# Why Healthcare.gov Cost Taxpayers $2.1B and What a Real Product Team Would Have Done Differently

By: Justin Abrams
Published: 2026-01-04

Healthcare.gov launched as a $2.1B disaster. The fix did not come from more contractors. Here is what enterprise and mission driven organizations should learn before their next big software build.

On October 1, 2013, [Healthcare.gov](https://www.healthcare.gov) launched as the centerpiece of the [Affordable Care Act](https://en.wikipedia.org/wiki/Affordable_Care_Act). Within hours it was effectively unusable. Pages timed out. Account creation failed. Enrollment data corrupted in transit between systems. By the end of the first week, only six people had successfully completed enrollment through the federal exchange.

The project had taken three years and [cost the federal government over 2.1 billion dollars by some estimates](https://www.cbsnews.com/news/healthcaregov-price-tag-2-1-billion/). It involved roughly 55 contractors, an estimated 16 million lines of code, and no single accountable product owner. The fix did not come from adding more contractors. The fix came when [a small team of veterans from companies like Google and a handful of startups parachuted in](https://www.nytimes.com/2013/11/23/us/politics/from-the-start-signs-of-trouble-at-health-portal.html), identified the critical bottlenecks within days, and rewrote the systems that mattered.

The technology was never the hard part. The leadership was.

### The Body Shop Problem

Healthcare.gov was not built. It was procured. The federal government wrote requirements documents, issued contracts, and hired vendors to deliver against specifications. Each vendor delivered exactly what their contract required. Nobody delivered a working product because nobody was responsible for the product. They were responsible for the line items.

This is what happens when you treat software as a procurement problem instead of a leadership problem. Every body shop in the world will happily staff your project with bodies. Most of them will hit their hours, deliver their deliverables, and move on to the next contract. None of them will own the outcome because none of them are paid to.

You see this pattern in enterprise software constantly. A large organization with a critical project hires a large contractor with a large bench. The contractor staffs the project with whoever is available. Project managers manage timelines, not products. Engineers build modules in isolation, not features in context. Quality assurance happens at the end, not throughout. The whole thing gets delivered on time and immediately falls over in production.

### What the Rescue Team Did Differently

When the Obama administration brought in the rescue team, they did not add more people. They subtracted layers. They put one technical lead in charge. They made decisions in minutes instead of weeks. They focused on the few transactions that actually mattered to users, ignored the cosmetic problems, and shipped fixes daily instead of monthly. The story is captured in detail in [Steven Brill's Time magazine feature on the rescue](https://time.com/10228/obamas-trauma-team/).

In other words, they ran the project like a small product team instead of a large procurement program.

The lesson is not that government cannot build software. The lesson is that nobody can build software through procurement. Software is built by small teams with clear ownership, fast feedback loops, and the authority to make decisions. Always has been. Always will be.

### Why Mission Driven Organizations Get This Wrong

Healthcare.gov is the extreme version, but the same pattern plays out constantly in nonprofits, healthcare systems, government agencies, and mission driven organizations. The work matters too much to leave to a small team, the thinking goes, so we will hire the biggest, most established firm we can afford. They have done this before. They have certifications. They have references.

What those organizations are actually buying is a process designed to reduce risk for the contractor, not deliver outcomes for the user. The biggest firms have the most overhead because they have the most layers, and every layer adds cost and slows decisions. By the time a critical fix gets approved, the original problem has compounded.

I have seen this firsthand working with mission driven organizations. The work is important. The stakes are real. The people inside the organization care deeply about getting it right. And then they hire a vendor that treats their mission as a line item, and the project loses its soul somewhere between the kickoff meeting and the second change order.

### What a Real Product Team Looks Like

At [Cause of a Kind](https://causeofakind.com), we have built our model specifically for projects that matter too much to hand to a body shop. We are small by design. Full stack engineers who can hold the whole product in their head. Designers who sit in the same conversations as the developers. Product strategists who have launched companies, not just managed timelines.

We have worked with mission driven organizations in this exact spot. [NASHIA](https://www.nashia.org), the National Association of State Head Injury Administrators, came to us needing technology that served a community of brain injury survivors and the professionals who support them. BEST Connections is a platform for the TBI community that has to feel like care, not software. These are not projects where you can throw bodies at the problem. They are projects where every decision has to be made by someone who understands both the technology and the mission.

The same logic holds for enterprise clients. I spent years at [BrightEdge](https://www.brightedge.com) consulting for [Marriott](https://www.marriott.com), [Disney](https://www.disney.com), [Salesforce](https://www.salesforce.com), [Oracle](https://www.oracle.com), and dozens of the most recognizable brands on the planet. The pattern was always the same. The projects that succeeded had small accountable teams. The projects that struggled had large procurement programs.

### What to Do If Your Project Is Going Sideways

If you are reading this and your software project is over budget, behind schedule, and producing deliverables that do not feel like a product, the problem is structural, not tactical. Adding more people will make it worse. Replacing the project manager will not help. The fix is to shrink the team, clarify the ownership, and bring in product leadership that has actually shipped products.

Software is a leadership problem dressed up as a technical one. Hire accordingly.

Forward to Extraordinary. [Connect with me on LinkedIn.](https://www.linkedin.com/in/cuzzinjustin/)

Canonical URL: https://www.causeofakind.com/blog/why-healthcare-gov-cost-taxpayers-2-1b-and-what-a-real-product-team-would-have-done-differently