Sometimes, the best missions are the hardest to fund. For the founders of RapidSOS, improving the quality of emergency response by adding useful data, like location, to 911 calls was an inspiring objective that garnered widespread support. There was just one problem: How would they create a viable business?
America’s roughly 5,700 public safety answering points (PSAPs) weren’t great contenders. Cash-strapped and highly decentralized, 911 centers already spent their meager budgets on staffing and maintaining decades-old equipment, and they had few resources to improve their systems. Plus, appropriations bills in Congress to modernize centers have languished for more than a decade, a topic we’ll explore more in part four of this EC-1.
Who would pay? Who was annoyed enough with America’s antiquated 911 system to be willing to shell out dollars to fix it? People desire better emergency services — after all, they are the ones who will dial 911 and demand help someday. Yet, they never think about emergencies until they happen, as RapidSOS learned from the poor adoption of its Haven app we discussed in part one. People weren’t ready to pay a monthly subscription for these services in advance.
Ultimately, the company iterated itself into an API layer between the thousands of PSAPs on one side and developers of apps and consumer devices on the other. So, who would pay? Who was annoyed enough with America’s antiquated 911 system to be willing to shell out dollars to fix it?
These developers wanted to include safety features in their products but didn’t want to engineer hundreds of software integrations across thousands of disparate agencies. RapidSOS’s business model thus offered free software to 911 call centers while charging tech companies to connect through its platform.
It was a tough road and a classic chicken-and-egg problem. Tech companies wouldn’t use the API without call center integrations — it was essentially useless. Call centers, for their part, didn’t want to use software that didn’t offer any immediate value, even if it was being given away for free.
This is the story of how RapidSOS just plowed ahead against those headwinds from 2017 onward, ultimately netting itself hundreds of millions in venture funding, thousands of call agency clients, dozens of revenue deals with the likes of Apple, Google, and Uber, and partnerships with more software integrators than any startup has any right to secure. Smart product decisions, a carefully calibrated business model, and tenacity would eventually give the company the escape velocity to expand across America and increasingly worldwide.
In this second part of the EC-1, I’ll analyze RapidSOS’ current product offerings and business strategy, explore its pivot from consumer app to embedded technology and look at its nascent but growing international expansion efforts. It offers key lessons on iterating, securing customer feedback, and determining the best product strategy.
The 411 on a 911 API
From the earliest stages of RapidSOS’ journey, it became clear that getting data into the 911 center would be its first key challenge. The entire 911 system — even today in most states — is built for voice and not data.
Karin Marquez, senior director of public safety at RapidSOS, who we met in the introduction, worked for decades at a PSAP near Denver, working her way up from call taker to a senior supervisor. “When I started, it was a one-person dispatch center. So, I was working alone; I was answering 911 calls, non-emergency calls, dispatching police, fire, and EMS,” she said.
As a 911 call taker, her first requirement for every call was figuring out where an emergency occurred — even before characterizing what was happening. “Everything starts with location,” she said. “If I don’t know where you are, I can’t send you help. Everything else we can start to build our house on. Every additional data [point] will help us better understand what that emergency is, who may be involved, and what kind of vehicle they’re involved in — but if I don’t have an address, I can’t send you help.”
