Personal blog of Yzmir Ramirez

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, and one that garnered widespread support. There was just one problem: How would they create a viable business?

The roughly 5,700 public safety answering points (PSAPs) in America 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.

People obviously 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 actually 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.

So, who would pay? Who was annoyed enough with America’s antiquated 911 system to be willing to shell out dollars to fix it?

Ultimately, the company iterated itself into essentially an API layer between the thousands of PSAPs on one side and developers of apps and consumer devices on the other. 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’ business model thus became offering 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. Without call center integrations, tech companies wouldn’t use the API — it was essentially useless in that case. 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 lend the company the escape velocity to not just expand across America, but increasingly across the world as well.

In this second part of the EC-1, I’ll analyze RapidSOS’ current product offerings and business strategy, explore the company’s pivot from consumer app to embedded technology and take a look at its nascent but growing international expansion efforts. It offers key lessons on the importance of iterating, how to secure the right customer feedback and determining the best product strategy.

The 411 on a 911 API

It became clear from the earliest stages of RapidSOS’ journey 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-man dispatch center. So, I was working alone, I was answering 911 calls, non-emergency calls, dispatching police, fire and EMS,” she said.

RapidSOS senior director of public safety Karin Marquez. Image Credits: RapidSOS

As a 911 call taker, her very first requirement for every call was figuring out where an emergency is taking place — even before characterizing what is 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 kind of start to build our house on. Every additional data [point] will help to give us a better understanding of what that emergency is, who may be involved, what kind of vehicle they’re involved in — but if I don’t have an address, I can’t send you help.”

Every application is a palimpsest of technologies, each layer forming a base that enables the next layer to function. Web front ends rely on JavaScript and browser DOM, which rely on back-end APIs, which themselves rely on databases.

As one goes deeper down the stack, engineering decisions become ever more conservative — changing the location of a button in a web app is an inconvenience; changing a database engine can radically upend an entire project.

It’s little surprise then that database technologies are among the longest-lasting engineering projects in the modern software developer toolkit. MySQL, which remains one of the most popular database engines in the world, was first released in the mid-1990s, and Oracle Database, launched more than four decades ago, is still widely used in high-performance corporate environments.

Database technology can change the world, but the world in these parts changes very, very slowly. That’s made building a startup in the sector a tough equation: Sales cycles can be painfully slow, even when new features can dramatically expand a developer’s capabilities. Competition is stiff and comes from some of the largest and most entrenched tech companies in the world. Exits have also been few and far between.

That challenge — and opportunity — is what makes studying Cockroach Labs so interesting. The company behind CockroachDB attempts to solve a long-standing problem in large-scale, distributed database architecture: How to make it so that data created in one place on the planet is always available for consumption by applications that are thousands of miles away, immediately and accurately. Making global data always available immediately and accurately might sound like a simple use case, but in reality it’s quite the herculean task. Cockroach Labs’ story is one of an uphill struggle, but one that saw it turn into a next-generation, $2-billion-valued database contender.

The lead writer of this EC-1 is Bob Reselman. Reselman has been writing about the enterprise software market for more than two decades, with a particular emphasis on teaching and educating engineers on technology. The lead editor for this package was Danny Crichton, the assistant editor was Ram Iyer, the copy editor was Richard Dal Porto, figures were designed by Bob Reselman and stylized by Bryce Durbin, and illustrations were drawn by Nigel Sussman.

CockroachDB had no say in the content of this analysis and did not get advance access to it. Reselman has no financial ties to CockroachDB or other conflicts of interest to disclose.

The CockroachDB EC-1 comprises four main articles numbering 9,100 words and a reading time of 37 minutes. Here’s what we’ll be crawling over:

