Government That Ships: Modern Procurement for Public Technology

Governance determines whether code delivers

Federal technology failure is usually described as a software problem. The deeper failure is governance. Agencies often buy a complete system before they have tested whether the service model works. Contracts reward document production and compliance artifacts before a user can complete a transaction. Program officials inherit requirements written years earlier and cannot easily stop a vendor that has become embedded in the operating model. Oversight arrives late, after the program has already spent through the point where changing course feels more embarrassing than continuing.

GAO's 2025 High Risk update named three continuing challenge areas in federal IT acquisition and management: portfolio oversight, mature acquisition and development practices, and federal IT capacity. That diagnosis is useful because it does not pretend one more dashboard will fix the system. Portfolio oversight asks whether agencies know what they own and whether investments are producing mission value. Mature development asks whether programs use disciplined, incremental methods rather than treating a future launch date as proof of progress. Capacity asks whether government has enough technical and acquisition skill to act as an owner instead of a passive buyer.

The public already has a model for what better looks like. The federal Digital Services Playbook asks direct questions a working service should be able to answer: what are the key metrics, how often do users complete the transaction, how quickly does the service respond, what is the uptime target, how are incidents handled, and what postmortem process exists. Those questions are not a separate innovation agenda. They are the minimum evidence that a service exists for the public rather than for an internal org chart.

Modular procurement should become the default

Modular contracting is not new. Federal acquisition guidance has recognized for years that software can be bought in smaller increments and iterated with users. The problem is that the exceptional method has never become the ordinary one for the systems where failure hurts the public most.

This issue would make modularity the starting point for major public-facing technology programs. A phase should fund discovery, prototype, security architecture, and user research. The next should fund a narrow production capability. Later phases should expand scope only when the earlier increment works. Agencies should publish which milestones unlock continued funding: service completion, security accreditation, cost control, accessible design, interoperability, and operational readiness. A vendor should not be rewarded for producing a thousand-page requirements document if no eligible person can complete the application the system is supposed to support.

This also changes how oversight works. Congress and inspectors general should ask whether a service is improving against public metrics, not only whether a program submitted required documents. A program that ships a narrow working service in six months and learns hard limits from users is healthier than a program that spends three years reporting green status before a single person can use it.

Public capacity is what makes accountability possible

The party should be clear about the role of contractors. This issue is not a claim that all public technology should be written by federal employees. It is a claim that government must retain enough technical, acquisition, security, product, and data capacity to be a competent owner. Without that capacity, agencies cannot evaluate bids, challenge vendor claims, maintain reusable components, or know when a project should stop.

That owner capacity belongs in three places. First, CIOs need enough authority over major IT investments to intervene before failure is irreversible. Second, program offices need product owners who understand the service and can make decisions with users, lawyers, security teams, and engineers in the same loop. Third, acquisition offices need people who can write contracts for outcomes and interoperability rather than for exhaustive feature lists that are obsolete before award.

This is the same logic GOV-01 applies to Congress's technology capacity. A legislature that cannot understand technology will write bad law. An agency that cannot own technology will buy bad systems. Both are institutional capacity problems, and both are solvable only if the public sector can attract, retain, and empower people who know the work.

Reuse requires discipline

Every agency should not separately invent login, identity proofing, forms, notices, payment status, appointment scheduling, eligibility checks, case tracking, and appeal submission. Some variation is legitimate because legal programs differ. But a government that lets every program buy a bespoke version of the same basic component creates cost, security, and user burden for no public benefit.

The platform should therefore support reusable public components and open standards where security allows. That does not mean one mandatory federal platform for every service. It means a reusable catalog of components, shared interface standards, documented APIs, and procurement language that makes reuse easier than one-off reinvention. A state, local government, nonprofit benefits navigator, or small vendor should be able to understand how a service works without reverse-engineering a proprietary contract.

Reusable components also need exit rights. A government system should not become impossible to recompete because only one vendor can export the data, operate the interface, or understand the code. Contracts should define data portability, documentation, government-purpose rights, transition support, and source-code access where necessary before the first award is signed, not after a relationship has already become dependent.

Metrics have to be public enough to matter

Performance.gov's customer-experience work recognizes that trust in government is built transaction by transaction. That point is easy to say and hard to operationalize. A public technology program should publish enough service metrics for the public, Congress, watchdogs, and agency leaders to tell whether the service is working.

The metric set should match the stakes. For high-volume services, basic uptime and page-speed metrics are not enough. Completion rate, abandonment rate, time to decision, denial and appeal timelines, accessibility defects, language access, error rates, call-center deflection, and security incidents are often more important. For systems affecting benefits, enforcement, or rights, agencies should publish how many people are delayed, denied, redirected, or forced offline because the technology does not work for them.

Metrics should not become another paperwork layer. They should be used to make decisions: continue, stop, recompete, add support, simplify a form, change a rule, or fund a shared component. A metric that no one can act on is just another dashboard.