Sri Lanka’s Digital Ambition Is Rather Good. Now for the Bloody Hard Part.

There’s a particular kind of optimism that comes with reading a government digital transformation strategy.

The diagrams are beautiful. Everything connects to everything else. Citizens glide effortlessly between services. Nobody asks you to photocopy your birth certificate for the fourth time.

Then somebody tries to implement it.

And reality arrives, usually carrying a procurement manual thick enough to stop a small-calibre bullet.

I’ve spent a fair chunk of my career working on large technology programmes, including open-source systems intended to improve public services. Enough to know that the distance between a sensible strategy and a functioning service can be measured in years, millions of dollars and the premature ageing of everyone involved.

But Sri Lanka’s digital ambitions interest me for a more personal reason too.

I’m Sri Lankan by ethnicity. I have a vested interest in seeing the country succeed.

And working in digital public infrastructure and digital public goods, I can see the opportunity to make ordinary people’s lives substantially easier.

So I approached the Digital Economy Blueprint 2025–2030 with a mixture of professional curiosity and personal hope.

My assessment?

It’s a pretty bloody good strategy.

Now we need to make sure people actually feel the benefit.

Someone has clearly done their homework

Sri Lanka’s blueprint sets ambitious targets for 2030: a $15 billion digital economy, $5 billion in digital exports and a digital workforce of 200,000.

Targets, of course, are considerably easier to publish than achieve. What interests me more is the thinking underneath them.

The blueprint calls for a platform-first approach, open-source and API-driven technology, shared systems across departments, and investment in talent. It describes reusable digital public infrastructure supporting services across the economy. Source: ICTA’s Digital Economy Blueprint

That’s encouraging.

Instead of every ministry commissioning its own identity mechanism, payment integration and data-sharing arrangements, the idea is to build common foundations that different services can use.

It’s the difference between building a road network and asking every government department to construct its own motorway.

There’s a useful distinction here. Digital public infrastructure, or DPI, provides those shared foundations. Digital public goods, or DPGs, can supply components used to build them.

The terms aren’t interchangeable. Nor does every open-source project automatically qualify as a DPG: the designation involves standards covering matters such as licensing, privacy and contribution to sustainable development. Source: Digital Public Goods Alliance

Choosing reusable technology is sensible. Making the institutions using it work together is where things get interesting.

The first thing people need is a reason to believe

For me, the most important question is how quickly citizens will experience an improvement.

People have heard promises for a long time. Another strategy launch won’t, by itself, persuade someone that their next encounter with a government office will be any different.

A service that saves them a wasted journey might.

So might being able to pay a fee without taking time off work, or finding out whether an application has been approved without visiting the office that received it.

These sound like small things when you’re discussing national architecture. They feel considerably bigger when you’re the person losing a day’s wages.

Early improvements build confidence because people can experience them for themselves.

Government stakeholders need to see progress too. Frontline staff need evidence that a new system will reduce their workload rather than add another screen to an already complicated process.

But a successful internal demonstration isn’t enough. The benefit has to reach the person trying to use the service.

That’s the standard I’d set from the beginning.

A stack of good products can still become a stack of problems

Implementing even one substantial government platform is difficult.

You have to adapt it to operational requirements, connect it to existing systems, establish security arrangements and train the people who will run it. Then you need to keep it working after the implementation team has packed up its laptops.

Now do that across several platforms and institutions, with each depending on the others.

Lovely.

An identity system might work perfectly in isolation. So might payments or an agricultural registry. But who owns the interfaces between them? What happens when one changes? Who resolves a disagreement about standards?

And who gets the phone call at two in the morning when something breaks?

A shared architecture needs clear operating responsibilities, technical leadership and people with the authority to resolve those questions.

Open source doesn’t remove that work.

It can offer transparency, flexibility and freedom from proprietary licence fees. Somebody still has to configure the software, secure it, maintain it and understand it properly.

Selecting a proven digital public good is not the same as selecting a proven implementation partner.

I’d rather see a government work with people who have delivered the relevant platform before than a supplier that has won the contract and is now enthusiastically discovering the documentation.

There’s a time and place for learning on the job. National infrastructure is an expensive classroom.

Government also needs enough internal expertise to challenge suppliers intelligently. Otherwise, it risks replacing proprietary vendor dependence with open-source implementation dependence.

Same problem. Different T-shirt.

Procurement needs to catch up with the work

This is one of my biggest concerns.

Traditional procurement often assumes that you can specify everything before delivery begins, choose a supplier and receive the finished thing.

That can be awkward when discovery reveals that the original requirements were wrong.

With digital public goods, the software may already exist. The work might involve configuration, a small integration or an improvement contributed back to the original project. Those are different activities requiring different expertise.