• Part 1: Origin story “CockroachDB, the database that just won’t die” (2,100 words/8 minutes) — Looks at the origins of CockroachDB, from the creation of the popular open-source image editor GIMP to some of Google’s most well-known infrastructure products.
• Part 2: Technical design “How engineers fought the CAP theorem in the global war on latency” (2,400 words/10 minutes) — Analyzes the key differentiation that CockroachDB offers the relational database market, particularly its focus on geography and data storage.
• Part 3: Developer relations and business “‘Developers, as you know, do not like to pay for things‘” (2,200 words/9 minutes) — Explores how CockroachDB engages with developers while also pivoting to the cloud at a key inflection point in its business.
• Part 4: Competitive landscape and future “Scaling CockroachDB in the red ocean of relational databases” (2,400 words/10 minutes) — Evaluates the future of the startup within the extremely competitive landscape of relational databases and what possible exit routes might look like.

We’re always iterating on the EC-1 format. If you have questions, comments or ideas, please send an email to TechCrunch Managing Editor Danny Crichton at danny@techcrunch.com.

There is an art to engineering, and sometimes engineering can transform art. For Spencer Kimball and Peter Mattis, those two worlds collided when they created the widely successful open-source graphics program, GIMP, as college students at Berkeley.

That project was so successful that when the two joined Google in 2002, Sergey Brin and Larry Page personally stopped by to tell the new hires how much they liked it and explained how they used the program to create the first Google logo.

In terms of good fortune in the corporate hierarchy, when you get this type of recognition in a company such as Google, there’s only one way you can go — up. They went from rising stars to stars at Google, becoming the go-to guys on the Infrastructure Team. They could easily have looked forward to a lifetime of lucrative employment.

But Kimball, Mattis and another Google employee, Ben Darnell, wanted more — a company of their own. To realize their ambitions, they created Cockroach Labs, the business entity behind their ambitious open-source database CockroachDB. Can some of the smartest former engineers in Google’s arsenal upend the world of databases in a market spotted with the gravesites of storage dreams past? That’s what we are here to find out.

Berkeley software distribution

Mattis and Kimball were roommates at Berkeley majoring in computer science in the early-to-mid-1990s. In addition to their usual studies, they also became involved with the eXperimental Computing Facility (XCF), an organization of undergraduates who have a keen, almost obsessive interest in CS.

CockroachDB was intended to be a global database from the beginning. The founders of Cockroach Labs wanted to ensure that data written in one location would be viewable immediately in another location 10,000 miles away. The use case was simple, but the work needed to make it happen was herculean.

The company is betting the farm that it can solve one of the largest challenges for web-scale applications. The approach it’s taking is clever, but it’s a bit complicated, particularly for the non-technical reader. Given its history and engineering talent, the company is in the process of pulling it off and making a big impact on the database market, making it a technology well worth understanding. In short, there’s value in digging into the details.

In part 1 of this EC-1, I provided a general overview and a look at the origins of Cockroach Labs. In this installment, I’m going to cover the technical details of the technology with an eye to the non-technical reader. I’m going to describe the CockroachDB technology through three questions:

1. What makes reading and writing data over a global geography so hard?
2. How does CockroachDB address the problem?
3. What does it all mean for those using CockroachDB?

What makes reading and writing data over a global geography so hard?

Spencer Kimball, CEO and co-founder of Cockroach Labs, describes the situation this way:

There’s lots of other stuff you need to consider when building global applications, particularly around data management. Take, for example, the question and answer website Quora. Let’s say you live in Australia. You have an account and you store the particulars of your Quora user identity on a database partition in Australia.

But when you post a question, you actually don’t want that data to just be posted in Australia. You want that data to be posted everywhere so that all the answers to all the questions are the same for everybody, anywhere. You don’t want to have a situation where you answer a question in Sydney and then you can see it in Hong Kong, but you can’t see it in the EU. When that’s the case, you end up getting different answers depending where you are. That’s a huge problem.

Reading and writing data over a global geography is challenging for pretty much the same reason that it’s faster to get a pizza delivered from across the street than from across the city. The essential constraints of time and space apply. Whether it’s digital data or a pepperoni pizza, the further away you are from the source, the longer stuff takes to get to you.

In the previous part of this EC-1, we looked at the technical details of CockroachDB and how it provides accurate data instantaneously anywhere on the planet. In this installment, we’re going to take a look at the product side of Cockroach, with a particular focus on developer relations.

