The decision to bring development in-house is usually framed as a hiring problem. Find the people, agree the salaries, set a start date, tell the agency.
Hiring is the visible half and the easier one. The half that determines whether this works is everything the agency currently holds that is not written down anywhere, plus the accounts and code that may not yet be in your name.
Get the sequence wrong and you spend six weeks with no agency, a new team who cannot yet act, and a system that nobody is maintaining.
Four things have to transfer
The code, with its full history rather than an export. A repository with years of commits tells a new team when things changed and why. A zip file tells them nothing.
The accounts and infrastructure, in your business's name. Hosting, domain registrar, code repository, monitoring, payment gateway, app store accounts, third-party services.
The data, in a form you can actually use and have verified.
The knowledge, which is neither written down nor easy to extract.
The first three are logistics. They are checkable, they have definite answers, and you can confirm them in a day. The fourth is the actual project.
Why knowledge is the hard one
Most of what an agency knows about your system exists in people's heads.
Why a particular decision was made and what the alternative would have cost. Which parts are fragile and should be touched carefully. What that odd workaround in the billing logic is protecting against. Which client complained about what, and what got changed as a result. Which supplier's interface behaves differently on Thursdays.
None of it is in the code, none of it is in the documentation, and most of it will not come up in a handover meeting because nobody thinks to mention what they consider obvious.
So do not run handover presentations. Have your incoming people work alongside the outgoing ones on real tasks.
Knowledge surfaces when somebody tries to change something and asks why it is built that way. A presentation transfers what the presenter thought to mention. Working together surfaces what nobody thought was worth mentioning, and that is where the value is.
The measure of a sufficient overlap is not calendar time. It is whether your team has deployed real changes to production with the agency still reachable. If they have not touched production while the previous team was still available, the overlap was decorative regardless of how long it lasted. One to three months is typical for a system of any complexity.
Sequence, and the mistake everybody makes
The order is: confirm ownership, hire, overlap, then reduce the agency's scope in stages.
The common error is giving notice first, because it feels decisive and it sets a date everything else can organise around. It also removes your bargaining position at exactly the moment you need it, before you have discovered which accounts are in somebody else's name.
Confirm ownership before anything else. That you own the code, in writing, unconditionally. That every account is in the business's name rather than the agency's or an individual's personal email address. That you can export the data and have actually tried. Our guides on who owns your code, the accounts your business must own and getting your data out cover each of those, and all three are far easier to resolve while the relationship is good.
Hire before giving notice. Hiring takes months in the UAE. A work permit sits ahead of a start date for a sponsored employee, and a candidate already working here will have a contractual notice period. Together those mean a strong local hire is realistically some months away from starting once they accept. Confirm current timelines with MOHRE and plan backwards from when you need people. Our guide on a first technical hire covers the roles and the timing.
Then reduce scope in stages rather than ending everything on one date.
If you cannot hire fast enough, phase it. Keep the agency on a reduced scope covering what your team cannot yet support, and shrink that scope as capability builds. It costs more in the short term than a clean break and considerably less than an outage nobody can fix.
You are replacing more than a developer
This is the most common underestimate.
An agency typically provides four functions: somebody deciding what gets built, somebody building it, somebody checking it works, and somebody keeping the infrastructure running. Those functions do not disappear when the agency does. If you hire only for the building, the other three land on whoever happens to be nearest, which is usually you.
It also provided continuity. One developer cannot cover holidays, illness or a resignation, and has nobody to check their work. Hiring a single person to replace an agency recreates precisely the dependency you were trying to remove, except now you carry the employment obligations too.
One structure worth considering: a junior or mid-level developer in-house for day-to-day work, plus an experienced person engaged part-time for architecture, review and the handful of high-stakes decisions each year. That buys responsiveness without needing to hire seniority you cannot yet keep busy.
On hiring the agency's own people: worth exploring, and it needs care. Most agency contracts restrict it, and the relationship matters until the handover is done. Ask the agency openly rather than approaching individuals, because being discovered mid-handover is expensive. Sometimes they will agree, particularly when the alternative is losing the account entirely.
Expect the rebuild conversation
Your new team will very likely want to rebuild. Anticipate it rather than being surprised.
Unfamiliar code always looks worse than code you wrote yourself, because you see the decisions without the constraints that produced them. Nearly every odd-looking thing in a working system is the residue of a real problem: a deadline, a client demand, a limitation of a tool that no longer exists.
Set the expectation before anybody starts that the first six months are about running and understanding the system rather than replacing it. Then ask for a written assessment at month two or three, once they genuinely know it.
A rebuild proposed in week three is a reaction to unfamiliarity. One proposed in month three, with a specific list of what cannot be fixed and why, might be a real finding. Our guide on rebuilding versus fixing covers how to assess that claim.
Handle the agency well, because it is cheap to
Handovers go better than people expect when handled straightforwardly, and worse than expected when handled awkwardly.
Tell them early. Explain the reasoning. Pay properly for handover time and treat it as real work rather than an obligation they owe you.
Agencies deal with this regularly and most are professional about it. What produces a bad handover is being surprised, being unpaid for the transition, or discovering the plan by accident.
Paying for handover is the cheapest part of the exercise. Handover performed unpaid, under notice, by people whose relationship with you is ending, is handover done to a minimum standard. Paying for it buys attention and goodwill at exactly the moment you need both.
Then arrange ongoing support explicitly rather than relying on goodwill afterwards. A small retainer for questions over the following few months costs little and removes the single largest risk in the whole move, which is your new team hitting something they cannot explain with nobody left to ask. Agree it before the relationship ends, not by calling three months later.
If the agency does become difficult, focus on what you control: ownership of code, accounts and data, established before you give notice. Our guide on changing your development agency covers the order of operations that protects you regardless of how a supplier reacts, and what a proper handover document must contain.
The test that matters
Your team deploys a change to production without the agency's help, while the agency is still engaged.
That is the only meaningful verification. A thick handover document, a completed checklist, a series of walkthrough sessions: all are proxies for that one demonstration, and all can be produced without it being true.
Schedule it deliberately, early in the overlap rather than at the end. If it does not work, you still have the agency and time to fix the gap. If you leave it until the final week, you find out at the point where you have neither.
What the agency was doing that nobody itemised
Before deciding, it is worth writing down what you are actually replacing, because the invoice showed one number and the arrangement provided several things.
Cover. Somebody was always available. Holidays, illness and resignations were the agency's problem to absorb, and you never saw them. An internal team of one converts every one of those into your outage.
A second opinion. Somebody else looked at the work before it shipped, even informally. That is a quality mechanism you stop having the moment there is only one person, and its absence shows up gradually rather than immediately.
Breadth. An agency has seen many systems and many failures. When something unusual happens, somebody there has probably seen it before. A specialist internal team is deeper on your system and narrower on everything else, which is the right trade for some businesses and the wrong one for others.
Capacity that flexes. A busy month absorbed by adding people temporarily. Internally, a busy month is overtime or slipped deadlines, because you cannot hire for six weeks.
Somebody to hold accountable. A contract with a company you can escalate to, and eventually leave. Once the work is internal, the accountability is yours, which is what you wanted and also what you now carry.
None of these is an argument against the move. They are the things to budget for consciously rather than discover, because each one has a cost and the cost does not disappear simply because the invoice does.
Is this the right move at all?
Two questions decide it.
Is the work continuous? Development in-house makes sense when there is enough sustained work to keep people genuinely busy. If your need arrives in bursts with quiet months between, an internal team spends those months either idle or being given work invented to fill them, which is how products accumulate features nobody asked for.
Is the knowledge deep and specific? Where the domain is unusual and takes months to learn, keeping that knowledge inside the business has real value. Where the work is standard, an agency's breadth is worth more than an employee's focus.
On cost specifically: it saves money less often than expected, because the comparison people run is incomplete. A day rate looks expensive next to a monthly salary until you add employment obligations, recruitment cost, management time, tooling, and the periods when there is not enough work. Our guide on in-house developer versus agency covers that comparison properly, including the UAE employment obligations.
Responsiveness is frequently the real motivation even when cost is the reason given, and it is a legitimate one. Wanting somebody who can change something this afternoon rather than raising a request that joins a queue is a genuine business need, and it is worth naming honestly rather than dressing as a saving that may not materialise.
Note also that the decision is only partly reversible. Re-engaging an agency is possible, and you will have lost the accumulated knowledge the previous team held and possibly the relationship itself. There is a real switching cost in both directions.
Budget for the first year honestly
The comparison that gets run is a day rate against a salary. The comparison that matters covers a full year and includes the things that appear on neither.
Recruitment takes months of somebody's time and frequently a fee. Onboarding means several months during which people are paid full rates while producing less than full output on an unfamiliar system. The handover itself is a real cost, and the overlap period means paying twice for a stretch.
Then there is the standing overhead an agency absorbed invisibly. Tooling and licences per person. Management time, which lands on somebody who was previously doing something else. Training and keeping skills current. Cover during holidays, which is either accepted downtime or additional headcount.
And ongoing maintenance does not reduce. Our maintenance guides budget fifteen to twenty-five per cent of build cost annually for keeping software alive, and that work still needs doing whoever performs it. Moving it in-house changes who does it rather than whether it is needed.
None of that makes the move wrong. It makes the first year more expensive than the arithmetic most businesses run, and it means the saving, where there is one, arrives in year two or three rather than immediately.
Work it out over three years rather than one, and be honest about the months where there will not be enough work to fill. That second figure is the one that most often changes the answer, and it is the one nobody wants to estimate.
Start here
Before hiring, and long before giving notice, verify that the code, accounts and data are genuinely yours.
That check takes a day and costs nothing. Businesses that skip it discover the problem at precisely the point where they have the least room to fix it, which is after the notice has been given.
If you want help, a codebase and dependency review establishing what exists, what is undocumented and what needs to transfer starts from around AED 4,000 with us. Reviewing a handover you have been given, or acting as the technical second opinion while an internal team builds up, sits in the same range. Final pricing depends on scope, and these are our own figures rather than a market survey.
References
- SKIMBOX, in-house developer versus agency in the UAE
- SKIMBOX, your first technical hire in the UAE
- SKIMBOX, changing your development agency in the UAE
- SKIMBOX, who owns your code in the UAE
- SKIMBOX, the accounts your business must own
- SKIMBOX, getting your data out
- SKIMBOX, rebuild it or fix it
- MOHRE, work permits and employment services
Employment timelines, permit requirements and fees change. Confirm current requirements directly with MOHRE or the official UAE government portal. This article is not legal or employment advice.
