Why governments need an assembly line for digital public services

Governments have learned how to build digital services, but delivering them consistently, repeatedly and at scale requires a system that many have yet to develop.

After years of investment in digital identity, interoperable registries, shared platforms and other foundational capabilities, "the challenge is no longer just to build these foundations, but to complete the systemic digital transformation of the state that will deliver real impact,” stated the Organisation for Economic Co-operation and Development (OECD)'s Digital Government Outlook 2026.

According to the report, many governments have invested in the right foundations, but these often fail to function as an integrated system. 

Progress ends up staying concentrated in strategies, frameworks, and enabling conditions rather than in their consistent operational application. 

Closing the gap between ambition and delivery now depends on governance, capability, and accountability alongside technology.

Over the past seven years, I have worked with Ukraine's Ministry of Digital Transformation and other public institutions to deliver more than 200 digital public services through Ukraine's national digital government platform, Diia, and Liquio, the open-source low-code platform our team developed to support service delivery. 

My experience suggests that one reason for this gap is that digital services are still commonly commissioned and delivered as individual projects rather than through a repeatable delivery model.The difficulty comes when governments need to deliver not one service, but hundreds.

A traditional project model illustrates the challenge. If every new service is procured, designed and built separately, and each delivery takes around nine months, a portfolio of 2,000 services represents 18,000 months of work. 

Even with one hundred delivery teams working simultaneously, implementation would still take around fifteen years. 

By then, legislation will have changed, institutions will have evolved, and citizens' expectations will have moved on.

So, we dived deeper with analytical tools. We went back through twenty-eight service delivery projects, looking for where delivery consistently broke down. 

Instead of treating projects in isolation, we grouped recurring issues into patterns. 

Six systemic challenges emerged repeatedly: fragmented portfolios, inconsistent delivery approaches, complex regulatory processes, limited resources and capabilities, technological fragmentation, and weak measurement.

The main obstacle is the absence of a common operating model for delivering services at scale.
So what would such an operating model look like?

Building the assembly line

No project- or product-level method can fix problems that exist at the level of the system producing the projects.

But manufacturing solved this problem long ago. Every product is different, but the production process remains remarkably consistent. 

Digital public services could be produced with the same logic. Each has its own legislation, participating institutions and user journey, but the path from an idea to a live service follows the same sequence of decisions.

That is what we call the assembly line.

The assembly line is a complete operating model for the lifecycle of a digital public service – from portfolio planning to eventual retirement. It has two dimensions: phases and tracks. 

Every service moves through the same sequence of phases – portfolio shaping, discovery, design, build and test, beta, launch and live operation. 

At the same time, five workstreams, from product and users, engineering, legal and regulatory, security and data, to resources and procurement, run in parallel.

At the portfolio shaping phase, the agency decides which problems are worth solving at all, and in what order. 

Services should be designed around people's real needs rather than government structures.
And that includes people who cannot or will not use the digital channel: how the service reaches them is decided at the concept stage, not after launch. 

Inclusion retrofitted later costs more and often never happens, which is why so many services around the world remain single-channel.

Once the concept is clear, the discovery phase establishes what it will take to make the service possible. 

Teams analyse the citizen journey from beginning to end, identify which registries need to exchange information, and determine which institutions must participate. 

Risk analysis belongs at the start: cybersecurity threats, personal data exposure, operational and institutional risks are assessed while the service is still a concept. 

Identifying these risks during discovery allows teams to address them before they reach production, where the consequences can affect both the service and citizens' trust. 

This is also when the service gets a named owner on the government side, so requirements do not drift with every new voice in the room. 

Next comes service design. A great user experience means the citizen does as little as possible: no certificates to collect, no data to re-enter that government already holds. 

But every step removed from the citizen's side must be absorbed by the government's side – a registry has to share the data and differentiate access among users, an institution has to accept another's records, and the law has to permit the simplification. 

That is why the participating institutions' agreements, legislation, and service design are aligned before software development begins. 

Otherwise, the team builds an experience the legal and institutional foundation cannot yet support. 
Designers themselves design from existing patterns citizens have already learned in previous services.

By the time development begins, little needs to be built from scratch: teams assemble services from existing building blocks – user-interface components, digital identity, secure data exchange, electronic signatures, payments, reusable registry integrations. 