As a business, Cockroach Labs has many things going for it. The company’s approach to distributed database technology is novel. And, as more companies operate on a global level, CockroachDB has the potential to gain some significant market share internationally. The company is seven years into a typical 10-year maturity model for databases, has raised $355 million, and holds a $2 billion market value. It’s considered a double unicorn. Few database companies can say this.

But its growth depends upon securing the love of developers while also making its product easier to use for new customers. To that end, I’m going to analyze the company’s pivot to the cloud as well as its extensive outreach to developers as it works to set itself up for long-term, sustainable success.

Cockroach Labs looks to the cloud

These days, just about any company of consequence provides services via the internet, and a growing number of these services are powered by products and services from native cloud providers. Gartner forecasted in 2019 that cloud services are growing at an annual rate of 17.5%, and there’s no sign that the growth has abated at all.

Its founders’ history with Google back in the mid-2000s has meant that Cockroach Labs has always been aware of the impact of cloud services on the commercial web. Unsurprisingly, CockroachDB could run cloud native right from its first release, given that its architecture presupposes the cloud in its operation — as we saw in part 2 of this EC-1.

Most database startups avoid building relational databases, since that market is dominated by a few goliaths. Oracle, MySQL and Microsoft SQL Server have embedded themselves into the technical fabric of large- and medium-size companies going back decades. These established companies have a lot of market share and a lot of money to quash the competition.

So rather than trying to compete in the relational database market, over the past decade, many database startups focused on alternative architectures such as document-centric databases (like MongoDB), key-value stores (like Redis) and graph databases (like Neo4J). But Cockroach Labs went against conventional wisdom with CockroachDB: It intentionally competed in the relational database market with its relational database product.

While it did face an uphill battle to penetrate the market, Cockroach Labs saw a surprising benefit: It didn’t have to invent a market. All it needed to do was grab a share of a market that also happened to be growing rapidly.

In previous parts of this EC-1, I looked at the origins of CockroachDB, presented an in-depth technical description of its product as well as an analysis of the company’s developer relations and cloud service, CockroachCloud. In this final installment, we’ll look at the future of the company, the competitive landscape within the relational database market, its ability to retain talent as it looks toward a potential IPO or acquisition, and the risks it faces.

CockroachDB’s success is not guaranteed. It has to overcome significant hurdles to secure a profitable place for itself among a set of well-established database technologies that are owned by companies with very deep pockets.

It’s not impossible, though. We’ll first look at MongoDB as an example of how a company can break through the barriers for database startups competing with incumbents.

When life gives you Mongos, make MongoDB

Dev Ittycheria, MongoDB CEO, rings the Nasdaq Stock Market Opening Bell. Image Credits: Nasdaq, Inc

MongoDB is a good example of the risks that come with trying to invent a new database market. The company started out as a purely document-centric database at a time when that approach was the exception rather than the rule.

Web developers like document-centric databases because they address a number of common use cases in their work. For example, a document-centric database works well for storing comments to a blog post or a customer’s entire order history and profile.

Take a close look at any ambitious startup and you’ll find pugnacity nestled in its core. Stubbornness and a bullheaded belief in the worth of what a company wants to bring to fruition is often the biggest driver of its success, and the people at such companies also tend to share this quality.

So it wouldn’t be too far off the mark to say the people at Expensify are a stubborn lot — to the company’s ultimate benefit. This group of P2P pirates/hackers that set out to build an expense management app stuck to their gut, made their own rules. They asked questions few thought of, like: Why have lots of employees when you can find a way to get work done and reach impressive profitability with a few? Why work from an office in San Francisco when the internet lets you work from anywhere, even a sailboat in the Caribbean?

It makes sense in a way: If you’re a pirate, to hell with the rules, right? And even more so when nobody can explain the rules in the first place.

With that in mind, one could assume Expensify decided to ask itself: Why not build our own totally custom tech stack? Indeed, Expensify has made several tech decisions that were met with disbelief — from having an open-source frontend and cross-platform mobile development to hiring contractors to train its AI and recruiting open-source contributors — but its belief in its own choices has paid off over the years, and the company is ready to IPO any day now.

