Most technology decisions are cheap to change. You can swap an email tool on a Tuesday afternoon and nobody notices. You can redesign a homepage twice in a year and the only cost is the design fee.
A small number are not like that. They are taken early, usually quickly, usually by whoever happened to be in the room, and they set the price of every decision that comes after them. Companies in Dubai and Abu Dhabi rarely discover which ones they were until the second bill arrives, two or three years later, in the form of a rebuild.
Four of them account for most of that bill.
1. The stack was chosen by whoever was available
A founder needs something built. Someone in the network knows a developer, or a cousin runs a small agency, or a freelancer quotes a third of what everyone else does. The work gets done and it works.
What nobody asks at that point is who else can maintain it. A stack picked because one person knew it is a stack you can only staff from a pool of one. Two years on, that person has moved to Riyadh or gone in-house, and the company discovers its whole operation runs on a framework version nobody will touch and a schema nobody documented.
The question is not “is this a good technology”. Almost all of them are. The question is “if this person disappears next month, how many people in this market can pick it up, and what will they charge”. In the UAE that answer is knowable before you sign, and almost nobody asks it.
2. The data model was designed around the first customer
This is the expensive one, and it is almost invisible while it is happening.
Early on there is one client, one workflow, one set of assumptions. The database gets shaped around them because that is the concrete thing in front of everyone. It ships, it works, more customers arrive, and each new one needs a small exception. A flag here. A second table that is almost the same as the first. A field called notes that six different things now get written into.
Nothing breaks. That is the trap. It simply becomes gradually more expensive to add anything, until a feature that should take a week takes a quarter and nobody can explain why.
Reversing a data model is not a refactor. It is a migration with downtime, a re-test of everything, and a period where both shapes have to be supported. It is the most common reason a company that is doing well finds itself quoted a rebuild price rather than an improvement price.
3. Integration was left until after launch
The website ships. The accounting system, the CRM, the inventory tool and the payment provider are all going to be connected “in phase two”.
Phase two is where the real work was. By the time it starts, three of those systems have been chosen independently, by three different people, each assuming that connecting them is somebody else’s problem. Often one of them has no usable interface at all, and the company ends up paying someone to retype data between two screens — which it will still be doing four years later, because that person is cheaper than the integration project.
The UAE has made this decision sharper rather than softer. Once invoicing has to leave your systems in a structured, machine-readable form, the quality of the join between your tools stops being an internal inconvenience and becomes a compliance surface. That is the argument in e-invoicing being a systems project rather than an accounting one.
4. The first technical hire was a builder, not a decider
Companies hire for output. The first technical person is chosen because they can build the thing, and they can. What they are not asked to do, and often not equipped to do, is decide what should not be built, or say no to a founder, or choose the boring option over the interesting one.
So the architecture ends up reflecting one person’s enthusiasm rather than the business’s constraints. It is nobody’s fault. It is a hiring brief that asked for hands when the company needed judgement, and the two are genuinely different jobs.
This is the gap fractional CTO work exists to fill: the decisions that are expensive to reverse taken once, by someone who has taken them before, without adding a full-time salary to a company that does not yet need one.
What a reversible decision looks like
The test is not whether a choice is right. It is what it costs to be wrong.
A reversible decision has a boundary around it. The payment provider sits behind an interface, so swapping it is a week rather than a quarter. The content lives somewhere it can be exported from. The reporting reads from a copy of the data rather than being welded into the application. None of that is expensive at the start; all of it is expensive to add later.
Get the reversible ones wrong and you lose a week. Get the four above wrong and you lose the option of changing your mind.
Why the cost curve is so steep
None of the four decisions above is dramatic on the day it is taken. What makes them expensive is that each one quietly becomes a dependency for everything built afterwards.
A framework choice looks like a preference in month one. By month thirty it is the reason a feature request needs a specialist, and the reason two of the three developers you interviewed said no. Nothing about the original decision changed. What changed is the number of other things now resting on it.
This is why a rebuild quote so often shocks a company that believes it has been investing steadily. The quote is not pricing the new site. It is pricing the removal of four years of accumulated dependency.
What to do if you are already inside one
Most companies reading this are not at the start. They are two or three years in, aware that something is wrong, and being told the answer is to start again. It usually is not.
The useful move is to find out which of the four you actually have. The remedies are completely different, and only one of them justifies a rebuild.
If the problem is the stack, the fix is documentation and a second pair of hands, not a rewrite. Buy down the key-person risk first and you often discover the technology was never the issue.
If the problem is the data model, that is the one worth real money — and it can usually be done underneath a running system rather than by replacing it. Painful, but far cheaper than rebuilding the parts that work.
If the problem is integration, the answer is almost never a new platform. It is a small piece of plumbing and an honest conversation about which of your existing tools has no future.
And if the problem is that nobody is deciding, no amount of building will fix it, because the next build will inherit the same absence of judgement that produced this one.
A supplier who wants to rebuild will diagnose a rebuild. That is not dishonesty, it is what they sell. Getting the diagnosis from someone with nothing to build is the cheapest hour in the process.
Frequently asked questions
How do I tell the difference between a decision that is reversible and one that is not?
Ask what has to change elsewhere if you change this. If the answer is “nothing, we swap it out”, it is reversible. If the answer involves migrating data, retesting unrelated features, or coordinating three suppliers, it is not. That question takes a minute and is worth asking out loud before anything is signed, because the cost of being wrong is what you are actually buying.
Our developer is excellent. Is key-person risk really a problem?
Their quality is not the risk; their singularity is. The question is not whether they are good but what happens in the month after they leave, and everyone eventually leaves. The cheap insurance is documentation, a code repository the company owns rather than the developer, and one other person who has deployed a change successfully.
We were quoted a full rebuild. How do I know whether it is justified?
Ask what specifically cannot be carried forward, and why. A justified rebuild has a concrete answer: the data model cannot represent what the business now does, or the platform is out of support and cannot be upgraded. An unjustified one is described in adjectives — outdated, legacy, not modern. If the reasons are aesthetic rather than structural, you are being sold a redesign with a rebuild price on it.
Do these decisions look different for a company in Dubai than elsewhere?
The decisions are universal; two of the constraints are local. Staffing depth in this market is genuinely different from a larger one, so a niche stack choice bites harder here. And the regulatory direction of travel, from data protection through to structured invoicing, keeps raising the price of systems that cannot talk to each other cleanly.
Can these decisions be fixed without a full-time technology lead?
Usually, yes. The work is concentrated: a few weeks of diagnosis and decisions, then oversight while other people build. That shape is exactly why fractional arrangements exist. What does not work is leaving the decisions to whoever is currently building, because it asks one person to both propose the work and judge whether it should happen.
A question worth asking before you sign
“If we want to replace you in eighteen months, what exactly do we take with us, and who else in this market can pick it up?”
The answer tells you more than a portfolio does. A supplier who has thought about the handover will describe the code, the data, the accounts and the documentation without hesitating. One who has not will talk about the relationship instead. Both answers are useful, and you only get them by asking before the work starts, not when it has already gone wrong.
If the site itself is the thing being decided, the same reasoning applies to how the build is scoped — and, if you are operating in both languages, to whether Arabic was designed in or bolted on.