Public Sector & GovTech: Digital Public Infrastructure That Actually Ships

There is also a trust dimension that the private sector rarely has to confront at the same intensity. When a retail checkout fails, a customer shops elsewhere. When a public service fails, a citizen may miss a pension payment, a subsidy, or a deadline with legal consequences — and they have no alternative provider. That asymmetry should change how the software is engineered: accessibility for every citizen including those on low-end devices and patchy networks, graceful degradation when a dependency is down, and transparency about why a decision was made. Most legacy delivery treats these as compliance checkboxes bolted on at the end. We treat them as the architecture.

Finally, the talent and incentive structure of the large integrators works against the public interest more often than anyone admits. A vendor paid by headcount and change requests has no commercial reason to ship something so good it needs no changes. A smaller, outcome-aligned partner does. That alignment — not a longer list of certifications — is the single biggest predictor of whether a GovTech programme delivers.

Procurement was designed for buildings, not software

Most public-sector procurement frameworks were written to buy roads, bridges and stationery — fixed scope, fixed price, delivered once. Software does not behave that way. Requirements are discovered, not specified; the right design for a benefits-eligibility flow only becomes obvious once real citizens have tried a prototype. When you force living software through a procurement model built for concrete, you get the worst of both worlds: a rigid contract that punishes learning, and a system that is obsolete the day it launches. The fix is not to abandon accountability — it is to contract for outcomes and iterations rather than a frozen specification.

This is why so many government IT programmes feel like they fail in slow motion. Nobody made a single catastrophic decision; the model simply made it impossible to course-correct. By the time the misalignment is undeniable, the change-request machinery has already turned a fixable problem into a budget line.

Legacy is a load-bearing wall, not a greenfield

Public agencies almost never get to start from scratch. There is a mainframe from the 1990s holding the system of record, a tangle of point-to-point integrations nobody fully understands, and data spread across departments that were never designed to talk to each other. Any honest modernisation strategy has to treat that legacy estate as a load-bearing wall — something you strangle and replace incrementally, behind a stable interface, rather than demolish in one risky cutover. We have seen too many programmes promise a big-bang migration and then quietly miss the date by years.

The teams that succeed do the unglamorous work first: they wrap the legacy system in clean APIs, build an anti-corruption layer, and move one service at a time onto modern rails while the old system keeps the lights on. It is slower to demo and far safer to live with.

We work as a single accountable team with the agency, not as a vendor lobbing deliverables over a wall. That means embedding with the officers who run the service today, capturing the edge cases that never make it into a requirements document, and treating their tacit knowledge as a primary input. The best GovTech is co-designed with the people who will operate it, because they know exactly where the current process bleeds time and trust.

And we plan for the handover from day one. A public system that only its original vendor can maintain is a liability, however well it was built. We document relentlessly, prefer open standards and open source where it is responsible to do so, and build the client's own team up so they are never hostage to us. The goal is a system the agency owns — technically and operationally — not a dependency dressed up as a partnership.

Ship something real in weeks, not years

We refuse to disappear for eighteen months and reappear with a system. Within the first weeks of an engagement, a real, working slice of the service is in front of real users — often a single high-volume journey like a permit application or a grievance flow. That early increment does more than de-risk the build; it changes the politics of the programme. Stakeholders stop arguing over abstract requirement documents and start reacting to something they can click. Adoption data, not opinion, drives the roadmap from there.

This cadence is only possible because we invest upfront in automation: infrastructure-as-code so environments are reproducible, CI/CD so every change is tested and shippable, and observability so we know what is actually happening in production. Legacy vendors often treat these as optional extras to be funded later. For us they are the precondition for moving fast without breaking trust.

Security, accessibility and audit are designed in, not bolted on

In the public sector, security and accessibility cannot be a phase near the end of the plan — by then the architecture has already foreclosed the right choices. We thread threat modelling, WCAG-grade accessibility, data-protection-by-design and full auditability through the work from the first sprint. Every privileged action is logged and attributable; every citizen-facing screen is tested with assistive technology and on low-end devices. This is slower to start and dramatically cheaper over the life of the system, because retrofitting these properties into a finished build is where budgets go to die.

We also design for the day a dependency fails. Public systems live in a messy world of intermittent legacy APIs and uneven connectivity. We build for graceful degradation, idempotent retries and clear citizen-facing communication when something is down, so a back-end hiccup never becomes a citizen's missed deadline.

The decisive shift of the next decade is from monolithic government IT systems toward composable digital public infrastructure — open, interoperable building blocks that the public and private sectors share. India has already proven the model at population scale; the question for every department now is whether it builds another walled-garden portal or contributes to and consumes from a common stack. The agencies that embrace interoperability will move faster and cheaper, because they stop rebuilding identity, payments and consent for the hundredth time. The ones that cling to bespoke end-to-end systems will keep paying the integration tax forever.

Artificial intelligence is about to test public institutions hard. Used well, it can triage grievances, translate services into every regional language, surface fraud and leakage, and clear backlogs that have defeated agencies for years. Used carelessly, it becomes an opaque decision-maker that citizens cannot question and operators cannot explain. Our firm position is that AI in government must be assistive and accountable: it can recommend, draft and flag, but a human remains responsible, and every automated decision must be explainable and contestable. Any vendor selling you a black box that adjudicates citizen entitlements is selling you a future scandal.

What most teams get wrong is treating GovTech as a delivery problem when it is really a trust problem. The hard part was never the database schema; it is building software that a citizen believes will treat them fairly and an officer believes will not embarrass them. That trust is earned through reliability, accessibility, transparency and the willingness to fix things fast — exactly the properties that a slow, change-request-driven delivery model cannot produce. The future of public-sector software belongs to teams that ship like a product company and govern like a public institution.