Kitsoft CEO Oleksandr Iefremov explains in his guest column for GovInsider why traditional project-based approaches hinder the scaling of digital public services and how governments can rethink their service delivery models.
Over the past seven years, Oleksandr has worked with Ukraine’s Ministry of Digital Transformation and other public institutions to deliver more than 200 digital public services through Ukraine’s Diia ecosystem and Liquio, the open-source low-code platform developed by Kitsoft.
Drawing on this experience and an analysis of 28 service delivery projects, Oleksandr presents the Digital Public Service Assembly Line, an operating model that enables governments to deliver and scale digital public services systematically.
Here are the key insights from his guest column for GovInsider.
Photo: Oleksandr Iefremov, CEO of Kitsoft
Why traditional project-based approaches fall short at government scale
Governments have learned how to build digital services. The challenge arises when they need to deliver not one service, but hundreds.
If every service is procured, designed and developed separately, and we assume that each takes nine months to deliver, a portfolio of 2,000 services would require 18,000 months of work. Even with 100 teams working simultaneously, delivering such a portfolio would take approximately 15 years.
By then, legislation, public institutions and citizens’ expectations will have changed.
An analysis of 28 digital public service delivery projects revealed six systemic challenges: fragmented service 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 digital public services at scale.
How the Digital Public Service Assembly Line works
In manufacturing, every product may be different, but the production process remains standardised. The same principle can be applied to digital public services.
Each service has its own legal requirements, participating institutions and user journey. However, the path from an idea to a live service follows the same sequence of decisions.
The Digital Public Service Assembly Line covers the entire lifecycle of a digital service, from portfolio planning and discovery to design, development, testing, launch, continuous improvement and eventual retirement.
At the same time, five workstreams run in parallel: product and users, engineering, legal and regulatory, security and data, and resources and procurement.
This allows technical development, regulatory changes and institutional preparations to be coordinated.
For example, if a technically completed service is waiting for a legal act to be adopted, the problem arose much earlier. Legal and technical work should have been synchronised during the design phase so that the service and its legal framework are ready at the same time.
Why Quality Gates matter
Another essential element of the model is Quality Gates, formal checkpoints between development phases.
At each checkpoint, a decision is made on whether a service is ready to move to the next phase. Importantly, the government retains the authority to stop the process if the necessary conditions have not been met.
Should the service enter the portfolio at all? Do the discovery findings justify its development? Is the design ready for implementation? Does the proposed solution meet security requirements? Is the beta version ready for citizens?
According to the analysis, most service delivery failures were not engineering failures. They occurred where a checkpoint should have existed but did not. Work continued because no one had the authority to pause it.
Quality Gates therefore embed governance and accountability directly into the digital public service delivery process.
How reuse accelerates digital transformation
In a traditional project-based model, each team starts much of its work from scratch.
The Digital Public Service Assembly Line, by contrast, enables the reuse of not only software components but also established processes, integrations, data models, legal documents and testing assets.
For example, an integration with a government registry is more than just code. It also includes an agreed data-sharing arrangement, an approved access model and a completed security review. Reusing that integration means these approvals do not have to be negotiated again for every new service.
Similarly, registration services, permit applications and grant applications can share the same underlying structure, components and processes.
As a result, each new service builds on what has already been developed.
“Over time, the conversation shifts from ‘How do we build this service?’ to a much more powerful question: ‘What can we reuse?’”
This is the approach we applied within Ukraine’s Diia ecosystem. Every service delivered leaves behind not only reusable technical solutions but also experience that becomes part of the shared delivery process for future services.
Why this matters for the future of GovTech
Shared digital public infrastructure, including digital identity and data exchange systems, provides an essential foundation for digital public services.
The Digital Public Service Assembly Line builds on this foundation by enabling the reuse of not only technological components but also processes, proven solutions and accumulated expertise.
Every service delivered helps improve the shared operating model. Lessons learned from coordinating legal work, conducting beta testing and carrying out security reviews become part of the delivery process for subsequent services.
Such an operating model also creates the conditions for applying artificial intelligence in government. As Oleksandr explains, AI has little room to operate across hundreds of disconnected, ad hoc processes, whereas repeatable processes provide opportunities for its integration.