Every transformation lead I meet in the UAE is carrying some version of the same problem: a SaaS estate that grew one procurement decision at a time, and a steering committee that now wants to know why the licence bill keeps climbing while the integration backlog keeps growing. Buy versus build used to be an easy call. SaaS was cheaper, faster, and someone else's problem to maintain, and for most workloads that logic still holds. But the calculus has shifted at the margins, and the margins are where transformation budgets go to die.
Two things changed. First, per-seat SaaS pricing scales linearly with headcount while custom software doesn't, which means the crossover point where building wins arrives earlier for large organisations than the default assumption suggests. Second, modern development, mainstream frameworks, mature cloud platforms, AI-assisted engineering, has cut the cost and risk of a custom build to a fraction of what a 2018-era business case assumed. If your buy-vs-build framework predates those shifts, it's quietly biased. This post is the framework I'd take to a steering committee in 2026, built for someone who has to defend the decision, not just make it.
Start with the default: buy
Any credible framework starts with a bias toward buying, because most software categories are commodities and rebuilding a commodity is value destruction. Email, HR core, finance core, CRM for a standard sales motion, collaboration, these are settled markets. The vendor amortises R&D across thousands of customers; you never will. If a workload is undifferentiated, the discussion should end at vendor selection, and any internal sponsor pushing to build one of these should be asked what strategic problem the build solves that configuration can't.
The framework below exists for everything that survives that first filter: the workloads where the fit is imperfect, the costs are compounding, or the process itself is part of how you compete.
The five signals that SaaS has become the bottleneck
1. Per-seat economics inverted at scale
SaaS pricing is designed to be trivial at 50 seats and painful at 5,000. As a rough illustration, a tool at AED 350 per user per month across 2,000 users is AED 8.4 million a year, every year, with contractual uplifts. A custom replacement for the specific workflows you actually use might cost a low single-digit multiple of one year's licence fee to build, then a fraction of that annually to run. Run the ten-year total cost of ownership, not the three-year, because the SaaS line compounds and the build line doesn't. Industry TCO studies typically find the crossover for large deployments lands between years three and five.
2. Data residency and sovereignty constraints
For UAE enterprises, this signal has hardened from preference to requirement in several sectors. If your regulator, your DIFC or ADGM data protection obligations, or your government clients require data to stay in-country, and your vendor's nearest region is Frankfurt, you are one audit away from a forced migration. Custom software deployed on UAE-region cloud infrastructure makes residency a design decision you control rather than a roadmap item you lobby a vendor for. With the D33 agenda pushing more of the economy through digital channels, expect scrutiny here to increase, not relax.
3. Integration ceilings
Every SaaS product integrates well up to the boundary of its commercial interest and poorly beyond it. The tell is when your architecture diagram shows middleware compensating for what the vendor's API won't expose: rate limits that throttle your syncs, webhooks that don't cover the events you need, export formats that lose fidelity. When integration workarounds become a permanent line item, you're paying custom-software costs for someone else's product.
4. Process mismatch you've stopped noticing
The most expensive SaaS failure mode is invisible: the organisation reshapes its process to fit the tool, and the friction gets booked as "how things work" rather than as a cost. Audit this directly. Count the offline steps, the spreadsheet exports, the approval flows that happen in email because the tool's workflow engine can't model yours. If a differentiating process, how you underwrite, how you allocate, how you serve, has been bent around a vendor's data model, the strategic cost dwarfs the licence fee.
5. Vendor risk concentration
Price captivity, acquisition risk, deprecation risk, and roadmap divergence all grow with dependence. A useful stress test: if this vendor doubled prices at renewal or sunset the product with 12 months' notice, what would it cost to respond? If the answer is "we'd have no choice but to pay," you've located a negotiation position, theirs.
A scoring model you can defend
Steering committees don't reward instinct, they reward auditable reasoning. Score each candidate workload from 1 to 5 on six criteria, weighted for your context:
| Criterion | Favours build when... | Suggested weight |
|---|---|---|
| Strategic differentiation | The process is part of how you win | 25% |
| 10-year TCO delta | Licence costs compound past build costs | 20% |
| Data residency & compliance | Requirements exceed vendor's roadmap | 20% |
| Integration fit | Workarounds are permanent, not transitional | 15% |
| Process fit | The tool bends your process, not vice versa | 10% |
| Vendor risk exposure | Exit costs make you price-captive | 10% |
A weighted score above roughly 3.5 justifies a build business case; between 2.5 and 3.5, consider a hybrid (buy the commodity core, build the differentiated edge on top of it); below 2.5, buy and renegotiate. The exact thresholds matter less than the discipline: score every workload the same way, document the inputs, and the decision survives personnel changes and audit questions.
Two adjustments worth making for a UAE context. Weight residency higher if you serve government or regulated financial clients. And weight TCO honestly on the build side too: include maintenance, hosting, security patching, and the internal product ownership a custom system needs. A build business case that shows zero ongoing cost is not conservative, it's fiction, and a committee should treat it as such.
The hybrid pattern most enterprises actually land on
In practice, the mature answer is rarely pure. The pattern we see work: keep commodity SaaS for undifferentiated functions, and build the thin custom layer where your differentiation lives, the portal your clients actually touch, the workflow engine that encodes how you operate, the integration spine that makes the SaaS estate behave like one system. This keeps build scope small and defensible while capturing most of the strategic upside. It also sequences well with modernisation programmes; if you're already mapping a path off legacy systems, the build-the-edges pattern slots into it directly, and our guide on taking legacy systems to an AI-ready state covers that sequencing.
There's a forward-looking reason to favour this pattern in 2026 specifically. AI and automation initiatives need clean, controllable access to your operational data and workflows. SaaS tools expose what their roadmap allows; systems you own expose what your strategy requires. Enterprises positioning for the D33 decade are increasingly treating owned software at the differentiated edge as AI infrastructure, not just as applications.
Governance for the build you approve
If a workload scores toward build, de-risk the execution the same way you'd de-risk any capital project. Insist on mainstream technology (frameworks like Next.js and React mean any competent team can maintain the asset, protecting you from partner captivity, the build-side version of vendor risk). Contract for code ownership and full handover from day one. Phase the delivery so working software appears in weeks and the committee reviews evidence, not status decks. And assign internal product ownership before the build starts; custom software without an owner degrades into next decade's legacy problem.
Frequently Asked Questions
Isn't custom software always riskier than SaaS?
Delivery risk is real but has fallen sharply with modern frameworks and phased delivery, while SaaS carries its own risks, price captivity, residency gaps, roadmap divergence, that compound silently. The honest comparison is risk-adjusted ten-year cost on both sides, not build risk against an assumed-safe subscription.
How do I present the TCO comparison credibly?
Model ten years, include contractual SaaS uplifts and seat growth on the buy side, and include maintenance, hosting, and internal ownership on the build side. Have finance validate the assumptions before the committee sees them. A TCO model that survives a CFO's scrutiny is the single strongest asset in the business case.
What team do we need to maintain a custom build?
Less than most committees fear. A well-built system on mainstream technology typically needs a part-time product owner internally and a maintenance arrangement with the development partner, scaling up only if the system becomes a platform. The contract should make switching partners viable, which keeps that arrangement honest.
Where does buy-vs-build sit in a wider transformation roadmap?
Treat it as a portfolio decision, not a one-off. Score every significant workload annually, because the answer changes as seat counts grow, regulations tighten, and vendor roadmaps drift. Most enterprises find two or three workloads flip from buy to build over a transformation cycle, and catching the flip early is where the value is.
If you have a workload sitting in that uncomfortable middle, scoring too high to renew without questions, too uncertain to build without evidence, that's exactly the assessment our web app design and development team runs, alongside our broader digital transformation practice for the roadmap around it. We'll pressure-test the scores with you before anything gets built. Reach us at team@ins.ae or +971 58 995 4553.
