Every public-sector digital programme starts with ambition. A department wants to move its services online, reduce queues, cut paper and give citizens a better experience. The business case is approved. A vendor is appointed. A steering committee meets monthly.
Eighteen months later, almost nothing is live. The project is in testing. The testing reveals integration problems nobody anticipated. The integration problems expose a data quality issue nobody quantified. The data quality issue reveals a process disagreement that nobody resolved. The steering committee is still meeting monthly.
This is not a South African problem. It is a universal pattern in government technology. The ambition is genuine. The failure is structural — caused not by bad intentions but by trying to solve every problem at once.
There is a better approach. Instead of designing the full transformation programme before writing a single line of code, a government team can scope a focused, time-boxed MVP that targets one service journey, one set of users and one measurable outcome — and go live in 90 days. That evidence then justifies scaling.
What a 90-day MVP should and should not do
A 90-day government MVP is not a proof of concept that gets shelved. It is not a demo environment that only works in a conference room. It is not a website with placeholder content that says "coming soon."
It is a working, live, operational service that real citizens can use and that real officials can process — even if it serves only one function, for one specific group, in one channel.
What it should do:
- Deliver one end-to-end citizen service journey, from intake to outcome notification
- Support real processing by officials, not just a digital intake form with a manual backend
- Include a basic reporting layer so the department can see what is happening
- Be designed with the operational model in place from day one — not bolted on after launch
What it should not do:
- Attempt to replace every paper process in the department
- Solve every integration problem before going live
- Require a full procurement cycle for new infrastructure
- Wait for policy decisions that are months away from being finalised
- Depend on organisational changes that are still being negotiated
The MVP succeeds when it proves that the journey works, that citizens actually use it, that officials can process through it without workarounds, and that the underlying data flows are viable. That is enough. Everything else can follow.
The four phases
Phase 1: Discovery (weeks 1–3)
Discovery is not a planning exercise. It is a fact-finding exercise. The team needs to understand the service as it actually operates today — not as the policy document describes it.
The discovery phase should answer:
- Which service journey is most valuable to fix and most achievable to digitise in 90 days?
- Who are the citizens who use this service, what are their access conditions, and what devices are they likely to use?
- What does the current process look like, from the citizen's first point of contact to the final outcome?
- What data is required, and where does it live today?
- Which external systems does this service depend on, and what is the realistic pathway to connecting with them?
- Who in the department will own the service operationally after launch?
The output of discovery is a scoped service definition: a clear description of what the MVP will do, what it will not do, and what the success criteria are. This document should be short and agreed by all parties before phase 2 begins.
Many government programmes skip or compress discovery because it does not look like progress. This is why they stall in phase 3 when the assumptions made in phase 1 turn out to be wrong.
Phase 2: Prototype (weeks 3–6)
The prototype is a working version of the service, built against the scoped service definition. It is not a wireframe. It is not a presentation. It is a system that can be tested with real users.
For a typical citizen-facing service, the prototype includes:
- The citizen intake flow — the form or interface through which a citizen submits their request or accesses the service
- The official processing interface — the view that lets an official receive, review, assign and decide on an application
- Basic case tracking — a way for the citizen to check the status of their submission
- At least one integration — even if it is a manual stub that will be replaced later
Prototype decisions should favour speed over completeness. Use a low-code platform if it allows the team to build faster without compromising security. Use cloud-hosted infrastructure that can be provisioned quickly. Avoid bespoke solutions where commercial options exist.
The prototype phase ends with a round of structured user testing — not internal review, but sessions with actual citizens and actual officials, using the actual system. The findings from these sessions determine what gets fixed before the pilot.
Phase 3: Pilot (weeks 6–10)
The pilot is a controlled live deployment. A defined group of citizens uses the real service, and the department processes their submissions through the real system. Nothing is simulated.
The pilot scope is deliberately narrow: one geographic area, one category of applicants, or one channel. This limits exposure if something goes wrong while generating real data about how the service performs in practice.
During the pilot, the team monitors:
- Completion rates — what percentage of users who start the intake flow finish it?
- Drop-off points — where are users abandoning the process, and why?
- Processing times — how long is it taking officials to process submissions end to end?
- Error rates — how many submissions are incomplete, duplicate or ineligible?
- Support queries — what questions are citizens asking that the service did not answer?
This data is more valuable than any amount of pre-launch testing. It reveals what actually confuses users, where officials need more support, and which assumptions in the original service design were wrong.
The pilot phase ends with a documented set of findings and a clear go/no-go recommendation for full rollout.
Phase 4: Operational handover (weeks 10–12)
The fourth phase is what most government digital projects leave out entirely. Before the MVP scales, the operational model needs to be formalised.
Operational handover includes:
- Assigning a named service owner within the department — someone accountable for ongoing performance
- Documenting the support workflow for citizen queries that the digital channel cannot resolve
- Training the officials who will use the system daily
- Establishing a basic service performance dashboard that the department can read without technical support
- Agreeing a maintenance and support arrangement with the technology team
- Scheduling the first post-launch review — typically at 30 days
Without this phase, the MVP becomes an orphan. It works for a few months, starts to degrade, and is quietly worked around. The department reverts to paper. The technology team is replaced.
With this phase, the MVP becomes a foundation — something that can be measured, improved, and used to justify the next iteration.
Example MVP features by service type
Not every service requires the same components. Depending on the type of service, the MVP scope will differ.
Service locator: helps citizens find the nearest service point, office or facility. Relatively low integration complexity. Useful for health, social development and home affairs services. High citizen value because location barriers are a significant access failure point.
Appointment guidance: allows citizens to find out what documents they need to bring before attending a service point. Reduces failed appointments and wasted trips. Can be delivered as a web page, WhatsApp flow or SMS interaction with no backend integration required.
Incident or complaint reporting: allows a citizen to lodge a complaint or report a fault — a broken streetlight, a missed rubbish collection, a service failure. Requires a case management layer but low integration complexity with external systems.
FAQs and knowledge base: answers the most common citizen questions about a service digitally, reducing call centre load and in-person queries. Fastest to build. Lowest risk. Highest reach relative to effort.
Notifications: sends status updates to citizens by SMS or WhatsApp when their application progresses. Can be added to an existing manual process without fully replacing it. Reduces inbound status queries significantly.
Reporting dashboard: gives officials and managers a live view of service volume, processing times and outstanding work. Can be built on top of an existing system without replacing it.
The choice of starting feature should be driven by the discovery findings: where is the highest citizen pain, and where is the lowest technical risk?
How to scale after the MVP
A successful MVP does not automatically scale itself. The decision to scale should be a deliberate choice, made on the basis of the evidence generated in the pilot.
Questions to answer before scaling:
- Did the pilot prove that citizens can use the service without assistance?
- Did officials process submissions within the target time consistently?
- Were the integration points stable under real transaction volume?
- Is the department's operational model ready to handle higher volumes?
- Is there budget for the infrastructure, support and maintenance the full service will require?
If the answers are yes, the MVP has done its job. The department now has something it did not have before the MVP: evidence. Real data about what works. A working system that can be extended. An operational team that understands how to run a digital service.
That evidence is what makes it possible to build phase two — whether that means expanding to additional services, additional channels, additional geographies, or all three.
Work with CloudNala
CloudNala helps public-sector teams design and deliver focused 90-day MVPs that prove the service model without the risk of a full transformation programme. We work across the citizen journey, the processing workflow, the technical architecture, and the operational handover — not just the front end.
Whether you are planning your first digital service, trying to rescue a programme that has stalled, or looking to demonstrate early delivery to a funding or oversight body, we can help you scope and ship something real.
Ask CloudNala to define your 90-day citizen service MVP or write to us at consult@cloudnala.co.za