When a citizen-portal project goes badly, the post-mortem usually looks at the build. The technology choice, the vendor, the integration work, the testing. That is where the visible failure happened, so that is where the explanation is sought. It is also why the same kind of project fails the same way repeatedly across UAE entities: the outcome of a citizen-portal project is mostly determined before development starts, by a small set of pre-build conditions that were either secured or assumed. The build does not decide the project. It executes a verdict that was already reached, and most projects reach that verdict without anyone having assessed it.
This piece is a perspective on why citizen-portal projects in the UAE succeed or fail before any code is written. The argument is opinionated. We are not arguing that delivery quality does not matter, or that vendors are blameless. We are arguing that a handful of pre-build factors, identity integration access, service-owner data commitments, decision rights, service definition, and the assurance regime, set the project's trajectory; that these are commitments and definitions rather than technical tasks; and that the projects which fail are usually the ones that started development with those factors assumed rather than secured. The build is where the consequence becomes visible, not where the cause lives.
The audience for this analysis is digital, programme, and procurement leads in UAE government entities planning or running citizen-portal projects who have seen one stall and want to know whether the next one will, before it is too expensive to change. The useful diagnostic question is not "is the build going well" but "of the factors that actually decide this project, how many are secured commitments and how many are assumptions we have not tested".
The Pre-Build Readiness Check
Below is the small set of factors that decide a citizen-portal project before development starts. Set each to where it honestly stands and read the verdict. The point is not the scoring; it is that an unassessed factor is an assumed one, and assumed pre-build factors are precisely the ones that surface as overrun after the budget is committed. Closing a gap here, before any code, is the cheapest risk reduction the project will ever have access to.
Citizen-portal pre-build readiness
Set each factor to where it honestly stands and read the verdict
Why the Pre-Build Factors Decide the Outcome
The reason these factors are decisive is that they are dependencies the build cannot create for itself. A citizen portal is, by nature, a surface over services other entities and systems own. It needs to authenticate citizens through the national identity layer, draw data and status from the back-office systems that own each service, and operate inside the entity's assurance regime. None of those is something the development team can build unilaterally; each is a commitment from another party or a definition the entity must supply. When development starts before they are secured, the team is building against assumptions, and the project's progress becomes hostage to confirmations it does not control.
The UAE environment makes this sharper rather than softer. Mature digital government means a citizen portal is rarely standalone; it sits over an estate of established platforms, the national identity layer, and multiple service-owning entities, and it is judged against the digital-government expectations citizens already have from other services. The more integrated the estate, the more of the project is dependency on others being ready, and the less of it the build controls. An entity that treats those dependencies as build tasks rather than pre-secured commitments has mis-located the part of the project that determines its fate.
This is why the failure is structural rather than a delivery weakness. A capable team can build a good portal and the project can still fail, because a portal cannot display a status a service owner never agreed to expose, cannot personalise without the identity dependency, and cannot finish while a policy decision sits unresolved between entities. The entity that is exposed here is not the one that picked the wrong vendor; it is the one that started the build with the deciding factors assumed, so the project was running to a verdict reached before the first sprint.
The shift in one observation
A citizen-portal project read as a build problem produces a post-mortem about technology and vendors. Read as a readiness problem, it produces an assessment done before development starts, when the deciding factors can still be changed cheaply. The projects that fail are rarely the ones that built badly. They are the ones that started building before the factors that decide the outcome were secured.
Where Starting Without Readiness Breaks
Beginning development with the pre-build factors assumed breaks in four predictable places.
Identity dependency assumed
If sign-in through the national identity layer is an assumption rather than a secured, scoped dependency with access and timeline confirmed, nothing personalised works until it is resolved, and the whole portal waits on a confirmation the build does not control.
Service owners not committed
A portal can only show what the owning systems and entities agree to expose. When that commitment is not in place before the build, the portal is built around data it never receives, and the gap is found in integration testing, the most expensive place to find it.
Decisions with no single owner
When cross-entity and policy questions route through several bodies with no accountable owner, the project stalls on unresolved decisions far more than on code. The build idles while a question that should have been settled pre-build is debated.
Services defined in brochure terms
A service described in brochure language rather than to the level of the actual transaction, rules, exceptions, documents, turns definition into discovery during the build. Discovery at build time is the costliest version of work that was cheap to do beforehand.
The Numbers
Two Ways to Start a Portal Project
The difference between citizen-portal projects that finish close to plan and those that stall is whether the pre-build factors were secured or assumed before development started.
| Factor | Assumed at kick-off | Secured before build |
|---|---|---|
| Identity access | Presumed available, resolved mid-build. | A scoped dependency with access and timeline confirmed. |
| Service owners | Expected to cooperate when asked. | Committed to the data and status the portal needs. |
| Decision rights | Diffuse, decisions stall the build. | One accountable owner who can resolve quickly. |
| Service definition | Brochure level, discovered during build. | Defined to the transaction before build starts. |
| Assurance regime | A late compliance gate forcing rework. | Understood and designed for from the start. |
A citizen-portal project that fails has usually not been built badly. It has been started before the factors that decide it were secured, so the build spent its budget running to a verdict reached before the first sprint. The cheapest version of fixing that happens before any code.
What a Build-Ready Project Looks Like
The pattern in citizen-portal projects that finish close to plan is recognisable. Identity integration is a secured, scoped dependency with access and timeline confirmed before the build, not an assumption. The service-owning entities and systems have committed to exposing the data and status the portal needs, so it is built around data it will actually receive. One accountable owner can resolve cross-entity and policy questions quickly, so the build is not idled by unresolved decisions. Each service is defined to the level of the real transaction before development, so definition is not rediscovered during the build. The assurance and data regime is understood and designed for from the start rather than met as a late gate. In that state, the build is mostly an execution problem, which is the kind that finishes close to plan.
This is a readiness and discovery question more than a tooling one, and it does not depend on any particular platform. In most entities the highest-value early work is establishing and securing these factors before committing the build, because that is where the project's outcome is actually set. Where the factors cannot all be secured pre-build, knowing which are not is itself the result, because it converts an invisible risk into a planned dependency. What is right is specific to the entity and the services, 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 services, the policy, the procurement decision, the citizen data, the relationships with the identity layer and other service-owning entities, and its own compliance with the assurance regime it operates under. The software work is the delivery: building the portal and its integrations once the entity has secured the pre-build factors, and helping make those factors visible during discovery.
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 services or policy, secure inter-entity commitments on an entity's behalf, make procurement or assurance determinations, or act for any central authority, and we are not affiliated with or endorsed by any government body. The entity owns the services, the commitments, the data, and its own compliance; we deliver the portal to its direction and can help surface the readiness factors during discovery. 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 planning a citizen portal that wants to know its real risk before committing the build; a programme lead whose project is stalling on confirmations and decisions rather than code; or a digital team reviewing why a previous portal overran and finding the cause sits before the first sprint. The honest answer is usually the same: the outcome is mostly set by the pre-build factors, most of them are commitments not code, and securing them first is the cheapest risk reduction the project will get.
For broader related work, see our perspective on what UAE government entities are actually procuring and our perspective on why UAE payment certification is a data problem. The applied work sits across our citizen portal development and UAE Pass integration platform capabilities, within the broader government software development practice and our technical consultancy work. Get in touch if a 45-minute conversation about a specific portal project 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 services or policy, secure inter-entity commitments on an entity's behalf, make procurement or assurance determinations, 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 services, the commitments, the citizen data, and its own compliance. We deliver the portal to the entity's direction and can help surface readiness during discovery; the entity owns the decisions.
No. It is an observational reasoning aid to make the pre-build point concrete, not a methodology, certification, or assurance assessment, and it describes no specific entity or project. The factors that matter and their weighting differ by entity and by the services involved. A real readiness assessment is done with the entity against its specific estate and obligations, not from this aid.
No. Those commitments are between the entity and the identity layer and the other service-owning entities, and only the entity can secure them; they are governance and policy matters, not software ones. What we can do is make the dependencies explicit and specified during discovery, so the entity knows exactly what it needs to secure and the build is not started on assumptions. Securing them remains the entity's responsibility.
It is more expensive than doing it pre-build, but still worth doing. For a project already running, assessing which pre-build factors were assumed rather than secured converts hidden risk into a managed set of dependencies that can be handled through replanning and change control rather than discovered later as overrun. The earlier in the build this is done, the cheaper the correction; the most expensive option is to keep building on the assumptions.
It is applied as discovery work before the build is committed: establishing each pre-build factor's true state, securing what can be secured, and naming what cannot as explicit dependencies in the plan and procurement. The order is driven by which factors carry the most schedule risk if assumed, which discovery establishes for the specific entity and services. The build is committed once the readiness picture is real rather than presumed.
Citizen-portal projects in the UAE are widely diagnosed at the build and are in practice decided before development starts, by a small set of pre-build factors that were secured or assumed. Most of those factors are commitments and definitions other parties own, not code the build team can produce, which is why a capable team can still deliver a failing project when the factors were assumed. The entities whose portals finish close to plan are the ones that secured the readiness before committing the build. The build is software work; the services, the inter-entity commitments, the citizen data, and compliance with the assurance regime remain entirely the entity's, and the work simply delivers the portal once the factors that decide it are real rather than presumed, and helps make those factors visible while they can still be changed cheaply.
References to UAE digital government direction, the national identity layer, and information-assurance expectations are descriptive of publicly known frameworks. This article cites no market figures; the readiness factors and verdicts are an observational reasoning aid, not a methodology, certification, or assessment, and represent no specific entity, project, 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 services or policy, secure inter-entity commitments on an entity's behalf, make procurement or assurance determinations, 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 services, the commitments, the citizen data, and responsibility for its own compliance with the regimes it operates under. This article is not procurement, assurance, 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