Six enrollments on day one: Healthcare.gov and public-sector software assurance

A launch that failed on contact

Healthcare.gov opened at midnight on 1 October 2013 to serve residents of the roughly three dozen states that had not built their own insurance exchanges. The site was overwhelmed almost immediately: users faced error pages, endless loading screens and an identity-verification bottleneck that prevented most visitors from ever reaching a plan comparison page. Documents later released by the House Oversight Committee showed that only six people completed enrollment in a private plan on day one.

The failure was not a brief teething problem. Serious performance issues persisted for close to two months, prompting the administration to bring in a 'tech surge' of outside engineers before the site reached broadly acceptable reliability by late November 2013.

“Political deadlines that are not negotiable, integration testing treated as a final checkbox, and no named architect empowered to say a launch date isn't achievable.”

How it happened

Subsequent investigations, including reporting by the Government Accountability Office and extensive congressional testimony, described a project managed across dozens of contractors with no single entity accountable for end-to-end system integration. Requirements changed late, including a decision to require account creation before users could browse plans, which concentrated load on the weakest part of the system. End-to-end load testing was conducted only in the final days before launch, at a fraction of the traffic the site actually received.

The episode cost far more than original budget estimates and became a significant political liability — but its more durable legacy for the profession was procedural: it is widely cited as a catalyst for the creation of the US Digital Service and 18F, federal units built specifically to bring modern software practice into government.

What large public IT projects still get wrong

The Society's interest in Healthcare.gov is as a case study in how public accountability can be structurally diffused across contractors until no individual or firm owns the outcome. It is a pattern repeated in public-sector IT failures across jurisdictions: political deadlines that are not negotiable, integration testing treated as a final checkbox rather than a continuous discipline, and no named systems architect empowered to say a launch date is not achievable.

• Statutory or political launch dates should not override engineering judgment about readiness without a documented risk acceptance by an accountable official.
• Multi-contractor public IT projects require a single named systems integrator with authority over the whole stack.
• Load and integration testing must be scheduled with enough runway to act on what it finds.

What the Society advises

The Society recommends that agencies commissioning large public-facing systems require an independent, credentialed engineering sign-off — separate from the delivering contractors — before any launch serving the public at scale. It further advises that procurement rules reward incremental, testable delivery over fixed-date launches, and that named technical accountability become a contractual requirement on public IT work. Practitioners should decline to certify systems as ready when the evidence does not support it, whatever the pressure to do so.