We Converted 6 Contract Developers Into Employees in Dubai: the 7 Steps I Wish We Had for the First 2

Our second conversion nearly cost us the engineer. He had been contracting with us for fourteen months, we offered him a permanent role with a base salary that I thought was generous, and he went quiet for four days. When he came back he had done the arithmetic I had not: on his contract he was invoicing for roughly eleven months of billable days a year, and our offer put him about nine percent down in cash for the privilege of being harder to leave. He was right, we fixed it, and I started writing the sequence down. This is that sequence, after six conversions.

Why Conversions Go Wrong When Ordinary Hires Do Not

A normal hire runs through a process. You price the role, you test the candidate, you check the paperwork, you onboard them. A conversion skips all four, because the person is already sitting in your standup and the whole thing feels administrative. That is the entire problem in one sentence: conversion is a new hire wearing the costume of a contract amendment.

The three failures are predictable once you have seen them. The pricing failure is treating a day rate as a salary. The evaluation failure is assuming contract performance predicts employee performance, when the contract deliberately exercised a narrow slice of what the permanent role needs. The sequencing failure is issuing an offer with a start date before you know what the person’s permit position allows, which turns a celebration into a renegotiation with somebody who already trusts you. Nobody writes a conversion playbook, because conversions happen one at a time and feel like a good problem to have. Here is ours.

Step 1: Decide Whether Conversion Is the Right Instrument

Teams convert for three different reasons and only two of them survive scrutiny. The first is retention risk: the contractor is load-bearing and you believe a competitor will hire them permanently. The second is scope that has become permanent: the work is no longer a project, it is a system that needs an owner, and ownership sits badly in a contract. Both are good reasons and both justify a headcount slot.

The third reason is administrative convenience, and it is the one to interrogate. Wanting fewer invoices, simpler access control or a tidier org chart is not a reason to create a permanent, difficult-to-reverse cost. If convenience is the real driver, the honest alternatives are a longer fixed-term contract, a retainer with a notice period, or restructuring how the contractor engages with you. Our notes on engaging developers under a UAE freelance permit cover the options that are not conversion.

Write the reason in one sentence before you proceed. If the sentence is about your paperwork rather than their scope or their departure risk, stop here. Two of our six conversions should probably have been long contracts, and in both cases the sentence would have told me so.

Step 2: Price Total Cost of Employment Before the Conversation

This is the step that nearly lost us an engineer, so it gets the most space. A contractor day rate is a single number that already contains everything. Employment splits that number into a base salary plus a set of costs that you pay and they do not see, and if you compare your base against their day rate you will reliably mislead both of you.

Build two annualised figures. On the employment side: base salary, any allowances, end-of-service gratuity accrual, medical insurance, visa and permit costs, annual leave, any air fare provision, plus the overhead of equipment and tooling if you were not already providing it. On the contract side: their day rate multiplied by the billable days they actually invoice, which is never 260 and in our experience lands between 200 and 230 once holidays, admin and gaps are counted.

Then compare the two things that actually matter to each party. Your total cost of employment against your previous total contract spend, which tells you whether the conversion is affordable. And their new gross cash against their previous net invoicing, which tells you whether they will accept. Those are different comparisons and teams routinely run only the first. Our notes on building a Dubai salary benchmark cover how to sanity-check the base against the market rather than only against the contract.

Step 3: Sequence the Permit and Sponsorship Route First

Establish the contractor’s current status before you issue anything at all. The route to employment, and therefore the realistic start date, differs substantially depending on which of these applies: they hold a freelance permit, they are sponsored by another employer, they are resident on a family member’s sponsorship, or they are currently outside the UAE and working with you remotely.

Those four cases have genuinely different timelines, and the gap between the fastest and the slowest in our own conversions was about ten weeks. The failure mode is universal and avoidable: you issue an offer with a confident start date, discover the route requires cancelling an existing arrangement or serving a notice period, and have to go back and move the date. You have now spent trust you did not need to spend, on somebody who is already inside your organisation and talking to your team about it.

The fix is to offer a start window rather than a start date until the route is confirmed, and to say explicitly that the window firms up once the paperwork path is clear. Nobody has ever objected to that framing. Several people have objected to a date moving. Run your internal approvals in parallel with the route check rather than after it, because your own finance sign-off is almost never the binding constraint and treating it as sequential adds a week for no reason. Our notes on part-time developer permits in Dubai cover the adjacent cases where conversion is not the only path.

