Case Study 2: The Healthcare.gov Launch Failure (October 2013)

The Case in One Paragraph

On October 1, 2013, the federal Healthcare.gov website opened to the public. It was the central enrollment portal for the Affordable Care Act's individual insurance marketplaces — the legal access point through which most uninsured Americans in 36 states (those without state-run exchanges) were expected to enroll in subsidized health-insurance plans. Within hours, the site collapsed under a combination of overwhelming traffic and architectural failures. Of the estimated 8.6 million people who attempted to use the site in its first week, fewer than 26,000 succeeded in enrolling in a plan. Two months in, only 364,000 of a projected 3.3 million had enrolled. The failure embarrassed the Obama administration, jeopardized the long-term political viability of the Affordable Care Act, and prompted a six-week emergency rescue operation by a "tech surge" team of private-sector engineers led by former Office of Management and Budget official Jeff Zients. By December 2013, the site was largely functional. By the end of the first open enrollment period in March 2014, more than 8 million Americans had enrolled. But the political and institutional damage was real and lasting.¹

The Institutional Actors

Healthcare.gov was administered by the Centers for Medicare and Medicaid Services (CMS), a subagency of HHS. The principal institutional actors were:

• The Centers for Medicare and Medicaid Services (CMS), with the Center for Consumer Information and Insurance Oversight (CCIIO) as the lead office.
• HHS leadership, including Secretary Kathleen Sebelius (who later resigned, in part, over the failure).
• Multiple federal contractors, including CGI Federal (lead contractor for the front-end portal) and Quality Software Services Inc. (data hub), among 55 contractors total.
• The White House, which had political accountability for the rollout but, by subsequent accounts, was insufficiently informed of the technical problems before launch.
• The U.S. Digital Service (USDS), which did not yet exist as an institution but whose creation in August 2014 was a direct response to the Healthcare.gov failure.
• The "tech surge" team, an emergency group of approximately 50 software engineers from Google, Oracle, Red Hat, and other firms, plus civil servants and consultants, organized in October 2013 to repair the site.

This case is a useful illustration of an institutional pathology: not the absence of resources (CMS spent more than $400 million on Healthcare.gov over multiple years before launch), and not the absence of technical talent in America (Silicon Valley demonstrably had the skills required to build the site), but the gap between federal procurement and oversight processes and modern software-development practices.

Timeline

• March 23, 2010: Affordable Care Act signed into law.
• June 28, 2012: Supreme Court upholds the individual mandate (NFIB v. Sebelius) but allows states to opt out of Medicaid expansion. This decision puts more pressure on the federal exchange because more states than expected (eventually 36) decline to operate their own exchanges, expanding Healthcare.gov's responsibility.
• September 2011 – mid-2013: CMS issues contracts and begins development. Internal warnings about timeline and integration risks accumulate but do not produce schedule changes. Late additions to scope (such as a requirement that users complete identity verification before browsing plans) compound the problem.
• March 2013: A McKinsey & Company review (commissioned by HHS) warns that "we are not on a course to be successful." The report is briefed internally but does not result in launch delays or major contract restructuring.
• September 2013: End-to-end testing of the site is conducted late and inadequately. The full system is not load-tested at the volume the site is expected to receive on day one.
• October 1, 2013: Site opens. It collapses within hours.
• October 22, 2013: President Obama gives a Rose Garden address acknowledging the failure and announcing a "tech surge."
• October 24, 2013: Jeff Zients arrives to lead the rescue.
• November 30, 2013: The site achieves what the team calls "marketplace targets": 90 percent of users can complete enrollment, response times have dropped from eight seconds to less than one second, and the daily error rate has fallen from 6 percent to less than 1 percent.
• March 31, 2014: First open enrollment period closes with more than 8 million enrollments.
• April 11, 2014: Secretary Sebelius announces her resignation.
• August 11, 2014: The U.S. Digital Service is established by executive memorandum to professionalize federal technology procurement and operations.

What Failed

The HHS Office of Inspector General's 2016 case study identifies several categories of failure.

Procurement and contract management. The federal government's procurement system, governed by the Federal Acquisition Regulation (FAR), is designed for the slow, sequential, requirements-heavy work of buying tanks, buildings, and uniforms. It is poorly adapted to modern software, where requirements emerge during development and integration risks dominate. CMS used a traditional waterfall procurement structure: a lead contractor (CGI Federal), with payment milestones tied to deliverables defined years in advance. By the time the deliverables were tested integrated, the launch date was already announced.

Management. No one was clearly in charge of the integrated system. CMS's CCIIO managed the policy side; CMS's Office of Information Services managed parts of the technical side; the lead contractor managed development; multiple subcontractors handled discrete components. There was no single technical authority empowered to make integration tradeoff decisions in real time. When red flags appeared, they tended to surface within silos, not across them.

Schedule rigidity. The October 1, 2013 launch date was politically sacred. Delaying it would have been read as an admission that the Affordable Care Act's central feature was not ready, which the administration believed (probably correctly) would be politically catastrophic. The result was that schedule pressure dominated all other considerations — and a system that should have been delayed three to six months was instead launched on time and broken.

Testing failures. The full end-to-end test of the system at expected production volume was conducted only days before launch, and it failed. The decision to launch anyway, based on confidence that the team could fix problems "as they emerged," reflected a fundamental misunderstanding of how high-traffic web systems behave under stress.