Buying them all through one enormous, inflexible contract can create problems before anybody writes a line of code.

Sri Lanka appears to recognise the issue. In April 2026, Cabinet approved a Rs. 563 million project for a government technology marketplace intended to address fragmented procurement. Source: Daily FT’s report of the Cabinet decision

That’s encouraging, but the contracts and delivery arrangements matter as much as the marketplace.

I’d like to see smaller delivery packages with clear acceptance criteria. Suppliers should be assessed on working services and maintainable systems. Government should be able to change an integrator without throwing away the platform.

Oversight still matters. So do security and public accountability.

But a process that takes eighteen months to procure six months of work deserves some fairly direct questions.

Start the legal reforms. Deliver what can move now.

Some changes will need legislation. Others may require new regulations, institutional agreements or procurement rules.

Those can be long burns.

My instinct is to get that work moving early, while identifying useful improvements that can proceed under the existing framework.

The first question for a proposed service should be: what actually prevents us from delivering this?

Sometimes there will be a legal barrier. Sometimes the obstacle will be an internal procedure, an unclear responsibility or a requirement nobody has questioned for fifteen years.

Those need different responses.

Where a reform is necessary, give it an owner and a timetable. Where a service can lawfully and securely improve now, get on with it.

Citizens shouldn’t have to wait for every institutional reform before receiving any benefit.

That also means being honest about dependencies. If a service needs infrastructure that isn’t ready, choose another useful starting point. Announcing an early win doesn’t make its prerequisites disappear.

Other countries have already paid some of the tuition fees

Sri Lanka has the advantage of being able to learn from other countries’ experience.

X-Road, used in Estonia, demonstrates how organisations can exchange data directly through a distributed architecture. Shared infrastructure doesn’t have to mean putting every department’s information into one enormous database. Source: X-Road architecture documentation

But software alone cannot settle who may access which information, for what purpose or under whose authority. Those responsibilities still need to be agreed.

Bangladesh offers a different lesson, and one particularly relevant to the argument here.

A UNDP account of its a2i programme reported average reductions of 65% in service time, 73% in cost and 51% in required visits. The account references a study of 85 services over nine years. These are historical, programme-reported results, rather than a promise about what any new programme will achieve. Source: UNDP

But look at what was being measured.

Time. Money. Journeys.

Things that matter to the person using the service.

And because ambitious government technology deserves at least one expensive British cautionary tale, there’s the NHS National Programme for IT.

It delivered some lasting infrastructure, but serious problems with other elements contributed to the dismantling of the centralised programme. Parliament’s Public Accounts Committee subsequently examined its troubled legacy. Sources: Department of Health, Public Accounts Committee

It wasn’t a DPG programme. The comparison has limits.

The warning about ambitious scope, difficult contracts and institutional complexity is still useful. Sri Lanka would be wise to borrow the lessons rather than the invoices.

Pick something useful. Make it work.

Sri Lanka already has operational services to build on.

In an announcement dated 19 December 2025, the President’s Office reported that GovPay had processed more than 69,000 transactions worth over Rs. 2 billion, enabling payments for 3,372 services across 215 institutions. Source: President’s Office

That demonstrates real activity. It doesn’t yet tell us what proportion of eligible payments moved online or how much time users saved. Those would be useful next questions.

The World Bank also approved a $50 million project supporting a citizen service portal, shared data exchange, digital document storage and government cloud infrastructure, alongside training. Source: World Bank

The opportunity is to connect those investments to specific problems people experience.

Take a farmer applying for an agricultural support programme.

As an illustration, imagine that people repeatedly travel to an office because they cannot tell whether an application is complete or what happens next. Proper discovery would establish whether that is the problem, how widespread it is and what staff need to resolve it.

An initial improvement might let applicants check their status and receive a clear explanation of missing information, with help available through the existing service counter.

It wouldn’t require digitising the entire agricultural sector before anybody benefited.

One accountable service owner would oversee delivery. The team would measure repeat visits and time to a decision, alongside how many people could successfully use the service. Frontline staff would help test it before expansion.

That gives “quick win” a practical meaning.

A prototype at a ministerial launch doesn’t count. A service people keep using, and that the responsible institution can keep running, does.

Two or three meaningful improvements in a delivery cycle would be a useful ambition, provided their size and dependencies make that realistic. The number matters less than whether the improvements survive contact with daily life.

Make it easier for everyone who needs the service

There’s a fairly obvious trap here.

A service can become easier for confident smartphone users while becoming harder for everyone else.

Language, disability, unreliable connectivity and access to devices all affect whether a digital service is useful. So does knowing what to do when something goes wrong.

