Every government agency now operates at least one portal. The mature jurisdictions operate dozens. The strategic question is no longer whether to build a portal — it is how to build one that survives ministry reorganisation, changes of government, and the year-7 vendor refresh. This page describes a sovereign-deployable portal platform: multi-language, accessibility-compliant, identity-federated, and configurable by the ministry team.
Government portals fail in predictable, structural ways. Most are built by an external agency as a fixed-scope project, launch with a press conference, and degrade for the rest of their operational life. Content goes stale because the ministry team cannot update it without an agency call. The portal becomes a static brochure with a contact form, while the actual government services live elsewhere.
The technically-better portals are built on packaged web platforms (Liferay, AEM, Drupal) that the ministry's IT team can update — but the cost is that every new agency wanting a portal triggers a fresh implementation, with no shared identity, no shared design system, no shared component library, and no shared accessibility posture. The estate sprawls.
The strategic answer is a portal platform that is owned by the ministry, shared across agencies, configurable by the ministry team, and architecturally aligned with the rest of the digital-government stack — identity, payment, workflow, notification. Not a portal-as-a-product; a portal-as-a-capability.
The failure patterns are unusually consistent across jurisdictions. That's what makes the solution shape consistent too.
Portal launched by external agency. Initial content perfect. Six months later content is stale because the ministry has no path to update it. Year three the portal is functionally a press archive.
Each agency wants its own portal. Each one is procured separately. Each one uses a different stack, a different design system, a different identity provider. The citizen experiences thirty portals; the centre cannot enforce any consistency.
Portal launches English-first. Arabic version is ‘coming in phase 2’. Phase 2 arrives six months later with content drift between the languages. RTL layout is retrofitted, not designed-in. Citizens whose first language is Arabic experience the portal as second-class.
The procurement said WCAG 2.2 AA. The vendor declared compliance. Nobody on the ministry team can independently verify it. A few months later a citizen with screen-reader needs reports a critical failure. There is no remediation path that doesn't require another agency engagement.
Citizen types a service name into the portal search. Results are five years old. The citizen gives up, calls the call centre. The portal's primary purpose — reducing call centre volume — is structurally undermined by the search nobody fixed.
Modules, integrations, and patterns that compose the solution. Each is configured against the metadata model rather than custom-engineered.
Multi-tenant portal platform. Each agency operates its own portal with its own brand on the same core. Shared identity, shared component library, shared accessibility posture.
Both languages are first-class. No phase 2. No drift. RTL is layout-native. Content published in both languages simultaneously through the same workflow.
Single sign-on across every agency portal. One citizen identity, one log-in, one set of personal preferences carried across the estate.
Search across the full agency portal estate. Citizen searches for ‘family visa’ once; results return from immigration, health, education, housing in unified ranking.
Form publication and editing by the ministry team. No vendor call. Forms inherit identity, payment, and workflow integration automatically. Accessibility validated at publish time.
Continuous accessibility validation built into the publishing pipeline. Independent verification possible by the ministry's compliance team. Third-party audit on roadmap Q2 2027.
Most deployments follow the four-phase pattern below. Subsequent expansions are typically configured by the customer's own team after academy certification.
Agency portal scope, brand guidelines, content migration plan, identity federation plan, search strategy.
Platform configured, brand applied, initial content migrated, identity federation tested, search indexed.
Ministry content team trained on publishing. Accessibility verified. Performance tested under projected load. Production environment ready.
Production launch. Quarterly cadence established for additional agency portals on the shared platform.
Precise pricing is provided in a written proposal after a scoping conversation — see pricing.
Subscription contract. One portal, brand-applied. Ministry team owns publishing. 10–12 weeks to live.
Single platform, multiple agency portals. Shared identity, search, component library. Academy programme for ministry digital team.
Central digital agency holds the platform contract. All agencies onboarded under the central programme. Strategic estate-management capability.
A 45-minute scoping conversation. Written proposal within five business days.