When a software build is being scoped, the cost in the conversation is the build cost. Discovery, design, development, deployment, the headline number on the proposal. That is the cost the procurement committee weighs, the cost the executive approves, and the cost both parties focus on. It is also the smallest of the costs the build actually carries if it gets wrong. The expensive costs of a UAE software build that does not work out, rework, operational compromise carried for years, regulatory exposure, lock-in, the opportunity cost of the delivery window, are all downstream of the build budget and almost never on the proposal. They are visible after the build, when the cost of getting it wrong is being paid rather than priced, and they routinely add up to several times the original investment.
This piece is a perspective on the real cost of a UAE software build going wrong, and what that should change about how buyers select and de-risk. The argument is opinionated. We have a stake, BY BANKS sells the upfront work that prevents most of these costs, so the argument tilts toward the kind of investment we are paid for. We are not arguing that every build that overspends has gone wrong, or that the proposal cost is unimportant. We are arguing that selecting and pricing a build against the proposal number alone optimises the smallest cost; that the costs that decide whether the build was actually worth doing show up later and are systematically larger; and that the cheapest way to influence them is in selection and scoping, not in delivery firefighting. The headline price is the visible part. The decisions that matter are made against the rest.
The audience for this analysis is CFOs, CIOs, COOs, procurement leads, and founders comparing proposals for a UAE software build and trying to decide whether the headline numbers are actually comparable. The useful diagnostic question is not "which proposal costs least" but "for each proposal, what would the rework, compromise, regulatory, lock-in, and opportunity costs be if the build did not deliver what it intended, and how does the proposal price reflect protecting against them".
The Visible Cost and the Costs Beneath It
Below is the structure of the cost of a UAE software build, with the visible budget at the top and the five downstream costs underneath. Tap any cost layer to see what it is, how it surfaces (almost always late), and what to test for in selection to protect against it. The point is not the exact weighting; it is the shape, that the visible cost is one of six, and the other five are usually larger and unpriced.
The cost of a build that gets wrong, visible and below the line
Tap any layer for what it is, how it surfaces, and what to test in selection
Why the Visible Cost Is the Smallest of the Costs That Matter
The reason the visible cost is the smallest of the costs that matter is the nature of software in operation. A build that succeeds produces value continuously across years; a build that fails costs continuously across years. Both numbers compound. The headline build budget is a one-off that the procurement process is well-equipped to compare; the operational and supervisory costs are recurring, often unmeasured, and almost never compared across proposals at all, because they would have to be modelled rather than read off a page. The result is that buyers select on the cost that procurement can compare and live with the costs that procurement could not see.
The UAE context adds two specific cost layers that buyers in unregulated markets do not face the same way. The regulatory and supervisory cost of a build that produces determinations a licensed entity cannot defend is severe and concrete: under Federal Decree-Law No. (6) of 2025 the administrative fine ceiling on a violating licensed financial institution is up to AED 1,000,000,000, and in 2024 the CBUAE took enforcement action against eleven banks, six in connection with weak or absent AML/CFT and sanctions-compliance frameworks. The exposure attaches to the licensed entity, not to the software partner; a build that creates this exposure has cost the entity far more than the build budget, and the partner cannot insure against it on the entity's behalf. Separately, the UAE labour market context affects rework cost: with a +48 per cent net employment outlook in Q3 2025 per the ManpowerGroup Employment Outlook Survey and 56 per cent of UAE employers planning to increase workforce, finding the replacement seniority to fix a build that went wrong is materially harder and more expensive than the original would have been, because the market is competing for the same people.
This is why investment in the upfront work, scoping, partner selection, boundary precision, and the discovery-stage de-risking that precedes commitment, is structurally cheaper than the alternative. The cost of two extra weeks of scoping is the cost of two extra weeks of scoping. The cost of a build that needs full replacement two years later, plus the operational compromise carried in between, plus the supervisory exposure the original system created, plus the opportunity cost of the delivery window for the right system being lost to the wrong one, is many multiples of the upfront investment that would have prevented it. Buyers that get this right are not buying caution; they are recognising that the cheapest place to influence the total cost of a build is before it begins.
The shift in one observation
A UAE software build evaluated on the proposal cost is being evaluated on the smallest of the costs it might actually carry. The costs that decide whether the build was worth doing, rework, operational compromise, supervisory exposure, lock-in, and opportunity cost, are systematically larger, almost always unpriced in the proposal, and almost entirely set by decisions made before the build begins. Buyers that price the build well are buyers that priced the rest, by selecting and scoping against it rather than for it.
How the Hidden Costs Surface in Practice
Rework cycles that exceed original cost
A build that does not fit the operation produces ongoing rework and eventual replacement. The original budget plus the rework plus the replacement often exceeds what a second proposal would have cost, but the comparison is never made because the costs are spread across years.
Compromise borne by headcount
When the system does not match how the operation works, senior people spend time on coordination the system should be doing. The cost is invisible because nobody bills it as a software cost; it shows up in the operation as a productivity drag nobody attributes to the build.
Supervisory exposure attaches to the entity
A regulated build that gets the boundary wrong creates supervisory exposure the licensed entity carries, the AED 1 billion CBUAE fine ceiling under Federal Decree-Law No. (6) of 2025 attaches to the entity. The partner cannot absorb the exposure even by contract.
Exit price decided at signing
The cost of leaving the partner is decided at signing through IP, hosting, dependency, and knowledge-custody terms. Vague terms set a high exit price the buyer pays the first time the relationship needs to change, often years after signing.
The Decision in Plain Terms
Side by Side: Selected Against Real Cost vs Selected on Price Alone
| Cost layer | Selected against | Selected on price alone |
|---|---|---|
| Rework | Scoping and discovery priced as separate, de-risking investment | Rework absorbed as overrun later, often multiple times |
| Operational compromise | Build validated against actual usage, not functional acceptance | Workarounds accumulate, productivity drag never attributed |
| Regulatory exposure | Boundary tested explicitly in selection; partner is self-limiting | Supervisory exposure discovered when first questioned |
| Lock-in | Exit terms and IP custody specific at signing | Exit price discovered when the relationship needs to change |
| Opportunity cost | Phased delivery with intermediate value, window for impact protected | Long timeline outlasts the strategic moment the build was for |
The cost of getting a UAE software build wrong is not the proposal number. It is the proposal number plus rework, plus the operational compromise carried for years, plus the supervisory exposure the wrong system creates, plus the exit price of changing the partner, plus the opportunity cost of the window the wrong build occupied. The cheapest of those is the one buyers compare across proposals; the rest are decided by selection and scoping before any build begins.
What Selecting Against the Real Cost Looks Like
The pattern in buyers who protect themselves against the real cost of a UAE software build is recognisable. Discovery is treated as a separate, paid de-risking phase rather than bundled into the build proposal, and the depth of discovery is priced honestly rather than minimised for sales reasons. Each proposal's assumptions are surfaced and compared explicitly, so a cheaper proposal that scoped less is not selected over an expensive one that scoped honestly. The boundary on regulated decisions is tested in selection rather than left to discover later, and the partner that holds the line precisely is preferred even at a price premium because the supervisory exposure of the alternative is the larger cost. Continuity and IP terms are made specific and written into the contract at signing, so the exit price is known and reasonable rather than set in the partner's favour. Delivery is phased to produce intermediate value and protect the window for impact rather than committed to a single long timeline. None of this is heroic; it is recognising that the proposal cost is the smallest of the costs the build will carry, and selecting against the others is the cheapest place to influence them.
How This Sits With BY BANKS, Honestly
We have a stake here and it is fair to name it openly. BY BANKS sells the upfront work, deep discovery, careful scoping, precise boundary-setting in regulated contexts, that prevents most of these costs. The argument we are making would, if buyers internalised it, push proposals away from the cheapest-on-the-page model toward proposals that price the de-risking honestly, and we expect to be in those proposals. We also know the alternative, telling buyers the visible cost is the whole cost, would put them in exposure they cannot insure against, which is a more expensive way to win business that we are not prepared to do.
The boundary stays clear. BY BANKS is an independent software engineering company based in the UAE. We design and build software and hand it over. We do not provide insurance, regulatory, financial, or legal advice. We are not a regulated entity in any sector we serve, we do not act for or on behalf of any UAE authority, and we are not affiliated with or endorsed by any authority. On any engagement, the buyer owns its procurement, contracting, commercial, regulatory, and compliance decisions and their legal implications. The accountable party leads and owns those obligations; we build the system that supports them, and where the build is regulated, we are precise about what we do and what we do not.
Where This Analysis Is Useful
The conversations where this perspective is most useful tend to be at three moments: a buyer comparing proposals whose headline numbers vary widely and unsure how to compare them honestly; a CFO or procurement lead reviewing why a previous build cost so much more than the original budget; or a leader scoping a new regulated build and trying to decide how much upfront investment is justified. The honest answer is usually the same: the proposal cost is one of six costs the build carries, the other five are larger and unpriced, and the cheapest place to influence them is before the build begins.
For broader related work, see our perspective on how to choose a software engineering partner, our perspective on evaluating a partner for a regulated UAE build, and our perspective on the build, buy, or augment decision. The applied work sits across our operational platforms and technical consultancy capabilities. Get in touch if a 45-minute conversation about a specific proposal comparison would be useful.
Frequently Asked Questions
No. BY BANKS is an independent software engineering company. We do not provide insurance against any of the cost layers described, we are not a regulated entity in any sector we serve, and we cannot absorb supervisory exposure on behalf of a licensed entity. We do scope and build to reduce the likelihood and magnitude of these costs, the upfront de-risking the argument is about. The buyer owns its own procurement, risk, regulatory, and insurance decisions.
No. The argument is that the upfront spend should be priced honestly against what it prevents, not minimised for sales reasons. A small build with light regulatory exposure and a short impact window does not need the same upfront investment as a large regulated build with a long horizon. The discipline is matching the upfront investment to the downstream costs it protects against, not maximising it for its own sake.
They are summarised from publicly available sources as published. The CBUAE fine ceiling figures are drawn from Federal Decree-Law No. (6) of 2025 as published; the labour market figures are drawn from the ManpowerGroup Employment Outlook Survey Q3 2025 UAE summary. They are point-in-time and the authoritative current data is whatever is published by the issuing organisation at the time of reading. Buyers should rely on official sources for current figures and qualified advice on their own circumstances, not on this summary.
Approximately, not precisely. The cost of rework is approximated by considering what a full replacement would cost and the share of the original investment that would be salvageable. Operational compromise is approximated by estimating the headcount time spent on workarounds. Supervisory exposure is bounded by the regulatory framework (the fine ceiling, the typical action shape). Lock-in is approximated by reading the exit terms. Opportunity cost is approximated by considering the value of the strategic window the build is for. None of these is precise; all are materially larger than zero, and approximate weighting is sufficient to change the proposal comparison.
Then it is the right answer. The argument is not that cheaper proposals are always worse; it is that the cheaper proposal should be tested against the other costs before being selected on price. A genuinely cheaper proposal that has scoped honestly, holds the boundary correctly, has clean continuity terms, and protects the timeline is a strong selection. A cheaper proposal that achieved its price by leaving those things to the buyer is not, and the comparison is meaningful only when the assumptions are made visible.
The cost of a UAE software build that gets wrong is not the build budget; it is the build budget plus rework, plus operational compromise carried for years, plus supervisory exposure the wrong system creates, plus the exit price of the partner relationship, plus the opportunity cost of the window the wrong build occupied. The visible budget is the smallest of those and the only one most proposals compare on, which is the structural problem this argument is about. The UAE context makes the supervisory layer concrete, the AED 1 billion CBUAE fine ceiling under Federal Decree-Law No. (6) of 2025 attaches to the licensed entity, not the partner, and the labour market context makes rework harder, the ManpowerGroup +48 per cent net employment outlook for Q3 2025 reflects a tight competition for the seniority a fix would need. We have a stake in this argument and the argument stands anyway; the cheapest place to influence total cost is before the build begins, and selecting on the proposal number alone optimises the smallest of the costs the build will carry.
This article reflects our perspective on the real cost of UAE software builds. Figures cited (administrative fine ceiling up to AED 1,000,000,000 under Federal Decree-Law No. (6) of 2025; 11 banks subject to CBUAE enforcement action in 2024, 6 in connection with AML/CFT and sanctions-framework weaknesses; UAE net employment outlook of +48% for Q3 2025 per the ManpowerGroup Employment Outlook Survey) are drawn from publicly available sources as published; they are point-in-time and the authoritative current data is whatever is published by the issuing organisations at the time of reading. The cost-layer model and its illustrative weighting language are an observational reasoning aid rather than a quantified methodology, scoring rubric, or any specific risk model. BY BANKS is an independent software engineering company; we design and build software and hand it over, we do not provide insurance, regulatory, financial, or legal advice, we are not a regulated entity in any sector we serve, and we are not affiliated with or endorsed by any authority. On any engagement, the buyer owns its procurement, contracting, commercial, regulatory, and compliance decisions and responsibility for their implications. This article is not procurement, contracting, regulatory, insurance, or legal advice; buyers should obtain qualified advice for their specific circumstances. Public sources used in this piece are listed on our Sources and Data page.
Ready to Build Something?
If this resonated, let's talk about how we can apply these ideas to your business.
Start a Conversation