There is a pattern that plays out repeatedly in South African public-sector technology. A department commissions a website. The website is built. It is launched at a function, photographed for the annual report, and presented as evidence that the department has gone digital.
Six months later, the website still exists. Barely anyone uses it. The processes it was supposed to support still run on paper, on WhatsApp groups, and in people's heads. The citizens it was supposed to serve do not trust it, cannot navigate it, or do not know it exists. The department has not changed how it operates. It has only added a website.
This is not a technology failure. It is a framing failure. Digital transformation in government is not about building digital assets. It is about redesigning how services are delivered — and the website, if one is needed at all, is a thin surface layer on top of a much deeper and more complex system.
A website is not a service
A government service is a promise. It says: if you qualify, we will do something for you. Enrol your child. Issue your permit. Investigate your complaint. Pay your grant. Help you find work.
Delivering on that promise requires more than a web address. It requires a process for intake — capturing the request, verifying identity, confirming eligibility. It requires a workflow for processing — routing the request to the right person, at the right time, with the right information. It requires integration with other systems — identity verification, eligibility databases, payment systems, document stores. It requires a way to communicate back to the citizen — status updates, decision notices, next steps. And it requires operational capability — the people, tools, and management structures that keep the service running after the launch.
None of this is a website. A website can be one of the touchpoints through which a citizen accesses the service. It is not the service itself.
Departments that start with the website — and think of the website as the product — build the wrong thing. They create a digital surface with no operational infrastructure underneath it. The surface looks good in demonstrations. It does not work in practice.
The eight layers of a proper digital service
A public-sector digital service is not a single system. It is an architecture of eight interconnected layers. Skipping any of them is what causes projects to succeed in the demo environment and fail in deployment.
1. Citizen journey
Before any technology is built, the service team needs to understand how a citizen actually experiences the service — not how the department believes they experience it. What prompts the need? How does the citizen find out the service exists? What do they need to bring? What steps do they go through? Where do things go wrong today? What happens if they make a mistake?
This is service design work, not technology work. It requires direct engagement with the citizens who use the service — not just the officials who administer it. The citizen journey is the design foundation for everything else. Get it wrong and the technology will simply automate a bad experience.
2. Service catalogue
A service catalogue is a clear, structured definition of what the service provides: who it is for, what it does, what the eligibility criteria are, what documents are required, what the expected processing time is, and what the outcome looks like.
Many government departments cannot articulate their own services with this precision. They have legislation, policies, and forms, but not a clean service definition that a citizen, a call centre agent, or a digital system can work from consistently.
Building the service catalogue is typically one of the first deliverables in a well-run digital services programme. It forces clarity about what is being built before any technology decisions are made.
3. Forms and intake
The digital intake form is usually the most visible part of a citizen-facing digital service, and the one that receives the most attention during development. But the form is only as useful as the processing capability behind it.
Good intake design means capturing the right information in the right format, with the right validation, at the right point in the citizen's journey. It means designing for the devices and connectivity conditions that South African citizens actually have — often a mobile phone on a limited data plan, with limited digital literacy. It means testing the form with real users before launch, not just with officials who already understand the system.
It also means designing for failure: what happens when a citizen submits an incomplete application, or provides incorrect information, or applies for something they are not eligible for? These are not edge cases. They are the majority of real-world transactions.
4. Case management
Behind every citizen submission is a case. Something needs to be reviewed, decided, escalated, or communicated. In most government departments today, this case management happens in email inboxes, spreadsheets, physical files, or ad hoc systems that were never designed for the volume or complexity of the work.
A digital service without a case management layer has moved the intake online while leaving the processing unchanged. Officials still handle paper. Processing still takes weeks. Citizens still cannot track progress. The only thing that changed is where the citizen started the transaction.
A proper case management system — even a relatively simple one — routes incoming applications to the right officials, tracks their status, sets processing time targets, and creates an audit trail of decisions. This is what makes a service accountable and measurable.
5. Data and reporting
Public-sector digital services create data that should be used to manage the service and improve it over time. How many applications were received? What is the average processing time? Where are the bottlenecks? What percentage of applications are incomplete at submission? What are the most common reasons for rejection?
Without a reporting layer, the department is operating blind. It cannot manage service performance, cannot make evidence-based staffing decisions, and cannot demonstrate outcomes to treasury, oversight bodies, or the public.
Reporting also creates the accountability structure that is essential for public-sector service delivery. When the head of department can see, on a dashboard, that processing times have increased by 40% over the past month, they can investigate, intervene, and be held to account in a way that is simply not possible when performance data lives in filing cabinets.
6. Integration
Government services rarely operate in isolation. Identity verification often depends on a connection to the Department of Home Affairs. Eligibility for a social grant depends on income data that may sit with SARS. Payment of a benefit depends on a banking integration. Vehicle licence renewals require data from the traffic register.
These integrations are technically complex and often politically complex. They require inter-departmental cooperation, data sharing agreements, API access, and security controls. They are also frequently the part of a digital service project that runs over time and over budget — because they are underestimated, deprioritised, or treated as someone else's problem.
Designing for integration from the start — understanding which external systems the service depends on and what the realistic pathway to connecting with them looks like — is essential to building something that will actually work in production.
7. Security and POPIA
Government digital services process personal information about citizens. POPIA places clear obligations on how that information is collected, stored, used, and protected. These obligations are not optional and they are not only triggered when something goes wrong.
Security architecture for a public-sector digital service needs to consider access controls, authentication, encryption, data residency, audit logging, penetration testing, and incident response. In a cloud-hosted environment, it also needs to consider the contractual and compliance implications of where data is physically stored and who can access it.
Security should be designed in, not bolted on. The most expensive security failures in government digital projects are the ones where a system was built without adequate security controls and then had to be partially rebuilt after a breach or audit finding.
8. Operations and support
The most consistently underestimated layer. Building the service is not the end of the project. It is the beginning of the operational phase — which can run for years or decades.
Who monitors the service for outages? Who handles citizen support queries that the digital channel could not resolve? Who manages the vendor relationships? Who decides when to update the service? Who trains new officials on the system? Who pays for hosting and maintenance?
Departments that build digital services without designing the operational model are creating technical debt with a launch date. The service degrades, officials work around it, and eventually it is quietly abandoned while a parallel paper process continues.
Sustainable digital services in government require a named operational owner, a support model, a maintenance budget, and a continuous improvement mechanism from day one.
Why MVP thinking matters in government
None of this means that a department must build all eight layers at once before any digital service can go live. That approach leads to the large multi-year transformation programmes that consume enormous budgets and frequently deliver nothing, or deliver systems that were obsolete before they launched.
The alternative is a disciplined MVP approach: identify the one service journey that is most valuable to fix, build the minimum set of layers required to make it work properly, go live with that, and learn before expanding.
A well-designed 90-day government MVP can demonstrate that the journey works, that citizens use it, that officials can process through it, and that the integration points are viable — all without the risk and cost of a full transformation programme. That evidence is what justifies the investment to scale.
The MVP does not skip the eight layers. It scopes them intelligently for the specific service being launched. Citizen journey: yes, for one service. Forms: yes, for one intake flow. Case management: yes, minimal but functional. Integration: only what is strictly necessary for that service. Operations: designed upfront, not as an afterthought.
Work with CloudNala
CloudNala helps public-sector teams move from a website to a service — designing the citizen journey, the processing workflow, the data architecture, and the operational model that makes digital services work in practice.
Whether you are starting a new digital services initiative, rescuing a programme that stalled, or planning a 90-day MVP for a specific citizen service, we can help you frame it correctly from the start.
Start a Digital Discovery Sprint or write to us at consult@cloudnala.co.za