We want to be the premier government digital services agency.

Ad Hoc is a software design and engineering company that came out of the successful effort to rescue HealthCare.gov after its disastrous initial launch.

Ad Hoc is focused on developing, delivering, and operating fast, stable, and well-designed digital services on behalf of U.S. government clients. Our work enables agencies to provide transactional and informational services to their users. We bring technologists together to collaborate closely with government partners, crafting solutions and delivering software that works.

Why are we called Ad Hoc?

Origins

In October 2013, before Ad Hoc the company existed, future co-founders Greg and Paul were two of a group of a half-dozen people, technologists from outside government, assembled by then-US CTO Todd Park to go in among the large group of contractors and government employees working on HealthCare.gov. Our mission was to help diagnose and troubleshoot the ailing site, which had launched at the beginning of the month but had failed to stabilize or enroll many people. As Todd was wont to say, our team needed both high IQ and high EQ — we weren't there to blow up the work being done. Everyone needed to work together to get the site on the right track. We were there to try to be useful, based on our experience and expertise from working on high-profile, high-demand consumer web technology. So we were mindful of how we presented ourselves to the rest of the larger team.

One of the first days we were on site, we found ourselves in a meeting with many of the top executives of the various stakeholders building the site. Most people working on HealthCare.gov didn't know who we were yet. We went around the table doing introductions, standard meeting preliminaries.

Then the room's attention came to our small team. Any of us could have said, "I'm So-and-So, from the White House," but instinctively we all knew not to say that. For one, it wasn't true: with the exception of one member of the team, we weren't White House employees. But more importantly, we didn't want to throw that around gratuitously. We needed to develop trust to work and communicate together to solve the site's problems, not have someone clam up or put a rosy spin on things because of what they perceived us to be representing. We could have said where we each were from individually, our own organizational affiliations, but there was also a value in having us seen by others as our own team.

When the time came, the first of us said, "I'm from the ad hoc team", and it was immediately and obviously right. We had been assembled, dictionary-definition-wise, for a particular purpose, for this rescue effort. It went by without any comment in the moment from the team, and we all just adopted it from there on out. Most people interpreted it as the uppercase "the Ad Hoc team". In any case, it was useful, greasing the wheels of normal business affiliation identification, and soon the whole HealthCare.gov organization knew and referred to us as the Ad Hoc team. Read more on the rescue of HealthCare.gov.

Why we chose it for the name of the company

Greg and Paul had a notion to start a company that provided modern software delivery to government from our experience working on the rescue of HealthCare.gov. We saw up close the consequences of a lack of expertise in specific domains—design, engineering, operations—and we wanted to directly address those things that we had witnessed during the rescue with a new business. The name “Ad Hoc” seemed the right choice to us. We knew we had to live up to the name that had been used by our initial small group as well as the many who joined the effort later on and throughout the months following to stabilize HealthCare.gov. We hope that the legacy of the HealthCare.gov rescue lives on in part through the care and diligence we put into every project we work on.

The specificity of Ad Hoc

Some see the words ad hoc as a pejorative, as if it is describing something slipshod, or something done haphazardly. We like the name Ad Hoc because it evokes for us the original notion of something purpose-driven, something built for a specific reason. We build every one of our teams to solve a specific problem, like providing API access to information about health plans sold on HealthCare.gov, simplifying Veterans' access to benefits, designing and implementing data reporting tools for health care providers, or modernizing Medicare.gov.

Related

Learn about our partners and programs.