Communications failure. The White House, by accounts in subsequent journalistic reconstructions, was not informed of the depth of the technical problems before launch. Officials briefed the President with optimism that was not warranted by the underlying engineering reality. This is a classic principal-agent failure of the kind political scientists study (Chapter 11 will return to this), and it is not unique to Healthcare.gov — federal agencies often communicate up the chain in ways that emphasize confidence and de-emphasize risk.

What Was Eventually Repaired

The "tech surge" of October–November 2013 worked. Within six weeks, a relatively small team of experienced software engineers, given clear authority and a clear mandate, restructured the site's architecture, fixed the bottlenecks, rewrote the most-broken modules, and stabilized the system. Many of the engineers involved later joined the U.S. Digital Service or 18F (a parallel office in the General Services Administration), bringing modern software-development practices into federal government.

The longer-term institutional response was the creation of USDS, which has since worked on a series of high-profile federal technology projects, including the Department of Veterans Affairs claims system, the Department of Defense's appeals processing, and the IRS's online taxpayer services. USDS's existence is, in many respects, a permanent monument to the Healthcare.gov failure — and a signal that the federal government can learn from its mistakes when given a forcing function.

The Affordable Care Act itself survived. By the close of the 2014 open enrollment period, more than 8 million Americans had enrolled through the federal and state marketplaces combined. The marketplaces continued to operate through subsequent administrations, including the Trump administration, which did not eliminate them. Enrollment grew to over 24 million in the 2024 open enrollment period under the expanded subsidies of the American Rescue Plan and the Inflation Reduction Act.²

Why This Case Matters for Chapter 1

Healthcare.gov is a useful counterweight to over-confident framings of federal government capacity. The same federal government that — eight years later — would orchestrate Operation Warp Speed and deliver a vaccine to a third of the country in eight months was, in 2013, unable to launch a website. Both are American government. Both are real.

The case illustrates several themes the book will return to:

• Theme 2 (the gap between design and reality): The textbook description of federal procurement (a careful, deliberate process protected by FAR, designed to ensure value for taxpayers) is meaningfully accurate; the operational reality is that it is poorly suited to high-stakes software, and federal officials have to work around it rather than within it to deliver modern technology.

• Theme 6 (institutions shape behavior): Career civil servants at CMS were not lazy or incompetent. They were operating within institutional constraints (procurement law, schedule pressure, principal-agent reporting incentives) that made the failure substantially predictable in retrospect. Replacing the people without changing the institutions would not have produced a different outcome. The creation of USDS — a new institution with different rules — is what changed federal software-delivery capacity.

• Theme 4 (every political question has at least two honest sides): Conservatives at the time argued that the Healthcare.gov failure was evidence that the federal government should not have undertaken something as ambitious as the ACA; liberals argued it was evidence of a procurement system in need of reform, not of the underlying program. Both positions were defensible; both turned on values judgments about government's appropriate scope. A decade later, the marketplaces continue to operate and serve more than 24 million Americans — which is data that bears on, but does not finally settle, the original question.

The Healthcare.gov failure also provides a useful point of comparison with Operation Warp Speed (Case Study 1). Both were technology-intensive federal initiatives. OWS largely succeeded; HCgov largely failed. The differences worth examining: OWS used milestone-based contracts with multiple parallel manufacturers (so failure of one did not doom the whole), recruited DoD logistics expertise (which had no analogue in HCgov's procurement), and operated under a single integrated leadership team (Azar/Perna), while HCgov was diffuse and uncoordinated. Also, OWS was launched in an emergency that licensed unusual flexibility, while HCgov was launched under normal procurement rules. The lesson is not that "government cannot deliver technology" — it is that the structure of the federal government's procurement and oversight processes makes some kinds of delivery much harder than they need to be, and that emergencies sometimes give institutions permission to do better than they normally do.

Discussion Questions

1. Federal contracting law (the Federal Acquisition Regulation, or FAR) is designed to protect taxpayer interests through competitive bidding, formal requirements documents, and milestone-based payments. How well does this regime work for software development? What specific features of FAR helped or hurt Healthcare.gov?

2. The October 1, 2013 launch date was politically driven. Steel-man both: (a) the case that the administration was right to launch on time (delaying would have created political momentum to repeal the ACA before any enrollment data existed); and (b) the case that the administration was wrong to launch on time (a six-month delay would have produced a working site, which would have generated better enrollment data, which would have created its own political momentum). Which argument do you find more persuasive in retrospect, and why?

3. The U.S. Digital Service was created as an institutional response to the Healthcare.gov failure. Is this kind of "create a new agency to fix the existing agency" approach a reasonable response to bureaucratic dysfunction, or does it just add a new layer of bureaucracy? Identify one specific subsequent USDS project to anchor your answer.

4. Compare Healthcare.gov to Operation Warp Speed (Case Study 1). What are the most important differences in how the two efforts were structured, and what do those differences suggest about when federal government can deliver complex technical projects?

5. Some critics of the Affordable Care Act argued at the time that the Healthcare.gov failure was evidence the program should be repealed. Some defenders argued it was evidence the program needed better implementation but not repeal. With ten years of additional data, what do the marketplace enrollment numbers and the survival of the program under both Trump and Biden administrations suggest about the original question?