EC-1
Auto Added by WPeMatico
RapidSOS learned that the best product design is sometimes no product design
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.
Who would pay? Who was annoyed enough with America’s antiquated 911 system to be willing to shell out dollars to fix it?
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.”
Powered by WPeMatico
The CockroachDB EC-1
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.
Powered by WPeMatico
CockroachDB, the database that just won’t die
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.
Cockroach Labs was started by developers and stays true to its roots to this day.
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.
Powered by WPeMatico
How engineers fought the CAP theorem in the global war on latency
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.
Using CockroachDB’s multiregion feature to segment data according to geographic proximity fulfills Cockroach Labs’ primary directive: To get data as close to the user as possible.
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:
- What makes reading and writing data over a global geography so hard?
- How does CockroachDB address the problem?
- 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.
Powered by WPeMatico
“Developers, as you know, do not like to pay for things”
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.
The company is now aggressively expanding into the database-as-a-service space, offering its own technology in a fully managed package, expanding the spectrum of clients who can take immediate advantage of its products.
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.
Powered by WPeMatico
Scaling CockroachDB in the red ocean of relational databases
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.
Cockroach Labs has a bright future, compelling technology, a lot of money in the bank and has an experienced, technically astute executive team.
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.
Powered by WPeMatico
The Nubank EC-1
Brazil is a country riven with economic contradictions. It has one of the largest and most profitable banking industries in Latin America, and is among the world’s most developed financial markets. Financial transactions that would take days to process in the United States through ACH happen instantaneously in Brazil. This sophistication, however, masks a backward state of affairs plagued by appalling customer service, exorbitant fees and lack of banking access for many.
The country’s financial system is volatile and often leaves its citizens with few or no alternatives. According to an HBS case study, “in December 2018 the interest rate in Brazil for corporate loans was 52.3%, for consumer loans it was 120.0% and for credit card indebtedness it was 272.42%.” Those rates are many multiples higher compared to figures in neighboring countries.
Brazil’s banking system is a massive market, and one ill-served by incumbents. If someone could thread the needle of product development, strategy and political horse trading required to build a bank in a country where it is nearly impossible for foreigners to own or invest in a bank, it would be one of the great startup and economic success stories of this century.
Nubank is on its way to realizing that objective. Its story is one of unmitigated success, even by the standards of our EC-1 series on high-flying companies and their hard-learned lessons. Just last week, this Brazilian credit card and banking fintech raised a $750 million round led by Berkshire Hathaway at a $30 billion valuation, becoming one of the most valuable startups in the world. It has 40 million users across Brazil, as well as Mexico and Colombia.
Yet, it’s a startup with a CEO and co-founder who isn’t Brazilian, didn’t speak the local language of Portuguese, hadn’t started a company before, and didn’t really know a lot about banking to begin with. This is a story of how raw execution, a “faster, faster” mentality and a fanaticism for making customer experience as enjoyable as a trip to Disney World can completely change the history of an industry — and country — forever.
Our lead writer for this EC-1 is Marcella McCarthy. McCarthy, who spent significant time in Brazil growing up and is trilingual in English, Spanish and Portuguese, has been covering the LatAm and Miami ecosystems for TechCrunch with an eye to the disruption underway in these interconnected regions. The lead editor for this package was Danny Crichton, the assistant editor was Ram Iyer, the copy editor was Richard Dal Porto, and illustrations were drawn by Nigel Sussman.
Nubank had no say in the content of this analysis and did not get advance access to it. McCarthy has no financial ties to Nubank or other conflicts of interest to disclose.
The Nubank EC-1 comprises four main articles numbering 9,200 words and a reading time of 37 minutes. Here’s what’s in the bank:
- Part 1: Origin story “How contrarian hires and a pitch deck started Nubank’s $30 billion fintech empire” (2,350 words/9 minutes) — Explores the challenges and opportunities in Brazil’s banking system and how co-founder David Velez assembled a unique team to take on some of the richest banks in the world.
- Part 2: Co-founder dynamics “One woman’s drive to make a neobank as magical as Disney” (1,900 words/8 minutes) — Profiles Nubank co-founder Cristina Junqueira and how she linked up with Velez, fundraised while pregnant and adapted her role to match the frantic pace of scaling Nubank.
- Part 3: Launching and scaling “How Nubank’s CX strategy made it one of the most loved digital banks” (2,700 words/11 minutes) — Analyzes the launch of Nubank’s now ubiquitous purple credit card, how the company scaled to serve as many people as possible, and its eventual foray into banking.
- Part 4: Market expansion and future “Which Nubank will own the financial revolution?” (2,250 words/9 minutes) — Evaluates Nubank’s expansion into Mexico and Colombia, the competitive landscape in Brazil, and the challenges that lie ahead.
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.
Powered by WPeMatico
How contrarian hires and a pitch deck started Nubank’s $30 billion fintech empire
For most startups, the hardest early challenge is identifying a market and a product to serve it. That wasn’t the case for Nubank CEO David Velez, who understood the massive potential for success if he could break into Latin America’s most valuable economy with even a moderately modern banking offering.
Instead, the challenge was how to rebuild the concept of a bank in a country where banking is widely hated, all while the incumbents heavily entrenched with the state worked to block every move.
Nubank knew its market and geography, and through tenacious fundraising, inventive marketing and product development, and a series of contrarian hires, Velez and his team stripped bare the morass of Brazilian banking to build one of the world’s great fintech companies.
The challenge was how to rebuild the concept of a bank in a country where banking is widely hated, all while the incumbents heavily entrenched with the state worked to block every move.
In the first part of this EC-1, I’ll look at how Velez brought his skills and experience to bear on this market, how Nubank was founded in 2013, and how the team brought a Californian rather than Brazilian vibe to their first office on — no joke — California Street, in a neighborhood called Brooklin in the city of São Paulo.
The makings of an entrepreneur
The idea of being his own boss was ingrained in Velez from his earliest days in Colombia, where he grew up in an entrepreneurial family, with a father who owned a button factory. “I heard from my dad over and over again that you need to start your own company,” Velez said.
But years would pass and Velez still had no idea what he wanted to do. To “kill time,” and also to surround himself with entrepreneurial energy, Velez attended Stanford University — partially financed by the sale of some livestock — and then worked as an analyst at Goldman Sachs and Morgan Stanley before switching to venture capital at General Atlantic and Sequoia.
Powered by WPeMatico
One woman’s drive to make a neobank as magical as Disney
As we mentioned in part 1 of this EC-1, David Velez had two key co-founding roles he needed to fill to get started building Nubank. For one, he needed a CTO to lead the engineering side of the business, as Velez didn’t have an engineering background.
Edward Wible, an American computer science graduate who spent most of his career in private equity, would take that responsibility. He didn’t bring years of coding experience, but he had qualities that Velez considered more important: A strong belief in the potential of the product and an equally intense commitment to working on it.
Given the occasionally hostile reaction of most incumbent banks to their customers in Brazil, Nubank’s starkly contrasting openness and transparency has garnered a huge following.
That left an even more important role to fill — one that was much harder to define. This other co-founder would need to blend knowledge of the Brazilian market and local savvy with expertise in banking, all while embodying a Silicon Valley ethos of focusing on customers. This person would also have to work in São Paulo for minimal wages out of a small office with just one bathroom, all in the belief that their equity (both stock and sweat) would one day be worth it.
Velez would eventually stumble upon Cristina Junqueira, who was qualified to do all this, and much, much more.
“Once someone said I was the glue of the operation, and that someone else was the brains. And I said, ‘No, I’m the glue and the brains, and I bet my brain is even better than his,”’ Junqueira said.
Junqueira didn’t just lead Nubank’s drive into the Brazilian market, she also upended age-old notions of what it means to be a 21st-century bank. Her inspiration was nothing short of Disney, and her mission was to create a bank as popular as the magical kingdom itself.
A bank. As popular as Disney. Sounds like a fairy tale, frankly.
Raised to be a doer
Unlike her co-founders Velez and Wible, Junqueira grew up in Nubank’s home market of Brazil. The eldest of four sisters, she remembers her parents — both dentists — always assiduously working to maintain their practice.
Their work ethic trickled down, but so did responsibility. As the oldest at home, she was forced to grow up quickly and take on responsibilities from an early age. “I remember being 11 years old and doing grocery shopping for the month,” she said. “I did everything very young.”
Powered by WPeMatico
How Nubank’s CX strategy made it one of the most loved digital banks
As we saw in parts 1 and 2 of this EC-1, by mid-2013, Nubank CEO David Velez had most of what he needed to get started. He’d brought on two co-founders, assembled ambitious engineering and operations teams, raised $2 million in seed funding from Sequoia and Kaszek, rented a tiny office in São Paulo, and was armed with a mission to deliver the kind of banking services that customers in a market as large and lucrative as Brazil’s should expect.
Despite being named Nubank, however, the startup couldn’t actually be a bank: Brazil’s laws made it illegal at the time for a foreigner-run company to operate a bank. That restriction required the team to develop an inventive product strategy to find a foothold in the market while they waited for a license directly from the country’s president.
Nubank was so adamant about differentiating itself from other banks that it chose Barney purple for its brand color and first credit card.
Nubank therefore pursued a credit card as its first offering, but it had to race against a clock counting quickly down to zero. At the time, Brazil didn’t have ownership restrictions on this product segment like it did with banking, but new rules were coming into force in just a few months in May 2014 that would block a company like Nubank from launching.
The company needed to execute rapidly over the next eight months if it wanted to be grandfathered into the existing regulations. The speed of operations was frantic to say the least, and the company would go on to work even faster, ultimately propelling itself into the stratosphere of fintech startups.
Full faith in credit
It’s easy to assume that the name Nubank refers to “new bank,” but that’s not really what the founders were going for. The word “nu” in Portuguese means “naked,” and Velez and his team wanted the name to reflect their vision: To build a 21st-Century bank without any of the shackles imposed by the traditional banks in Brazil.
The team wanted to offer services to as many people as possible, as there is a huge wealth gap in Brazil, where the minimum wage is around $200 a month.
Launching with just a credit card was both a strategic and practical business decision. Credit cards were widely used in the country, and everyone understood how they worked. Additionally, you could only use credit cards to shop online in Brazil, because debit cards weren’t accepted.
Powered by WPeMatico