Loading issue research
Buy public technology in modular increments, publish service metrics, stop failing programs early, and default to open standards and reusable components.
Verification Status
AI-researched, unverifiedLast Reviewed
Jul 6, 2026
Cited Sources
5
What is failing, what we would change, and the conclusion we are willing to defend.
The federal government spends more than enough on technology to deliver better public services. GAO still keeps federal IT acquisitions and operations on its High Risk List, a status it added in 2015 because large IT investments too often run late, cost more than planned, duplicate work, or fail to produce useful mission outcomes. That is not an abstract management problem. It is the reason a veteran waits on a broken claims system, a family re-enters the same information across benefit programs, a small business struggles through an obsolete portal, and Congress learns about a failing project after the money is gone.
The Innovation Party's position is straightforward: public technology should be bought and managed like working capability, not like a one-time document-delivery contract. Agencies should buy smaller increments, test them with users, publish service metrics, reuse components, and stop programs that are not producing public value.
Replace default megaproject procurement with modular delivery. Large public technology programs should be split into increments with working software, user testing, security review, and public milestone evidence before later funding is released.
Give agency CIOs and product owners authority to stop, restructure, or recompete failing programs when cost, schedule, security, or user-service metrics miss defined thresholds.
Require public service metrics for high-volume public-facing systems: uptime, completion rate, wait time, abandonment rate, appeal time, accessibility, incident response, and customer trust where the service affects benefits, permits, enforcement, or rights.
Default to open standards, documented APIs, data portability, and reusable public components for identity, notices, payments, forms, eligibility, case status, and appeals, except where a security case justifies a narrower design.
Require vendor exit plans, source-code escrow or government-purpose rights where appropriate, data-export rights, and contract structures that prevent a single incumbent from becoming the only plausible bidder on the next phase.
Publish plain-language postmortems for major public technology failures and near-failures, with procurement, governance, security, and user-research lessons separated from blame.
This is not anti-contractor. Contractors build much of the country's public technology and will keep doing so. The question is who owns the service, the data, the standards, and the decision to stop a failing path. A government that cannot ship working software cannot govern an innovation economy.
Turn frustration into useful pressure.
If this position misses evidence or a lived consequence, challenge it. If it holds up, help test it locally and connect it to the issues around it.