Why COVIDtests.gov worked where HealthCare.gov stumbled

The Biden Administration launched COVIDtests.gov this week, and by most accounts, the site has performed well. While apartment dwellers have reported difficulties entering their information, these sorts of bugs are expected and don’t point to fundamental problems. It has exceeded expectations for a government website, handling large, nationwide demand and absorbing intense interest from a public eager for more resources to combat the ongoing coronavirus pandemic.

As of writing, there appears to have been, at least from publicly available indicators, no downtime or outages of the service, even as many hundreds of thousands of users accessed the site simultaneously.

That the site would stay up amidst widespread attention was not a given. Many observers noted the parallels to the 2013 debut of HealthCare.gov: launching a new, high-profile, health-related website into a pressure-filled context with enormous scrutiny and public skepticism. (Disclosure: I was a member of the team that helped turn HealthCare.gov around and am now a contractor working on HealthCare.gov with the Centers for Medicare & Medicaid Services.)

So why did COVIDtests.gov work where HealthCare.gov stumbled? In these past eight years, the U.S. government has gained more experience building these kinds of services. Agencies have brought in the kind of guiding technical talent that can advise leadership, and teams are exercising better judgment around launches and operating websites.

It’s not perfect nor as widely spread as we’d like, as various government sites continue to struggle, but the U.S. Digital Service, 18F, a new crop of CIOs, and a cadre of modern vendors have imbued agencies with fresh perspectives and playbooks. In this case, it looks as though the web team at the U.S. Postal Service (USPS) has also learned the right lessons and deserves much of the credit.

What do we know about this new site? I took a deep dive into the architecture of COVIDtests.gov, and what I learned was that the team at USPS did not use their existing web properties, but built a new site for this purpose. They used products from Amazon Web Services (AWS), including content delivery networks for high-performance serving, reliable file storage for HTML and images, an API built with so-called “serverless” functions, and a database that automatically scales with demand.

What this means is that the site is designed entirely with well-known components that are proven to handle heavy loads. This is the same infrastructure that the largest platforms on the web use. The value of managed services such as these is that there are fewer knobs to turn and fewer visible moving parts to break. This reduces almost all of the burden for keeping things up and running, freeing the team to focus on providing the best user experience. Clearly, the team managing this launch planned for outsized demand, well above what a typical government site experiences, and made technology choices accordingly.

It’s also a remarkably simple site from a user-experience perspective. The user goes directly from the landing page to the order form. A few moments of entering information, a confirmation dialog box, and the order is submitted. The UI simplicity and architecture reinforce each other.

Contrast this with HealthCare.gov’s initial launch, which architecturally looked more like enterprise software than a modern digital service. Even though AWS and similar cloud hosting providers had been around by that point for years, the site was hosted in a single private data center, where members of a subcontractor team had to manage individual servers and network connections. When things got operationally dicey, it was a challenging environment in which to recover and scale. Hosting in the cloud removes this pain point.

Additionally, the UI was complex, and users were required to navigate a challenging account sign-up and an application for eligibility before they could browse health plans. This required many back and forth interactions with the servers, and many individual custom components to support, all of which created opportunities for things to go wrong.

HealthCare.gov is the website for a means-tested program, and covidtests.gov is available to a much wider swath of the public, which does make for a simpler implementation. We can’t necessarily compare government programs apples-to-apples. However, were HealthCare.gov built from scratch today, its design would more resemble covidtests.gov than not.

Ultimately, the proof will be whether the USPS can fulfill all the orders and deliver them to the public who are anxious for more tools to help get them through yet another high-stress period of the pandemic. This website, while necessary to get right, is only one part of how the public will experience the government’s pandemic-related services. As the Administration implements other tenets of the recent Customer Experience Executive Order, they’ll need to build upon reliable digital services approaches like this to improve the public’s perception of government.

Paul Smith is chief technology officer and co-founder at digital services consultancy Ad Hoc. He was a leader of the team that fixed HealthCare.gov after its troubled launch, and before that worked on the 2012 re-election campaign of President Obama as deputy director of technology of the DNC.