What should organisations do before building a superapp for public services?

How to scope a superapp before integration starts

A public-services superapp should not begin as a technology build exercise. It should begin as a boundary-setting exercise: define the platform’s mandate, decide which services are platform-governed and which remain independently operated, and specify the trust and evidence flows between them. That early scoping is what prevents the app from becoming a loose aggregation of incompatible controls.

The practical question is not whether one interface can display many services, but whether those services can share user journeys, records, and identity evidence without collapsing ownership or accountability. Once a platform becomes the common front door, every omitted decision about control boundaries turns into an operational decision later, usually under time pressure.

For that reason, the architecture should separate presentation convenience from control authority. A service can be unified in the user experience while still retaining its own policy, data stewardship, and approval logic. That distinction matters most where legal authority, record integrity, or downstream remediation obligations differ across services.

Which governance and evidence decisions must be fixed first?

The first decisions are governance decisions, not interface decisions. Organisations need to map each participating service to a named owner, a decision boundary, and a data-sharing rule set, then define how identity evidence, attributes, or assertions will move across the platform. That includes deciding whether the platform is merely brokering access or actually making authoritative decisions on behalf of source systems.

When those lines are unclear, the superapp tends to absorb responsibility without absorbing control. A central login, shared profile, or common case view can make the system feel integrated while underlying entitlements, consent, and service eligibility still live elsewhere. If the evidence exchange is not explicit, teams end up reusing assumptions instead of verified trust signals.

The same planning discipline applies to services that remain independently controlled. Their APIs, workflows, and approval steps may be visible through the superapp, but visibility does not mean central ownership. Organisations should make sure the architecture can preserve service-level autonomy where policy requires it, while still allowing the platform to present a coherent journey.

That is why governance diagrams should distinguish source of truth, source of decision, and source of presentation. The superapp may aggregate them, but it should not blur them. A clean separation reduces the chance that later integration work turns into a silent transfer of authority.

How privacy, resilience, and AI governance shape the architecture

Public-services superapps usually become sensitive because they concentrate personal data, decision paths, and operational dependencies. Privacy design must therefore be part of the architecture from the start, including data minimisation, purpose limitation, and clear retention and sharing rules. Resilience planning matters just as much, because a shared platform can become a shared outage domain if too many services depend on the same identity, messaging, or orchestration layer.

AI governance should be treated the same way. If the platform uses AI for routing, triage, summarisation, or eligibility support, organisations need to decide what the AI may influence, what must remain human or service-owned, and what evidence is required before any AI-assisted outcome is trusted. The architecture should not assume that AI output is authoritative simply because it is convenient to surface in one app.

Public-facing integration also raises assurance expectations around access control and identity proofing, especially when a superapp becomes the entry point for multiple government services. Relevant controls include the NIST Privacy Framework for privacy risk management, NIST AI Risk Management Framework for AI governance decisions, and NIST Cybersecurity Framework 2.0 for governance, protection, resilience, and recovery planning.

Risk and Threat Considerations

Superapps increase exposure by concentrating trust, data, and access paths. If the platform over-centralises identity, routing, or orchestration, a single design mistake can affect multiple services at once, and a compromise can produce broader blast radius than a standalone application.

Failure mechanism: Weak boundary definition allows one service’s data, decisions, or credentials to be reused by another without proper authorisation or evidence checks. That creates privacy leakage, privilege creep, and dependency failures that are hard to unwind after rollout.

Impact: The organisation can lose service autonomy, over-share personal or eligibility data, and create correlated outage or compromise risk across the entire public-services stack. If AI is embedded in the workflow, an ungoverned model can also amplify bad routing or classification decisions at scale.

Practitioner Guidance

What to prioritise: Start with a service boundary inventory. For each service, record whether the superapp may display it, initiate it, decide it, or merely pass a user into it, and treat those as different control states.

What to verify: Confirm that identity evidence, consent, and authorisation are exchanged through explicit contracts, not through informal API reuse or shared session assumptions. If a service cannot explain what evidence it trusts and why, it is not ready for integration.

Decision rule: If a platform function can change eligibility, access, or case outcome, it needs independent governance review before rollout. If it only improves navigation, the control bar is lower, but the privacy and resilience dependencies still need validation.

Practitioner takeaway: The safest superapp is not the most integrated one, it is the one that makes authority, evidence, and accountability visible before the first service is connected.

Related resources from NHI Mgmt Group

• How should European organisations evaluate SuperApp adoption in regulated markets like banking and public services?
• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?