The build-versus-buy debate has been alive in enterprise software for thirty years and is still routinely framed as a binary. Pick one. Custom is expensive and risky, off-the-shelf is generic and constraining, choose your trade-off. The framing was always reductive and has become actively misleading in the UAE context, because the third option is usually the right one and rarely gets considered until the binary has already been chosen and is causing problems. Most UAE operators do not need to build or buy. They need to augment, and augmenting is the option that requires the decision to be made clearly rather than by default.
This piece is a perspective on how UAE operators should approach the build, buy, or augment decision. The argument is opinionated. We have a stake, BY BANKS does custom build and augmentation work and not off-the-shelf product sales, so the argument tilts toward outcomes that involve us. We are not arguing that building custom is always right, or that off-the-shelf is universally bad. We are arguing that the right answer is decided by the gap between what is available off-the-shelf and the actual operation it has to fit; that the UAE context, regulatory and operational, creates fit-gaps that off-the-shelf vendors typically have not closed; and that operators who default to buy without measuring the gap, or default to build without checking what already exists, both pay more than they needed to. The decision is a fit problem, not a preference one.
The audience for this analysis is COOs, CIOs, CTOs, transformation leads, and operations directors at UAE businesses choosing how to source operational software for a specific function. The useful diagnostic question is not "should we build or buy" but "where does the available product end and our operation begin, and is the gap something to live with, augment around, or build past entirely".
The Decision, Tested Against the Inputs
Below is a short read. Move the three sliders to reflect a real decision in front of you, the fit-gap between off-the-shelf and your operation, the weight of UAE-specific context, and the urgency, and the three options will surface a relative lead with a short interpretation. The numbers are illustrative; the point is that the answer moves predictably with the inputs, and the right option is the one matched to the inputs rather than the one chosen out of habit.
Where does the right answer land between build, buy, and augment?
Move the sliders to reflect a real decision, then read the interpretation
Why Augment Is the Most Underused of the Three
The reason buy and build dominate the conversation is that they map to existing organisational reflexes. Buy is procurement-led: write a requirements document, run a vendor evaluation, pick a winner, configure. Build is engineering-led: scope the work, hire or commission the team, deliver. Both have established playbooks, mature templates, and a vocabulary the executive team already speaks. Augment has none of those. It is the option that requires holding two ideas at once, that the available product is good for what it does and inadequate for what your operation specifically needs, and most procurement and engineering functions are not set up to think that way comfortably.
Augment is also the option that the dominant vendors actively discourage. Every enterprise software vendor in the UAE is incentivised to position its product as the complete answer, because partial answers do not close deals at full price. Engineering teams, conversely, are sometimes incentivised to position custom builds as the complete answer because partial builds do not generate the same scope. Augment, the honest middle, is what neither sales force is pushing, and it is therefore the option that has to be chosen actively by an operator who has actually measured the fit-gap.
The UAE context tilts this further. UAE operators repeatedly hit fit-gaps that off-the-shelf has not closed, because the products were built for other markets and the UAE-specific operational and regulatory contexts (CBUAE, SCA, DFSA, ADGM, DHA, MOHAP, DCD, NCEMA, Dubai Customs, UAE Pass, sector-specific rules, Arabic-language requirements, payment rails, sponsor and free-zone structures) sit outside the configuration surface of the global product. The product handles 80 per cent of the operation, the remaining 20 per cent is structural, not cosmetic, and that 20 per cent is where the operation actually distinguishes itself. Buy alone leaves the 20 per cent unfixed and absorbed by the team as workaround. Build alone re-implements the 80 per cent the vendor has already done. Augment uses the product for what it does well and builds around it for what it does not, which is what the fit-gap actually rewards.
The shift in one observation
"Build or buy" is a binary that often has a third answer hiding behind it. The UAE-specific operational and regulatory context creates fit-gaps off-the-shelf does not close, and the operations that work well are usually the ones where someone deliberately measured the gap and decided what to do about it, rather than defaulting to the option their organisation is set up to procure most easily.
Where the Binary Framing Breaks
Treating the decision as build-or-buy breaks in four predictable places.
Buy with structural gaps absorbed by people
The product fits 80 per cent of the operation, the missing 20 per cent gets done in spreadsheets, email, and undocumented workarounds. The team works around the gap indefinitely, and the cost of that workaround never appears on any system's bill.
Build that re-implements the obvious
A custom build closes the gap and also re-implements the 80 per cent that a mature product already does well. The result is more expensive than augment, slower to deliver, and a permanent maintenance burden against capabilities that are commodity elsewhere.
Augment that became a parallel system
Augmentation done without discipline drifts into a parallel system that competes with the product it was meant to extend. Two systems of record emerge, data drift, and the operator pays for both. Discipline at the boundary is what keeps augment from becoming this.
Decision made before the gap is measured
Build, buy, or augment is decided before anyone has actually measured where off-the-shelf ends and the operation begins. The right answer is then unknowable, because the input that decides it was never gathered, and the decision is made on preference instead.
The Decision in Plain Terms
Side by Side: Where Each Option Is Genuinely Right
| Pattern | Right option | Why |
|---|---|---|
| Mature product fits closely, light UAE context | Buy | Configuration closes the gap; building re-implements commodity capability. |
| Product fits the core, UAE context creates residual gap | Augment | Use the product for the core, build for the gap, hold the boundary. |
| Available products structurally mismatch the operation | Build | Integration overhead exceeds the value the product would add; custom is cheaper here. |
| Heavy UAE regulatory context, partial product fit | Augment | Regulated context is rarely fully configurable in global products; augment closes it cleanly. |
| Urgent need, fit-gap not yet measured | Measure first | Deciding before measuring is the most expensive way to be urgent. |
The build-versus-buy framing turns a fit problem into a preference problem, and preference is not the right input. The cheapest operation in the UAE is rarely the one that built the most, or the one that bought the most. It is usually the one that measured the fit-gap and chose the option matched to the gap, including the augment option that neither sales force pushes.
What Choosing Well Looks Like
The pattern in UAE operators that get this right is recognisable. The fit-gap is measured before any decision: where does the available off-the-shelf product end, where does the operation begin, and how much of the gap is cosmetic versus structural. The UAE-specific context is treated as input to the decision rather than a feature request: regulatory, operational, language, payment, sponsorship, free-zone, and sector-specific factors are assessed as part of the gap, not pushed downstream to be handled later. Urgency is weighed honestly: indefinite horizons reward investment, urgent horizons reward speed, and neither is allowed to dominate the decision on its own. The chosen option is then matched to the result: buy when configuration closes the gap, build when no product anchors usefully, augment when a product fits the core and the residual gap is structural. Where the choice is augment, the boundary between product and augmentation is held with discipline, so the augmentation does not drift into a parallel system competing with what it was meant to extend.
How This Sits With BY BANKS, Honestly
We have a stake in this argument and it is fair to name it. BY BANKS does custom build and augmentation work; we do not sell, configure, or implement off-the-shelf products. So we benefit when an operator concludes the answer is build or augment, and we do not benefit when the answer is buy. We argue for measuring the fit-gap because it is the right way to make the decision, and because we believe the augment option is structurally underused in the UAE; we lose decisions where the gap is genuinely small and off-the-shelf is the right answer, and that is a sensible outcome.
The boundary is the same as the rest of this work. We are an independent software engineering company based in the UAE. We design and build software and hand it over. 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 every engagement, the operator owns its procurement, contracting, technology selection, commercial, regulatory, and compliance decisions and their legal implications. We build the option that fits where we genuinely fit; the operator owns the choice.
Where This Analysis Is Useful
The conversations where this perspective is most useful tend to be at three moments: an operator deciding how to source software for a specific function and unsure whether to default to procurement or to engineering; a CIO whose buy decision is being absorbed in workaround cost the original business case did not anticipate; or a transformation lead facing a build decision whose scope keeps growing because no one has separated the structural from the cosmetic parts of the fit-gap. The honest answer is usually the same: measure the gap first, treat augment as a real option rather than a residual, and match the choice to the gap rather than to the organisational reflex.
For broader related work, see our perspective on what the core banking system will expose and our perspective on how to choose a software engineering partner. The applied work sits across our operational platforms and technical consultancy capabilities, with sector applications across banking, insurance, healthcare, construction, and fire safety. Get in touch if a 45-minute conversation about a specific build, buy, or augment decision would be useful.
Frequently Asked Questions
No. We do custom build and augmentation work. We do not resell off-the-shelf software, we do not run vendor product implementations, and we are not affiliated with any vendor whose product an operator might consider buying. On any engagement, the operator owns its procurement, technology selection, and contracting decisions. We build or augment; the operator chooses what is bought.
No. It is an observational reasoning aid. The weights are chosen to make the relative direction visible, not to score any specific decision, and the percentages are illustrative. It is not a methodology, a model, or procurement or technology selection advice. Real decisions require measuring the actual fit-gap against the specific operation, regulatory context, and constraints, which is what the operator and its qualified advisors do.
No. Buying is the right answer when a mature product fits the operation closely and the UAE-specific context is light. The argument is that the question is not buy versus build; it is which of buy, augment, and build matches the measured fit-gap. Buy is genuinely right for some operations; the recurring problem is that it is also chosen for operations where it is not right, because augment was never seriously considered.
By mapping the operation step by step against what the candidate product handles natively, distinguishing cosmetic gaps (a different label, a missing column) from structural ones (a workflow the product cannot model, a regulated reporting view the product cannot produce, a data shape the product cannot hold). This is usually done as part of a discovery engagement, where an honest mapping replaces the vendor's demo as the basis for the decision. The decision improves materially with the mapping; without it, the choice is preference.
When the augmentation grows large enough that it is doing most of the work, when integration overhead exceeds the value the underlying product adds, or when the product's assumptions actively get in the way of the right design. At that point augment has crossed into build territory and the right call is to recognise it. Holding the boundary, knowing when augment ends and build begins, is part of the discipline of choosing augment in the first place.
The build-versus-buy framing is widely treated as binary and in practice has a third option, augment, which is often the right answer for UAE operators because the available off-the-shelf products were built for other markets and the UAE-specific operational and regulatory context creates fit-gaps that configuration does not close. Operators that decide well measure the gap before choosing, treat augment as a real option rather than a residual, and match the choice to what the gap actually requires. We have a stake in this argument and the argument stands anyway; we lose decisions where buy is the right answer, and that is a sensible outcome. The boundary is the same as before: the operator owns its procurement, contracting, and technology decisions, and a good partner is one whose chosen option genuinely fits the measured gap rather than the organisational reflex.
This article reflects our perspective on the build, buy, or augment decision for UAE operators. Figures cited (UAE ICT sector revenue of approximately US$ 66 billion for 2024 per the UAE Ministry of Economy and Tourism; UAE ICT spending of approximately US$ 23 billion for 2024 with banking, financial services, and energy accounting for about 43 per cent of that spend per GlobalData) are summarised from publicly available sources as published; the figures are point-in-time and the authoritative current data is whatever is published by the named organisations at the time of reading. The slider model and the percentages it produces are illustrative reasoning aids rather than a methodology, scoring rubric, or measured statistics, and represent no specific operator or decision. BY BANKS is an independent software engineering company; we design and build software and hand it over, we do custom build and augmentation work and do not resell or implement off-the-shelf products, 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 operator owns its procurement, contracting, technology selection, commercial, regulatory, and compliance decisions and responsibility for their implications. This article is not procurement, technology selection, regulatory, or legal advice; operators 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