The DPI frameworks make choosing a first use case sound like a big strategic puzzle. In my experience, most governments already know the answer.
Ask a registrar general what they need first and they'll tell you before you've finished the question: births and deaths.
The short answer: a strong first DPI use case is one people use often or that solves a big pain point, covers a large share of the population, and has a line ministry willing to get behind it. In practice, governments usually know their first use case already, because it comes from their own mandate and daily pain, not from the technology. The job is less about choosing and more about scoping it tightly enough to launch.
Key facts:
What the frameworks say
The Centre for DPI's guidance is sensible. Pick a use case that:
- Solves a regular need or a big enough pain point
- Covers a large part of the population
- Has the relevant line ministry on board
It also makes a useful distinction between the first use case and the first adopter. The use case might be verifying bank statements. The first adopter might be a digital lender using it to approve small loans.
All good. I'd just push back on one thing.
Why governments usually already know
The frameworks are written as if a country is choosing from a menu. That's rarely how it works.
Governments come to DPI with a problem, not a blank page. A civil registration authority knows exactly what it needs: birth and death registration that works, reaches rural areas and produces a legal record. That need doesn't come from the DPI or the DPG. It comes from the mandate, and often from law.
My take: if a consultant spends three months helping a government "discover" its first use case, somebody's billing for the obvious.
Where outside help genuinely earns its keep is scoping. Knowing the use case is easy. Cutting it down to something you can launch in months is hard.
How to scope a first use case
Take birth registration as the example.
| Scope decision | Tight first release | Later phases |
|---|---|---|
| Life events | Births and deaths | Marriages, divorces, adoptions |
| Geography | One or two pilot districts | National rollout |
| Channels | Registration offices and health facilities | Community agents, mobile |
| Integrations | One: ID or health | Statistics, social protection, courts |
| Historical records | Leave for now | Digitise and migrate in batches |
The first release should prove the model, not do everything. The Bangladesh OpenCRVS pilot in 2020 ran in just two locations, one rural and one peri-urban, for 12 months (UN ESCAP).
Signs you've picked the wrong first use case
- The line ministry isn't at the table
- It needs legislation that hasn't passed yet
- It depends on three integrations before anyone sees value
- Nobody outside the ministry will notice when it launches
The legislation one catches people out. In some countries, the law needs updating before a new registration or identity system can go live, and that lag can run to years.
From first use case to infrastructure
The first use case gets you live. The second and third turn a system into infrastructure.
Once births and deaths flow reliably, the same register can feed identity, health planning, vital statistics and social protection. That's the moment it stops being a registry project and starts being DPI. I explain the test in is my system a DPI?
Frequently asked questions
What is a good first use case for DPI? One with frequent use or a big pain point, wide population coverage, and a committed line ministry.
How long does a DPI pilot take? Around three months to go live, with a pilot period to prove the model before scaling.
Should we pilot more than one use case? CDPI suggests exploring three use cases and three first adopters in parallel. In my experience, governments usually have a clear priority already.
Sources
- First use case for DPI, Centre for Digital Public Infrastructure
- OpenCRVS goes live in Bangladesh, UN ESCAP
Scoping a first DPI or CRVS use case? Let's talk.
