The two engineers were not the problem. Both were strong, both were senior, both had done exactly what their CVs claimed. The problem was that I had written a requisition for building features onto a system I had never measured, and the system did not want features. It wanted a dependency migration, a test suite somebody trusted, and a build that finished. Nine months later one of them had left for a role where shipping was possible, and I had learned something expensive: the codebase, not the roadmap, specifies the hire. Here is the audit I run now before a requisition is written, with the measurement for each check and what each result changes about the advert.
Why the codebase specifies the hire, not the roadmap
Most hiring plans start from the roadmap. You want three features next quarter, so you need engineers who can build features, so you write an advert for a developer with the relevant stack experience. The logic is clean and it fails whenever the codebase is in a state where features are not the bottleneck.
The same job title covers at least three genuinely different jobs. A builder adds capability to a system that is ready to receive it. A stabiliser reduces the rate at which the system surprises you. A migrator moves the system off something that is no longer supported, usually while it stays in production. These require different experience, attract different candidates, and in the UAE market they sit in different pay bands. Advertising one and delivering another is the most reliable way to lose a good hire inside six months.
The seven checks below tell you which job you are offering. They take two to three days, run in parallel with writing the job description, and every one produces a number rather than an opinion.
Check 1: Time the local feedback loop on a clean machine
Take a machine that has never built this project. Clone, install, build, run. Time each stage with a stopwatch and write the numbers down. Then run the full test suite and time that too.
The number that matters is time to first running application. Under ten minutes is healthy. Ten to thirty minutes is a tax you are paying on every single onboarding and every context switch, forever. Over thirty minutes means your new hire will spend their first fortnight learning to avoid rebuilding, which is a skill with no transferable value and a strong correlation with quiet disengagement.
Measure it on a clean machine specifically, because the person who knows the project has caches, environment variables and undocumented local fixes that make their experience irrelevant to a new hire. If the install fails on a clean machine, that is the finding. Write it down rather than fixing it in passing, because the number of undocumented steps required is itself the measurement.
Check 2: Measure test signal, not test count
Coverage percentage is the number everyone quotes and the least useful of the three you need. Collect all three: coverage, suite runtime and the flake rate over the last fifty runs in continuous integration.
The flake rate is the one that decides what your hire can do. A suite that fails intermittently teaches the team to re-run rather than investigate, and once that habit exists the suite has stopped being a safety net. Functionally you have no tests, whatever the coverage badge says. That matters enormously for hiring, because an engineer cannot refactor code they cannot verify. Without a trusted suite, every hire you make becomes an append-only developer: they add new code beside the old code because changing the old code is unverifiable. That is how a codebase acquires three implementations of the same thing.
If you want a single question to ask the current team, it is this: when the suite goes red, what is the first thing you do? If the honest answer is re-run it, you have your finding.
Check 3: Age the dependency tree
List every direct dependency with its current version, the latest version, and how many major versions separate them. Then mark which ones are out of support entirely. Most ecosystems have a one-line command for the first part, and the second part takes a browser and twenty minutes.
Two thresholds matter. Any dependency that is out of support and sits on the critical path, meaning authentication, data access, the web framework or the runtime itself, converts your feature requisition into a migration requisition whether you like it or not, because the first serious security advisory will force the work at the worst possible time. And two or more unsupported majors on the critical path means the migration is no longer a task, it is the job, and it needs someone who has personally finished one under production load.
That profile is scarcer in Dubai than general senior developers and it commands a premium. The useful consequence of this check is that you learn it before the offer stage rather than after, when the candidate you underpriced declines. Our breakdown of engineering cost expectations in the UAE is a reasonable starting frame for the band, and the structural view is in our guide to enterprise software development in the UAE.
Check 4: Find the coupling hotspots from version control history
Your version control history already knows where the codebase is fragile, and it will tell you for free. Two queries do the work.
First, find the files that change together most often. If editing the payment handler almost always requires editing the user model and a shared utilities file, those three are effectively one unit regardless of how the directories are arranged. Second, find the files with the highest number of distinct authors over the last year. High author count usually means either a genuine shared interface or a file that has become a dumping ground, and reading twenty lines of it tells you which.
The hiring consequence is specific and practical: these hotspots are where your new hire will break something in week two. Knowing them in advance lets you do two useful things. You can scope their first task deliberately away from the hotspots, so that their first week produces a shipped change rather than an incident. And you can turn the hotspots into an interview exercise, because showing a candidate a real coupling problem from your own history and asking how they would approach untangling it is worth more signal than any abstract system design question.
Run the audit first. Then let us write the requisition with you.
Send us the seven numbers and we will tell you whether you are recruiting a builder, a stabiliser or a migrator, and what that profile actually costs in the Dubai market right now.
Get started with your audit numbersCheck 5: Measure deployment friction honestly
Count three things for putting one line of changed code into production: the number of manual steps, the elapsed wall-clock time, and the number of distinct people whose involvement is required. Then record two dates: when the last rollback happened, and whether it actually worked.
The people count is the most revealing and the least tracked. A deployment that requires three people to be awake and available is not a pipeline, it is a meeting, and it sets a hard ceiling on how fast any hire can work no matter how good they are. If your roadmap assumes weekly releases and your deployment needs three coordinated humans, the constraint is not engineering capacity and hiring will not move it.
The rollback question matters because an untested rollback is not a rollback. Teams that have never executed one under pressure usually discover during their first real incident that a database migration made it impossible. If that is your situation, you are hiring a stabiliser and your first thirty days should include an actual rehearsed rollback. Our vendor-side version of this problem is covered in our handover playbook for outsourced Node.js work in the UAE, where the same friction shows up as a contractual question rather than an engineering one.
Check 6: Map the undocumented knowledge, and who holds it
This is the check that predicts a failed first quarter better than any other, and it is the only one that requires conversations rather than commands.
For each significant area of the system, write down who can safely change it today. Not who has commit access, and not who wrote it originally. Who, this week, could make a non-trivial change there without breaking something. Then mark every area where that answer is exactly one person, and for each of those, ask whether that person will be genuinely available to your new hire during their first quarter.
An area with one owner who has time is a manageable onboarding risk, because knowledge transfer is possible even if it is slow. An area with one owner who is leaving, unavailable, or already committed to something else is a stop condition. You can hire the best engineer in the market and they will still fail there, because there is nothing to transfer context from and nothing written down. The fix is partial and cheap compared to a failed hire: pair the owner with someone else for two weeks, or have them write down the critical paths, before the requisition opens.
For the structural version of this problem across a whole team, our knowledge transfer runbook for dedicated teams in Dubai covers how to make the transfer explicit rather than hopeful.
Check 7: Read the last 90 days of the on-call record
Pull every incident from the last ninety days and group them by cause rather than counting them. Four or five buckets is usually enough: dependency or infrastructure failure, deployment error, data integrity, capacity, and genuine application bug.
The shape of that distribution is your job description. If incidents cluster heavily in one or two buckets, you are hiring a stabiliser and the advert should say so, because the work is reducing a known failure class rather than adding capability. If incidents are evenly spread and low in volume, the system is behaving and you are genuinely hiring a builder. If the record is empty, do not celebrate yet. Either the system is genuinely calm, or nobody is recording incidents, and the second is far more common than the first. Ask one engineer what broke last month and compare their answer to the record.
This is also the check that produces the best interview material. Taking a real anonymised incident from your own record and asking a candidate to walk through how they would have diagnosed and prevented it gives you signal about the work they will actually do, which no abstract exercise can match. The adjacent quality question, how you keep incidents from recurring, is covered in our guide to building a QA automation team in Dubai.
The seven checks, with thresholds
| Check | What you measure | Worry threshold | Effect on the hire |
|---|---|---|---|
| 1. Feedback loop | Clean-machine time to running app | Over 30 min | Weeks of onboarding lost, raises seniority needed |
| 2. Test signal | Coverage, runtime, flake rate | Flake over 1 run in 10 | Hire can only append, not refactor |
| 3. Dependency age | Majors behind, support status | 2+ unsupported on critical path | Feature role becomes migration role |
| 4. Coupling | Files changing together, author count | Deep hotspots across domains | Scope week one away from them |
| 5. Deployment friction | Steps, elapsed time, people required | 3+ people needed | Caps delivery speed regardless of headcount |
| 6. Knowledge concentration | Areas with exactly one safe owner | One owner, unavailable | Stop condition. Fix before hiring |
| 7. On-call record | 90 days of incidents, grouped by cause | Clustered in 1 to 2 causes | You are hiring a stabiliser, say so |
What I write differently now
Three concrete changes came out of the expensive version of this lesson.
The advert now names the state of the system. Not in a self-flagellating way, but factually: the one line that says this role involves moving a service off an unsupported major version while it stays in production filters the candidate pool more effectively than any list of required technologies. The people who opt out were going to resign in month four anyway, and in the UAE, where every replacement involves notice periods and visa transfers, a month-four resignation is one of the most expensive outcomes available.
The interview uses our own artefacts. A real coupling hotspot from check four and a real anonymised incident from check seven, instead of abstract problems. Candidates who have lived through a migration react in a recognisable way: they ask about rollback, about whether traffic can be shadowed, and about who owns the deadline. Those three questions are a better senior signal than any whiteboard exercise I have run.
And the first thirty days are written before the offer goes out, with the week-one task deliberately scoped away from the hotspots. A new hire who ships something real in their first week has a different year than one who spends it fighting the build. For the full onboarding frame around this, see our guide to structuring a developer probation period in the UAE.
None of this makes the debt disappear. It makes the debt a specification input rather than a surprise, and that single change is the difference between a hire who stays and a hire who discovers, in month three, that they accepted a different job from the one they are doing.
Audit the code first, then open the role.
We source builders, stabilisers and migrators for UAE employers, and we would rather see your seven numbers than your job title. Bring the audit and we will tell you which profile to recruit and what it costs here.
Brief our Dubai team on your codebaseFrequently Asked Questions
How long does a technical debt audit take before hiring?
Two to three days of focused work for a single codebase of moderate size, and it can run in parallel with writing the job description rather than delaying it. Checks one, two, three and five are mostly mechanical and can be completed in a single day by any engineer with repository access and a clean machine, because they are measurements rather than judgements. Check four takes a few hours once you have the version control history commands ready. The two checks that take real calendar time are six and seven, because mapping undocumented knowledge means short conversations with several people, and reading the on-call record properly means grouping incidents by cause rather than counting them. If you have multiple services, audit only the two or three the new hire will actually work in during their first quarter. Auditing everything is how this exercise turns into a project that never finishes and never informs a requisition.
Why does a codebase audit change the developer role I advertise in Dubai?
Because the same job title covers three very different jobs, and the code decides which one you are actually offering. A healthy codebase with fast feedback, trustworthy tests and current dependencies supports a feature-delivery hire, and a strong mid-level engineer will be productive quickly and economically. A codebase with a slow build, a flaky suite and two unsupported major versions on the critical path needs someone who has personally completed a migration under load, which is a senior profile in a shallow pool and a different pay band. A codebase whose last ninety days of incidents cluster around the same three causes needs a stabiliser with operational instincts, which is different again. Advertising a feature role and handing over a migration is the most common cause of a resignation inside six months, and in the UAE market, where notice periods and visa transfers make every replacement slow and expensive, that mismatch costs considerably more than the audit.
What threshold on these checks means I should not hire yet?
There are two genuine stop conditions. The first is check six: if there is exactly one person who can safely change the area the new hire is meant to own, and that person is leaving, unavailable or already fully committed, then the hire will not succeed regardless of quality, because there is nobody to transfer context from. Fix the knowledge concentration first, even partially, through pairing or written documentation of the critical paths. The second is a combination: a build over thirty minutes together with a flake rate above roughly one run in ten. That pairing means no engineer, however senior, can get a reliable answer about whether their change is safe, so your new hire will spend their first quarter waiting rather than shipping. Everything else is not a stop condition but a specification input. It changes the role, the seniority and the plan, which is exactly what the audit is for.
Should I share the audit result with candidates?
Yes, and selectively in the interview rather than in the advert. Sharing the honest state of the build, the test suite and the dependency position in the second or third conversation does three useful things. It filters out candidates who only want a clean slate, which is information you want early rather than in month three. It gives strong candidates something concrete to react to, and the quality of that reaction is the best technical signal you will get in the whole loop, because an engineer who has actually lived through a migration will immediately ask about rollback, traffic shadowing and who owns the deadline. And it removes the single most common reason a developer resigns in the first six months, which is discovering that the role they accepted and the code they inherited are different jobs. Candidates almost never walk away because a codebase has debt. They walk away because they were not told.
Bryan
Delivery & Offshore Teams Expert at HireDeveloper.ae. Sets up dedicated and offshore engineering teams for UAE employers, and spends most of his time on the handover problem: matching the engineers a company recruits to the system they will actually inherit.