How much of a tech advantage Expensify enjoys owing to such choices is an open question, but one thing is clear: These choices are key to understanding Expensify and its roadmap. Let’s take a look.

Built on Bedrock

I think another question Expensify also decided to ask in its early days was something like: Why not have our database on top of a technology that’s built for small-scale application software?

It may sound incredible, but Expensify actually runs on a custom database built on top of SQLite. This is surprising, because despite being one of the most widely deployed database engines, SQLite is known for running on small, embedded systems like smartphones and web browsers, not powering enterprise-scale databases.

This custom database is called Bedrock, and its architecture is as unique as they come. Expensify explains it as an “RDBMS optimized for self-healing replication across relatively slow, relatively unreliable WAN (internet) connections, enabling extremely high availability/high performance multi-datacenter deployments without any single point of failure.” RDBMS means relational database management system, describing SQLite and other row-based databases where entries are interconnected with each other.

But why would Expensify build this instead of going for any number of widely available enterprise database solutions?

To answer that question, we need to go back to the early days of the company, which was originally a side project for its founder and CEO, David Barrett. His initial idea was to develop a prepaid card for the homeless, but this required putting a server on the Visa network, which brought several strict requirements and challenges. “I would say one of the most difficult [parts] was that I needed the ability to automatically replicate and failover,” Barrett told TechCrunch when we interviewed him a couple of months ago.

This was no easy feat in 2007, but Barrett was up for the challenge. “I just hit a moment where the technology available off the shelf just wasn’t that good. And I happened to be a peer-to-peer software developer who had tons of spare time and really wanted to build this thing to put on the Visa backend,” he said. The P2P aspect was important, as Barrett had the skills to make it work. His first hires for Expensify, P2P engineers he had worked with at Red Swoosh and Akamai, were also unusually suited for the job.

Expensify may be the most ambitious software company ever to mostly abandon the Bay Area as the center of its operations.

The startup’s history is tied to places representative of San Francisco: The founding team worked out of Peet’s Coffee on Mission Street for a few months, then crashed at a penthouse lounge near the 4th and King Caltrain station, followed by a tiny office and then a slightly bigger one in the Flatiron building near Market Street.

Thirteen years later, Expensify still has an office a few blocks away on Kearny Street, but it’s no longer a San Francisco company or even a Silicon Valley firm. The company is truly global with employees across the world — and it did that before COVID-19 made remote working cool.

“Things got so much better when we stopped viewing ourselves as a Silicon Valley company. We basically said, no, we’re just a global company,” CEO David Barrett told TechCrunch. That globalism led to it opening a major office in — of all places —a small town in rural Michigan. That Ironwood expansion would eventually lead to a cultural makeover that would see the company broadly abandon its focus on the Bay Area, expanding from a headquarters in Portland to offices around the globe.

It makes sense that a company founded by internet pirates would let its workforce live anywhere they please and however they want to. Yet, how does it manage to make it all work well enough to reach $100 million in annual revenue with just a tad more than 100 employees?

As I described in Part 2 of this EC-1, that staffing efficiency is partly due to its culture and who it hires. It’s also because it has attracted top talent from across the world by giving them benefits like the option to work remotely all year as well as paying SF-level salaries even to those not based in the tech hub. It’s also got annual fully paid month-long “workcations” for every employee, their partner and kids.

Yet the real story is how a company can become untethered from its original geography, willing to adapt to new places and new cultures, and ultimately, give up the past while building the future.

The influence of a founder on their company’s culture cannot be overstated. Everything from their views on the product and business to how they think about people affects how their company’s employees will behave, and since behavior in turn informs culture, the consequences of a founder’s early decisions can be far-reaching.

So it’s not very surprising that Expensify has its own take on almost everything it does when you consider what its founder and CEO David Barrett learned early in his life: “Basically everyone is wrong about basically everything.” As we saw in part 1 of this EC-1, this led him to the revelation that it’s easier to figure things out for yourself than finding advice that applies to you. Eventually, these insights — and the adventurous P2P hacker attitude he nurtured alongside his colleagues and Travis Kalanick at Red Swoosh — would inform how he would go about shaping Expensify.