Reusing proven components reduces development time while improving reliability and security.
Before launch, every service undergoes comprehensive testing with the function, performance and accessibility to ensure that the service is ready for real-world use.

Testing culminates in a beta mode, where the service meets real users before it meets everyone. 
At the same time, institutions train civil servants, organising support teams and prepare communications. 

The legal track runs in parallel with engineering: regulation is drafted during design and finalised during beta, so the service and its legal framework arrive together. 

When a finished product sits waiting for its legal act, the failure had happened much earlier – the tracks were sequenced instead of synchronised.

After launch, the service enters the product live phase, where teams continuously improve it by monitoring analytics, user journeys, completion rates, system performance and citizen feedback.

And when a service has outlived its purpose, the same model governs its retirement – users are migrated, data is archived, and capacity is freed for what citizens need next.

Services follow the same operating model. That consistency changes more than project management. 

It changes how governments learn: a lesson from one service transfers to the next only when both follow the same process. In bespoke projects, lessons leave with the team.
Quality gates
Every real assembly line has one more element: quality control between stations. 

A product only moves to the next station when it has passed inspection. 

The assembly line for public services works the same way. 

Between phases stand gates: formal decision points where a service must earn the right to move forward, and where government keeps the right to stop. 

Should this enter the portfolio at all? Do the discovery findings justify building it? Is the design ready for development? Is the proposed solution secure enough? Is the beta ready for citizens? Should a live service keep evolving – or be retired? 

In our analysis, most delivery failures were not engineering failures. 

They happened where a gate should have stood and did not: work kept moving because no one had the mandate to pause it. 

This is the governance and accountability the OECD calls for – built into the production process itself, not layered on top of it.

Why reuse matters

In a traditional project model, each team starts almost from scratch. 

On an assembly line, reuse runs through every layer of a service. At the interface layer, teams reuse components and journey patterns citizens already know. 

At the process layer – approval chains, multi-party signing, payment-then-permit sequences. At the data layer – shared models where a "person" or an "address" is defined once,  with validation rules and tests to match. 

A registry integration is not just code, but is embodied with a negotiated data-sharing agreement, an approved access model and a passed security review. 

Rebuilding it for every new service would mean renegotiating all of that, every time. 

At the top, an entire service becomes the template: a registration service, a permit service and a grant application share the same skeleton, so a service built for one institution becomes the blueprint for the next. 

Over time, the conversation shifts from "How do we build this service?" to a much more powerful question: "What can we reuse?"

This is how we worked within Ukraine’s Diia ecosystem, and this is what allows digital transformation to scale. 

A production system is also the precondition for artificial intelligence (AI) in government. : AI has nowhere to plug into a hundred ad-hoc processes, but it has everywhere to plug into repeatable ones.   

Rethinking Digital Public Infrastructure

By now, the reuse argument for digital public infrastructure (DPI) as shared, reusable foundations is well understood – identity is built once so every service can recognise citizens the same way; registries are connected so data collected once can serve many services. 

That layer of reuse is necessary.

What a production system adds is reuse at a far finer grain. 

On an assembly line, a completed service leaves behind far more than an integration: the interface

components and interaction patterns citizens have already learned to use; the adapter to a specific registry, with its access model already approved; the draft regulation that has already survived legal review, ready to serve as a template; the test scenarios for a class of integrations; the checklist a gate review actually uses. 

And beyond artifacts, the system accumulates practice. 

Every service delivered teaches the production system something – how to sequence a legal track, how to scope a beta, where security reviews catch real risks – and those lessons become part of the process for the services that follow. 

Infrastructure reuse saves integration time. Practice reuse is what makes the hundredth service radically cheaper and faster than the tenth.

Ukraine's experience suggests this is the real achievement: not the foundations themselves, but a delivery model in which every shared capability compounds across services.

DPI cannot be looked at as just a collection of technologies, but the production system that turns shared capabilities into continuously evolving public services.

------------------------

The author is the CEO of Ukrainian govtech company, Kitsoft. Under his leadership, Kitsoft built the core technical foundation for Diia superapp, Ukraine’s national digital government platform used by millions of Ukrainian citizens.