Almost every founder we speak to about a first technical hire uses the word CTO. Almost none of them need one.
That is not a criticism of anybody's judgement. It is a vocabulary problem with expensive consequences: four genuinely different jobs share overlapping titles, the most senior-sounding one is the one everybody knows, and hiring the wrong one costs a year and a salary before the mismatch becomes obvious.
There is no government or standards-body taxonomy for these roles. They are industry labels rather than regulated professions, so what follows is our own framing rather than a citable definition. We think it is the useful one.
The question that decides all of this
Before any of the role definitions matter, answer one thing honestly: what needs to happen in the next six months?
If the answer is that something needs to get built and nobody is currently building it, you need a builder. If the answer is that things are getting built but the wrong things, or in the wrong order, or too slowly because you are the bottleneck on every specification, you need a product person. If the answer is that four developers are stepping on each other and nobody owns the process, you need a manager. And if the answer is that you are about to make an architecture decision that will be hard to unwind, and nobody in the building can assess it, you need a senior technical head, though possibly for two days a month rather than five days a week.
Most founders who write that answer down discover that the six-month list is entirely build work, and that they were about to hire somebody whose distinctive skill is direction. There is nothing wrong with the candidate in that scenario. The mismatch is in the job.
The second useful question is what happens to the role in eighteen months. A lead developer hired now is likely still doing recognisably the same job then, possibly with somebody working alongside them. A CTO hired now is either leading a team you have grown or is doing a lead developer's job while carrying a title that no longer describes it. If you cannot picture the organisation the second version implies, that is the strongest argument available against hiring for it today.
Four jobs, not one
A hands-on lead developer writes code daily, makes implementation decisions, which library, how to structure a module, how to fix the specific bug, and is the person whose hands are on the keyboard when something breaks in production. The test is simple: does the business need something built this month, by a person who can take a specification and return working software?
A technical product person decides what gets built, in what order, and why. They translate a business goal, "we are losing customers at checkout", into something a developer can execute against. They may or may not write code. The defining skill is translation between commercial reality and technical possibility.
An engineering manager runs people, not code. Hiring, performance, growth, workload, and the process by which work gets planned, reviewed and shipped. This becomes necessary once coordinating the team is a full-time job in itself. It does not exist in a one or two person shop.
A CTO, in the genuine sense, sets multi-year technical direction, decides build versus buy at portfolio level, represents the business to investors, regulators and enterprise customers on technical matters, and builds and leads an engineering organisation once one exists.
Read that last one again and notice what it presumes.
Why the CTO title arrives too early
In a business with one technical person, that person is simultaneously writing code, deciding what to build, and nominally leading engineering because there is nobody else to lead. Founders reach for CTO because it is the title they know.
The job actually being done is roughly ninety per cent hands-on development and ten per cent product judgement.
The mislabelling is not cosmetic. It sets a compensation expectation, an equity expectation, and an authority expectation that none of them match the work. It makes the next hire harder, because the title is taken by somebody doing a different job. And it makes a performance conversation awkward, because the title implies a mandate that was never actually handed over.
The deeper problem is sequencing. A CTO's distinctive value is applied to decisions like whether to open a second product line, or whether the architecture needs to change to support a new market. Those decisions do not exist yet in a pre-product or single-product business. Hiring someone whose distinctive skill is not needed for a year, ahead of someone whose distinctive skill is needed on Monday, is a sequencing error rather than a technology one.
Strategy without execution capacity produces documents. Architecture diagrams, technology roadmaps, hiring plans. None of them ship anything or serve a customer.
The honest counter-case
There is a real version of the early CTO hire and it deserves stating fairly.
It applies when the business is fundamentally a technology bet from day one, the founding team has no technical judgement of its own to fall back on, and the decisions made in month one, data residency, compliance-relevant architecture, build versus buy for a regulated capability, will be expensive or impossible to unwind later. A regulated fintech or a health platform is the genuine case.
There, the person is not managing an organisation yet. They are making foundational, hard-to-reverse decisions that need enough authority and enough equity that they behave like a founder rather than a contractor.
That is a narrow case. Most businesses making their first technical hire are not placing that kind of irreversible bet, and would be better served by somebody who builds.
The option most founders do not know exists
Between hiring full-time and engaging an agency sits a third shape: a senior technical person engaged for a fixed number of days or hours a month.
What they can do is real. Set technical direction at the decisions that matter. Review the work of whoever is building day to day, whether that is a junior in-house, a freelancer or an agency. Be your second opinion when a quote arrives. Be present for the handful of high-stakes calls a year, choosing a stack, deciding whether to rescue or rebuild, signing off a security posture, without a full-time senior salary sitting permanently on the payroll.
What they cannot do is equally real. They cannot be available at the cadence of daily small decisions. They cannot write meaningful volumes of production code, because a few hours a week is review capacity rather than build capacity. And they do not substitute for a team once you have outgrown a single build stream. It is a multiplier on a small technical capability, not a replacement for one.
There is a proper UAE mechanism for this rather than an informal retainer. MOHRE operates a part-time work permit covering part-time, flexible, remote and job-sharing arrangements, valid for one year, with a published federal fee in the low tens of dirhams and a short stated processing time [1]. Separately, the UAE provides for working for two employers at once with MOHRE approval [2]. Confirm the current fee and processing time with MOHRE directly rather than relying on any article, including this one.
Evaluating someone when you cannot read code
This is the part founders find hardest and it is more tractable than it looks. Four things you can genuinely judge without any technical knowledge.
How they explain a past decision. Ask about a specific technical choice they made and why. A strong answer names the alternative they did not pick and says why in terms you can follow: cost, time, risk, what it would have made harder later. A weak answer is jargon with no trade-off in it, or a trade-off with no reasoning. "We used this because it is what we know" is not an answer to why.
Whether they ask about the business first. Someone who starts describing a stack before understanding what you do, who your customers are, and what you are trying to achieve this quarter is solving a technology problem rather than yours. The order of their questions is diagnostic and costs you nothing to notice.
How they describe a failure. Ask what went wrong on a past project. Somebody who can say what broke, why, what they did, and what changed afterwards is showing you a working feedback loop. Somebody with no failure to offer, or who blames a colleague or client without owning any part of it, is a warning regardless of skill.
Whether they can say what they would not build. Ask what they would leave out of a first version, or refuse outright. Somebody who can only say yes has no filter for scope, cost or risk, which is exactly the trait that turns a first project into a runaway budget.
Then, if the hire matters, pay for a trial. An interview tests how somebody talks about work. A small, paid, real piece of work tests how they scope it, what they ask before starting, whether the estimate holds, and what actually arrives against what was promised. Make it small enough to finish in days and real enough to matter: a bug you genuinely need fixed, a small feature you actually want. Avoid contrived exercises, and pay properly rather than asking for free work.
This is the only evaluation method available to a non-technical founder that does not depend on trusting the candidate's own account of their ability.
The UAE timing you have to plan around
Two things routinely surprise founders under time pressure.
A work permit sits ahead of the start date for a sponsored employee, so somebody cannot simply begin on the day you agree [3]. And a strong candidate already employed in the UAE will have a contractual notice period. Under the federal labour law, that notice must be no less than one month and no more than three, running from the date notice is given to the last working day [4]. Probation may not exceed six months and carries its own notice rules on both sides [4].
Put those together and a strong local candidate is realistically one to three months away from starting, plus permit time, from the day they accept. Plan backwards from when you actually need them, and confirm current timelines and fees with MOHRE rather than any article.
Remote is a recognised route rather than an improvisation. The UAE has a remote work visa allowing somebody to live here while working for an employer based outside the country [5], and the private sector recognises remote and flexible arrangements alongside full-time and part-time models [6]. Whether remote suits the specific role is a judgement question: a fractional reviewer whose work is periodic and scheduled travels well, while a lead developer who needs to absorb small decisions quickly travels less well.
For senior candidates, the long-term visa scheme includes a highly skilled professionals category covering information technology, alongside categories for innovators and scientists in technology fields [7]. That can matter as an attraction factor, though the eligibility criteria are specific and worth checking on the official portal rather than assuming.
Everything else about employing somebody here, gratuity, insurance, Emiratisation, free zone variance, is covered properly in our guide on in-house developer versus agency. None of this is legal advice, and where a specific contract is involved, take proper advice.
The first ninety days
Within two weeks, the new hire should produce a written account, from them rather than from you, of what they have found, in plain language. If a senior technical person cannot do that in a fortnight, that is itself a signal.
Within thirty days, one small piece of real work shipped and live. Not a plan, not an audit. Something that changed. This is the same logic as the paid trial: the fastest way to confirm a hire was right is the test you used to make it.
By ninety days, the answer depends on the role. A lead developer should have a sustained cadence of shipped work. A technical product person should have a prioritisation process you can see and question. A senior strategic hire should have articulated a direction you can restate in your own words, because if you cannot summarise it after three months, it has not been communicated regardless of how sound it is.
The signals it is not working are all things you can observe without technical knowledge. Nothing has shipped by day thirty and "still ramping up" is doing all the explaining. They cannot describe in plain language what they are doing and why. Their proposals get more expensive and more complex over time rather than more scoped. Or you are still making every small technical decision three months in, which usually means the wrong role was hired rather than the wrong person.
On salary, and what we will not tell you
We are not going to publish a salary figure for a developer or a CTO in the UAE, and we would be sceptical of anyone who does.
No official source publishes it. Every number in circulation traces back to a job board or a recruitment firm with a commercial interest in what that number looks like. Giving you false precision on the most consequential figure in the decision would be worse than giving you nothing. Speak to three candidates in your actual market and you will have better data than any guide can offer.
What we can price is our own work. A technical review of a proposal or a scope starts from around AED 1,500, which suits a second opinion on a quote or on a candidate's trial work. A codebase and dependency review starts from around AED 4,000. Final pricing depends on scope, and these are our own figures rather than a market survey.
Before any of that, spend ten minutes writing down what you need done in the next six months in plain business terms, then read the four role descriptions above and pick the one that matches. Most founders discover they need somebody who builds, and were about to hire somebody who directs.
References
- MOHRE, part-time work permit
- UAE Government, working for two employers at one time
- UAE Government, getting a work and residency permit
- MOHRE, laws and regulations
- UAE Government, remote work visas
- UAE Government, employment contracts, duration and models in the private sector
- UAE Government, golden visa
- SKIMBOX, in-house developer versus agency in the UAE
- SKIMBOX, Dubai agency versus offshore team
- SKIMBOX, how to read a software proposal
Fees, processing times and permit conditions change. Confirm every figure directly with MOHRE or the official UAE government portal before relying on it. This article is not legal or employment advice.