Sinhala and Tamil access needs to be part of the design. Assisted channels need to work. People should be able to correct an error or reach someone who can help.

Otherwise, we’ve replaced the queue outside an office with a different kind of exclusion.

Privacy and security belong in the same conversation. Connecting systems should involve clear limits on access and use, with accountability when those limits are breached.

Moving quickly still requires taking responsibility for the people affected.

Build capability that stays in Sri Lanka

There’s a bigger opportunity here too.

Sri Lanka could develop expertise that helps other countries implement and operate digital public goods.

The skills required are valuable: engineers who understand shared infrastructure, product managers who understand government services, and specialists who can integrate systems without turning them into an unmaintainable mess.

But local capability won’t emerge automatically because an international supplier delivered a platform.

Government teams need to work alongside experienced implementers. Local firms need opportunities they can realistically compete for. Knowledge transfer needs to mean that someone can operate, troubleshoot and improve the service after the supplier leaves.

Where improvements can be contributed back to an open-source project, they should be. Maintaining a private version indefinitely can become its own expensive dependency.

I’d like to see Sri Lanka become a contributor whose expertise other countries seek out.

That starts with learning how to run its own services well.

Give people ownership, then judge the results

Cabinet has approved Digital Transformation Units within government institutions, with Chief Digital Officers reporting to institutional heads and access to specialist support from GovTech Sri Lanka. Source: Cabinet Office

That can help, provided those people have the authority and resources to resolve delivery problems.

Their value will become clear when they settle an ownership dispute, prevent incompatible systems from being commissioned or help a service team remove an unnecessary step.

An organisational chart cannot do those things on its own.

I’d make progress visible in terms citizens and public servants can understand: whether applications take less time, whether fewer people have to return with missing documents, whether problems get resolved.

Publish the disappointing results too. They tell the next team where to improve.

The opportunity is real. So is the hard work.

I’m optimistic about Sri Lanka’s direction.

There’s thoughtful architecture, investment and evidence of working services. My professional experience makes me conscious of how difficult the next stage will be. My Sri Lankan background makes me particularly keen to see it succeed.

The work ahead won’t always make for exciting announcements.

Nobody cuts a ribbon when an API is versioned properly. The person who prevents three ministries from building incompatible registries is unlikely to become a national celebrity.

Which is a shame. They may have saved everyone a great deal of money and aggravation.

But the benefit should eventually be obvious to the people using the services.

Keep the ambition big. Start the difficult reforms. Give delivery teams manageable problems, proper support and clear accountability.

Then show people that something has improved.

Someone who avoids a wasted journey doesn’t need a presentation explaining why digital transformation matters. They’ve already experienced it.

Nobody ever went home delighted that their government had implemented a reference architecture.

They went home delighted because something that used to take three days now takes three minutes.

That’s the transformation worth building.

And I’d rather see Sri Lanka become famous for that than for producing another beautiful bloody blueprint.

This article reflects my independent professional perspective, informed by work in digital public infrastructure, open-source technology and public-service transformation. It is not an official statement on behalf of any organisation.

Sources and further reading

1. Sri Lanka’s Digital Economy Blueprint 2025–2030 ↗ICTA. National targets, platform-first principles and shared infrastructure.
2. Digital public goods: definition and eligibility ↗Digital Public Goods Alliance. Open licensing, privacy and public-good standards.
3. Cabinet clears Rs. 563 million GovTech marketplace ↗Daily FT, 9 April 2026. Reporting on the Cabinet decision and procurement proposal.
4. X-Road architecture documentation ↗Nordic Institute for Interoperability Solutions. Distributed data exchange and system architecture.
5. Innovations from Bangladesh are transforming public service delivery in the Philippines ↗UNDP. Historical a2i findings on time, cost and visits, used in the chart above.
6. Dismantling the NHS National Programme for IT ↗UK Department of Health, 2011. Programme restructuring and retained components.
7. The dismantled National Programme for IT in the NHS ↗UK Public Accounts Committee, 2013. Parliamentary assessment of delivery and contracting.
8. GovPay’s reported 2025 transaction and coverage figures ↗President’s Office, Sri Lanka, 19 December 2025. Source for all four GovPay indicators.
9. World Bank and Sri Lanka partner to improve digital services ↗World Bank, 19 December 2025. Approval of the $50 million digital transformation project.
10. Establishment of Digital Transformation Units in government institutions ↗Sri Lanka Cabinet Office. Institutional ownership and GovTech support arrangements.

Photography credits

Colombo street market: sk / Pexels. Rice harvesting in Bandaragama: Leo Pixie / Pexels. Used under the Pexels licence. Both photographs are illustrative.