It’s striking how Expensify has managed to maintain this character 13 years later, even on the threshold of an IPO. How did this happen? During a series of interviews in February and early March, we found the answer is tied to the level of thought and effort this expense management business puts into its culture.

You see, the people at Expensify are prepared to invent their own playbook, develop it and, if needed, rewrite it completely. Its HR policies and strategy are tailored to find people who would have fun building an expense management product. It has a unique growth and recognition scheme to offset the drawbacks of a flat organizational structure. It’s even got a “Senate” that vets all major decisions. No kidding.

All this, and more, has ultimately helped Expensify reach more than 10 million users and achieve $100 million in annual revenue with just 130 employees. Let’s take a closer look at how Expensify makes it happen.

“We want the fewest people necessary to get the job done”

It’s clear Expensify’s unusually high employee-to-revenue ratio is intentional: “We want the fewest people necessary to get the job done,” Barrett says. But how do you actually achieve it? How do you hire and keep people who can deliver such results? Barrett had to learn how the hard way.

Expensify’s first team was based in San Francisco and comprised Barrett’s old Red Swoosh and Akamai colleagues, who joined a few months after Akamai fired him. A small team was enough to get started, but it was much more difficult to hire additional people. Barrett is eager to clarify the Valley is not really the best place to recruit talent: “Sure, Silicon Valley has a ton of really awesome people, but all of them have jobs!,” he says.

Let’s make it clear from the outset that this story is about an expense management SaaS business called Expensify. As you’d expect, yes, this is about the expense management market and how Expensify has grown, its technology and all of that. Normally, that would make us change the channel. But this is also a story about pirates; peer-to-peer hackers who asked, “Why not work from Thailand and dozens of countries across the globe?” and actually did it using P2P hacker culture as a model for consensus-driven decision-making — all with pre-Uber Travis Kalanick in a guest-starring role.

Most interestingly, this is a story about just not giving a damn about what anyone goddamn thinks, an approach to life and business that led to more than $100 million in annual revenue, and an IPO incoming on what looks to be a very quick timetable. Prodigious revenues, 10 million users and only 130 employees running the whole shebang — that’s a hell of an achievement in only 13 years.

If you’re going a bit “WTF,” well, we’d concur. Expensify is as contradictory as they come in the enterprise world. It’s managed to take what might well be the most boring part of the corporate business stack and turn it into something special. It doesn’t borrow its culture from other startups, it built its own tech stack from the ground up, and even hires in a completely radical way. Oh, and no one really has job titles either, because why the hell bother with hierarchy anyway? They’re pirates after all.

If expense management is about avoiding corporate plunder, then letting the pirates and hackers run the ship is probably the best approach. And now, Expensify is plundering the corporate spend world one travel ticket and business meal at a time just as the world is rebuilding in the wake of COVID-19.

TechCrunch’s writer and analyst for this EC-1 is Anna Heim. Heim is a tech journalist and former startup founder who has written for different tech publications since 2011. She recently joined Extra Crunch as a daily reporter, where she will be sharing insights on startups, particularly in SaaS. The lead editor of this package was Ram Iyer, the series editor was Danny Crichton, the copy editor was Richard Dal Porto, and original illustrations were created by Nigel Sussman with art direction from Bryce Durbin.

Expensify had no say in the content of this analysis and did not get advance access to it. Heim has no financial ties to Expensify or other conflicts of interest to disclose.

The Expensify EC-1 will be a serialized sequence of five articles published over the course of the coming weeks. We interviewed the company in February and March, well before the company announced a confidential filing of its S-1 to the SEC. Let’s take a look:

• Part 1: Origin story “How a band of P2P hackers planted the seeds of a unique expense management giant” (2,400 words/10 minutes) — Explores the colorful history of the Expensify founders’ days with Travis Kalanick’s venture before Uber, a P2P content distribution startup called Red Swoosh, and how that experience would eventually influence what would one day become an expense management giant.
• Parts 2-5: Upcoming shortly.

We’re always iterating on the EC-1 format. If you have questions, comments or ideas, please send an email to TechCrunch Managing Editor Danny Crichton at danny@techcrunch.com.