A UAE government technology procurement almost always reads as a request for a system. The document asks for a citizen portal, a workflow engine, a dashboard, a records platform, with features, screens, and a launch. The entity believes it is buying a system, the vendors price a system, and the evaluation scores a system. By the time the work is underway, everyone involved has discovered the same thing: the system was the small part. What was actually procured, and what actually consumes the budget, the timeline, and the risk, is integration into an existing estate of identity layers, systems of record, other entities, and central reporting. The gap between the stated buy and the actual one is where most public-sector delivery difficulty lives.
This piece is a perspective on the difference between what UAE government entities state they are procuring and what they are actually procuring in 2026. The argument is opinionated. We are not arguing that entities are naive or that vendors mislead. We are arguing that mature digital government changes what a technology procurement is: in an environment with a national identity layer, established central platforms, and entities that already hold the systems of record, almost every new system is mostly an integration into that estate; that the visible system is a small fraction of the delivered work; and that procurements scoped and priced as systems systematically under-account for the integration that is the actual deliverable. The entity is not buying a system with some integration. It is buying integration with a system on top.
The audience for this analysis is procurement, digital, and programme leads in UAE government entities, and the teams that deliver for them, who have seen technology projects scoped as systems run into the integration estate and absorb their contingency there. The useful diagnostic question is not "what system are we buying" but "of the work that will actually be done, how much is the system and how much is integrating it into identity, the systems of record, the other entities, and central reporting, and did the procurement price that".
What the RFP Says Versus What Gets Delivered
Below is a representation of common government technology procurements, each shown two ways: what the procurement states it is buying, and what delivery actually turns out to be, with the integration surface the price rarely reflects listed underneath. The point is not that the stated system is unimportant; it is that it is the visible fraction over an integration estate that is most of the work, and that scoping the visible fraction is what produces the overruns. Select a procurement type to see the gap and the surface.
Government procurements: the stated system versus the delivered integration
Select a procurement type to see the gap and the integration surface
Why Mature Digital Government Changes What Is Being Bought
The reason the stated-versus-actual gap is structural is the maturity of the environment the system has to live in. The UAE Digital Government direction, a national identity and sign-in layer, established central platforms, and entities that already operate their own systems of record mean a new system is almost never green field. It has to authenticate against the national identity layer, exchange with the entities that own the underlying services, feed central and cross-entity reporting, and sit inside the information-assurance regime the entity operates under. Each of those is integration into something that already exists and that the new system does not control. The more mature the digital estate, the larger the share of any new system that is integration rather than system, because there is more existing estate it must connect into correctly.
This inverts the intuitive cost model. A procurement scoped around screens and features prices the part that is visible in a demonstration, which is the system. The part that determines whether the system works in the entity's reality, the integration into identity, the systems of record, the inter-entity steps, and central reporting, is not visible in a demonstration and is routinely the larger and riskier body of work. Pricing the visible part and discovering the invisible part is the characteristic shape of a public-sector technology overrun, and it is a scoping consequence, not a delivery failure.
This is why the difficulty is structural rather than a matter of weak vendors or weak entities. A capable vendor can build the stated system well and the programme can still overrun, because the contingency was sized for system risk and consumed by integration risk that the procurement never named. The entity that is exposed here is not the one that chose a poor vendor; it is the one whose procurement described a system when the deliverable was an integration, so the plan, the price, and the evaluation were all aimed at the small part.
The shift in one observation
A government procurement that reads as a system buys a system and discovers an integration. In a mature digital estate the new system is the visible fraction over identity, systems of record, other entities, and central reporting, and that integration is most of the work and most of the risk. The entities whose programmes hold their plan are the ones whose procurement named the integration as the deliverable, not the ones who priced the screens.
Where the System-Framed Procurement Breaks
The system-framed procurement breaks in four predictable places once delivery meets the estate.
Identity and inter-entity steps under-scoped
Authentication into the national identity layer and steps another entity owns are integration into things the project does not control. Scoped as features of the system, they are sized too small, and the dependency on another party's readiness is discovered rather than planned.
Source reconciliation priced as a dashboard
A dashboard procurement prices the charts and under-prices the data engineering and definition reconciliation across inconsistent source systems, which is most of the actual work. The number that looked deliverable was the surface; the comparable, governed data underneath was not in the price.
Contingency sized for the wrong risk
Contingency calculated against system-build risk is consumed by integration risk it was never meant to cover. The programme is not over-running its own work; it is over-running into work the procurement did not describe, which is harder to defend and to recover.
Evaluation rewards the visible fraction
When the procurement describes a system, the evaluation scores the system: features, screens, references. The integration capability that actually determines delivery success is not what the scoring weighs, so the selection is optimised for the small part of the job.
The Numbers
Two Ways to Frame the Procurement
The difference between entities whose programmes hold their plan and those whose overrun is whether the procurement is framed as a system or as an integration.
| Dimension | System-framed | Integration-framed |
|---|---|---|
| What is described | Screens, features, a launch. | The estate it must connect into, with the system on top. |
| Pricing | The visible fraction. Integration discovered later. | The integration surface, sized as the main deliverable. |
| Contingency | Sized for system-build risk. | Sized for integration and dependency risk. |
| Evaluation | Scores features and references. | Scores integration capability into a known estate. |
| Dependencies | Another entity's readiness discovered mid-delivery. | Named and planned as part of the scope. |
A government programme that overruns has usually not failed at its own work. It has run into work the procurement never described, because the document bought a system when the deliverable was an integration into an estate that already exists. Naming the integration is the cheapest risk reduction available, and it happens before any code.
What an Integration-Framed Procurement Looks Like
The pattern in entities whose programmes hold their plan is recognisable. The procurement describes the estate the new capability has to connect into, the national identity layer, the systems of record, the inter-entity steps, the central reporting, and treats the system as what sits on top of that integration rather than as the whole deliverable. The price is built around the integration surface, so the budget reflects the work that will actually be done. Contingency is sized for integration and dependency risk, the risk that actually materialises. The evaluation scores integration capability into a known estate, not just features in a demonstration. Dependencies on other entities are named and planned rather than discovered. The system still matters and is still built well; it is simply understood as the visible part of an integration, which is what it is.
This is a scoping and capability question more than a tooling one, and it does not require any particular platform. In many entities the right move is to establish the integration surface during discovery and frame the procurement around it, so the plan and price match the deliverable. Where the estate is poorly documented, that discovery is itself the highest-value early work, because it converts invisible integration risk into a named, plannable scope. What is right is specific to the entity's estate, and is established before the build is committed.
How This Sits Alongside the Entity's Own Responsibilities
The configuration keeps a clear separation. The government entity owns the policy, the service, the procurement decision, the data, and its own compliance with the information-assurance and procurement regimes it operates under. The software work is the delivery: integrating the new capability correctly into the entity's estate and building the system that sits on it.
This is the role BY BANKS is positioned for. We are an independent software engineering company based in the UAE. We design and build software and hand it over to the entity that runs it. We do not own government policy or services, make procurement determinations for an entity, or act for any central authority, and we are not affiliated with or endorsed by any government body. The entity owns the policy, the procurement, the data, and its own compliance; we deliver the integration and the system to its direction and within its assurance regime. The accountable party leads and owns the obligations; we build to their direction.
Where This Analysis Is Useful
The conversations where this perspective is most useful tend to be at three moments: an entity scoping a technology procurement that wants the plan and price to match the deliverable rather than the demonstration; a programme lead whose contingency is being consumed by integration the procurement never named; or a digital team that keeps seeing system projects stall against the estate. The honest answer is usually the same: the deliverable is mostly integration, the system is the visible fraction, and naming the integration in the procurement is the cheapest risk reduction available.
For broader related work, see our perspective on what ICV scoring actually rewards and our perspective on why Dubai customs is a layered integration problem. The applied work sits across our government procurement software and public-sector digital transformation capabilities, within the broader government software development practice and our technical consultancy work. Get in touch if a 45-minute conversation about a specific procurement would be useful.
Frequently Asked Questions
No. We are an independent software engineering company based in the UAE. We design and build software and hand it over to the entity that runs it. We do not own government policy or services, make procurement determinations for an entity, or act for any central authority, and we are not affiliated with or endorsed by any government body. On any engagement, the entity owns the policy, the procurement, the data, and its own compliance with the regimes it operates under. We deliver the integration and the system to the entity's direction; the entity owns the decisions.
No. The system matters and has to be built well; it is the part the public and the users experience. The argument is about proportion and framing: in a mature digital estate the system is the visible fraction of a delivery that is mostly integration, and procurements that describe only the system mis-size the work. Build the system well, but scope and price the integration as the main deliverable, because that is what it is.
No. They are observational generalisations of how government technology delivery commonly differs from procurement framing, used to make the scoping point clear. They describe no specific entity, procurement, system, or determination. The authoritative scope of any procurement is defined by the entity and its procurement and assurance regimes, not by this article.
No. This is a scoping and capability point, not a platform pitch. It does not require any particular product. The highest-value early work is usually establishing the integration surface during discovery so the procurement is framed around the real deliverable. What is right is specific to the entity's estate and is established before any build is committed; the tooling follows the scope, not the other way round.
It can still help. For a procurement in flight, mapping the integration surface that the document under-described converts invisible risk into a named scope, which can be managed through change control, dependency planning, and re-baselining rather than discovered later as overrun. For one not yet issued, the same mapping done in discovery lets the procurement be framed around the deliverable from the start. The order is driven by where the unnamed integration risk currently concentrates, which discovery establishes for the specific programme.
UAE government technology procurement is widely framed as buying a system and is in practice buying integration into an estate that already exists, with the system as the visible fraction on top. The entities whose programmes hold their plan are the ones whose procurement named the integration as the deliverable, sized the price and contingency around it, and evaluated integration capability rather than scoring screens. The build is software work; the policy, the procurement decisions, the data, and compliance with the entity's assurance and procurement regimes remain entirely the entity's, and the work simply delivers the integration the procurement should have described, with the system correctly sitting on top of it rather than mistaken for the whole of it.
References to UAE digital government direction, national identity infrastructure, and central platforms are descriptive of publicly known frameworks. This article cites no market figures; the cases and integration surfaces are observational generalisations of how delivery commonly differs from procurement framing, and represent no specific entity, procurement, or determination. Patterns and observations reflect our perspective and are observational estimates rather than measured statistics. BY BANKS is an independent software engineering company; we do not own government policy or services, make procurement determinations for an entity, or act for any central authority, and we are not affiliated with or endorsed by any government body. On any engagement, the entity owns the policy, the procurement, the data, and responsibility for its own compliance with the regimes it operates under. This article is not procurement, regulatory, or legal advice; entities should obtain qualified advice for their specific obligations. 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