Step 4: Close the Pre-Conversion IP Gap

Work delivered under the old contract is governed by the old contract. This is obvious when stated and almost universally missed in practice, because the new employment agreement contains an intellectual property clause and everybody assumes it covers everything the person has ever done for you. It does not reach backwards.

So the question to answer is whether the original contract assigned the work product cleanly to you. If it did, you need nothing further and should note that you checked. If it was silent, or if it assigned a licence rather than ownership, or if the contractor engaged through their own entity and the chain of assignment is unclear, then the conversion is the natural and cheapest moment to fix it. The person is well disposed towards you and the fix is a short, specific assignment of the previously delivered work.

The reason to do this now rather than never is that the cost of discovering the gap scales with time and with the importance of what was built. We found ours during due diligence on a client contract, about eighteen months after the conversion, on a service that had become central. It was resolved amicably and it should never have been a conversation. Our notes on IP ownership in UAE developer contracts cover the clause-level detail, and our notes on non-compete clauses for UAE developers cover the related terms people try to add at this moment and mostly should not.

Step 5: Set the Start Date Deliberately

The employment start date is not an administrative detail, it is the date from which formal end-of-service entitlement and the probation window both run. That makes it the single most consequential field in the paperwork, and it deserves a decision rather than whatever the HR system defaults to.

The question that actually needs answering is what you do about the contract period internally. Formal entitlements run from employment, but you have discretion over recognition: leave accrual policy, seniority for internal mobility, eligibility dates for any long-service benefit, and how you describe their tenure to the team and to clients. Leaving this ambiguous is the mistake. An engineer who has been embedded for two years and is treated as a day-one joiner for every internal purpose experiences the conversion as a demotion with extra paperwork.

We recognise contract time for internal leave and seniority purposes, we state it in the offer in one sentence, and we are explicit that formal end-of-service accrual starts at the employment date. That combination has never caused a problem. The version where we said nothing cost us an engineer eight months later, who told us in his exit conversation that being introduced as a new joiner after two years on the team was the moment he started looking. Our notes on end-of-service gratuity for engineers in the UAE cover the accrual mechanics, and our notes on writing a Dubai developer offer letter cover where to put the recognition sentence so it is not lost.

Step 6: Re-Run the Evaluation the Contract Let You Skip

This is the step that gets the most resistance internally, and it is the one I would least like to give up. The objection is reasonable: we have worked with this person for a year, what could an interview possibly tell us. The answer is that the contract exercised a deliberately narrow slice of what the permanent role requires, and you have strong evidence about that slice and almost none about the rest.

Think about what a contract structurally does not test. Mentoring and review of people more junior, because a contractor is rarely given that. Ownership of a system through an incident at three in the morning, because on-call usually sits with staff. Participation in planning where the answer is to build less, because a contractor who argues for less scope argues against their own invoice. Those are not edge cases, they are most of what a senior permanent engineer does.

So the evaluation is not a repeat interview, it is a targeted conversation about the delta. We run one ninety-minute session: a design discussion where the best answer is to not build something, a review of a junior colleague’s pull request with the brief to coach rather than correct, and an honest conversation about what they want in three years. Two of our six conversions changed shape because of it, one into a more senior role than planned and one into a continued contract by mutual agreement. Our notes on engineering headcount planning cover how to hold the slot open while that conversation happens.

Step 7: Run the First 90 Days as an Onboarding

The assumption that sinks the last step is that a converted hire needs no onboarding because they know the codebase. Knowing the codebase was never the hard part. What changes on conversion is scope, authority and what the organisation expects of them, and none of that is self-evident from the inside.

Give the conversion an explicit scope change in writing: what they own now that they did not own before, what they stop doing, and who approves decisions in their area. Give them a 30, 60 and 90 day plan like any other joiner, with the first thirty days deliberately including the organisational material that contractors are routinely excluded from, which in our case meant the roadmap rationale, the client commercial context and the team’s own hiring plan. Then book a ninety-day review and actually hold it.

The failure mode here is quiet and slow. A converted engineer with no stated scope change keeps doing precisely the contractor job, while the organisation starts expecting ownership behaviours nobody asked for. Six months later somebody says they are not operating at the level of the role, which is true and entirely the employer’s fault. Our notes on offboarding a remote developer in the UAE cover the mirror image, for the conversions that do not work out.

FAQ: Converting a Contract Developer in Dubai