DoNotPay: The API for IRL
Plus! The Index; Twitter: Subscale; Chaos Engineering; Space Law; The Login Layer
|Byrne Hobart||Dec 16, 2020|| 5||2|
In this issue:
DoNotPay: The API for IRL
The Login Layer
DoNotPay: The API for IRL
Software tends to replace an existing product with a digital analogue—Outlook's calendar, email, and address book functionality would be recognizable to an office worker fifty years ago, even if the implementation was not, and the initial version of Facebook was a riff on the longstanding tradition of college face books. Some of them take something that works, and make it better: people watched TV before Netflix, but Netflix changed how they passively consume hours of video. And a handful of companies exist to wrap a functioning layer around dysfunctional. A while ago I described part of Stripe's function like this:
Some of the most valuable software companies in the world create value by making the Internet work the way a naive person would imagine it does if they’d heard about it but never used it. Simple tasks like looking up information, finding people and businesses, and making payments turn out to be nontrivial at scale, and making them trivial is immensely valuable.
DoNotPay is a company that leans in to this dynamic, by specifically focusing on broken bureaucratic processes, and making them app-accessible. I've mentioned the company a few times in past issues, when they raised money, launched new products, or hinted at future launches. But they're worth focusing on, because they represent both the promise of software to reverse the Great Stagnation and the long slog required to implement this vision. I caught up with DoNotPay's founder, Joshua Browder, to get more details.
DoNotPay starts with parking tickets: Browder started getting tickets when he started driving, and learned that there's a process to appeal them. He used FOIA requests to find out which approaches to contesting tickets were the most effective, and built a simple app to automate the process. Superficially, this is not a socially valuable proposition: parking is a scarce and valuable resource, and traffic rules are a way to ration it. But municipalities are not run by economists; they're run by people with budgets, and as it turns out, tickets, and court fines for not paying them, are a major revenue source for municipalities, and a regressive tax as well.
But an app that's just designed to appeal parking tickets doesn't have a large market. Most people don't get many of them, and don't get them all that often, so if DoNotPay sold its services on a one-off basis, it would constantly have to win new customers or win back old ones. Better to offer the product as a subscription instead, with enough features to keep customers using it.
Since the parking ticket days, DoNotPay has expanded into other products: breaking leases, cancelling subscriptions, refunding and changing plane tickets, getting a copyright, and submitting FOIA requests. (Like Amazon, they're slowly converting their costs into revenue lines—Browder describes the team as "people who are living the DoNotPay lifestyle, and looking for additional hacks, and if the company can productize the time its employees spend on that hobby, it will reduce the time-overhead it pays for.)
If DoNotPay's addressable market is the set of solvable small-time grifts and unnecessary inconveniences, it's a vast one. And it's not trivial to identify the next problem to fix. The way most ripoffs work is that they're minor enough to be almost unnoticeable, or intermittent enough to be hard to fix. DoNotPay has a few avenues other than the team's own inclinations: some of their products involve sharing data—users who submit FOIA requests can share the results with DoNotPay, which gives the company a look at which issues people care about. As it turns out, FOIA requests that don't come from journalists are often downstream of the kinds of problems DoNotPay lets users work around. And they get direct suggestions on their site, both from customers who understand the product and from people who stumble on the site due to its SEO, misread its branding ("The World's First Robot Lawyer"), and use the contact form to describe the lawsuit they'd like to file.
In some cases, the problems DoNotPay solves are due to monopolistic sloth. A good way to judge how competitive an industry is is to see whether their customer service number offers to call you back when an agent is available, or keeps you on hold indefinitely. Utilities and government agencies simply don't feel any pressure to improve the process; their customers have nowhere else to go. But others are trickier: some kinds of inefficiency are a jobs program and a form of mild protectionism. One of the functions of gatekeepers is to waste most people's time while giving express service to favored parties; DoNotPay gives everyone the same service. Another function of gatekeepers is to provide a job-like way to spend the workweek, for people who can’t perform work of actual value.
And that both raises and answers the long-term question about DoNotPay. If everyone's suboptimal interactions with slightly broken rules represents a business opportunity, the product can turn into a reverse-shakedown of slow-moving institutions. Instead of $50 parking tickets that sometimes compound into thousand-dollar fines for unpaid tickets and missed court appearances, we can end up in a world where free parking is even more underpriced because tickets don't matter. If DoNotPay makes it simple to cancel subscriptions, then subscription economics only work at a higher price point for the users who do choose to pay. If the generous bits of airlines' cancellation policies can be measured, modeled, and used at scale, those policies will go away (the airlines will lose some price discrimination power, but little brand value; they'll just live up to their low reputations for customer service).
That's another way of saying that DoNotPay helps users exploit arbitrage opportunities. Since those opportunities are available to individuals, and only expedited by the app, it's another case study in winner-take-some platforms. A few people have used the app to build side gigs, like auto-generating lawsuits against robocallers. But most of them are just using it to make small improvements, or smooth out small financial inconveniences. It's an arbitrage against flawed rules.
And while arbitrage is theoretically zero-sum, it does serve an important social purpose: it eliminates the opportunities for arbitrage. Ambitious people don't select into jobs processing paperwork for city governments, or running call centers for cable companies and gym chains. They do join startups. This makes some people uncomfortable, but when it turns into an arbitrage, it starts to solve itself: society's functional institutions are building a scalable, composable, and profitable layer of APIs around the broken ones.
 Like the lottery, they end up being a regressive tax because they disproportionately affect people who are bad at navigating the complexities of the modern world, and bad at simple expected-value calculations. The lottery, at least, is enjoyable to some participants, so any municipality that reduced traffic fines and replaced the fines with lotto revenue would offer a Pareto improvement.
Tech investors are well aware that the most profitable companies are the ones whose economics improve as they scale. This is usually described as some form of network effect, but there are sometimes multiple compounding scale effects at work. Google's dominant search index is getting some attention, and the economics there are fascinating.
To rank and display webpages, a search engine needs to have a bot parse the contents of every page. Site owners can choose to allow or reject bots, or to give some of them more generous permissions than others. From the site owner perspective, small search engines aren't worth the time—if they don't take up any bandwidth, they can be ignored, but if they do anything attention-grabbing, they'll probably get blocked. Meanwhile, Google has found that faster crawling leads to better results, especially for more specific long-tail queries. And since long-tail results are the way an excellent search engine differentiates itself from a merely good one, that's what they have to focus on. As a result, the total cost of crawling, both for search engines and the sites they crawl, rises with the number of search engines. A search engine that copied Google's algorithms and hardware, but not their distribution, would be imposing a pure cost on the sites it indexed, with no attendant benefit.
This leads to an economic setup that's wonderful for Google, and troubling for anyone worried about industry concentration: the better search gets, the more economic sense it makes for there to be just one big search engine.
The Times piece linked above cites research from a group called Knuckleheads' Club, and on their site they propose an interesting solution: a public cache of the web. It's not strictly necessary for this to be publicly-owned, though; the same benefits would accrue if it were run by a private company and offered open access to anyone. Ordering Google to spin off its crawling business and let Bing and DuckDuckGo buy access to the data on the same terms is not the sort of antitrust remedy that gets hearts racing, but it would peel one part of search with monopolistic economies of scale from the core business, which has a completely different set of the same.
The bear case on any software company with high dollar retention looks like this: in the short term, they grow revenue as their clients grow, and if their clients are generally growing fast, their natural growth rate is high, too; Twilio would be among the fastest-growing companies of its size even if it never landed another new customer, for example. The downside case is that eventually, customers replace an external product with one they've built themselves. The best customers churn. This risk has hit SaaS companies in the past (although the screenshot in that article shows Twilio dropping 28% to $24 a share; three and a half years later, they're at $345).
Twitter's recent decision to use AWS for some of its infrastructure shows that this concern is not dire, even at fairly large scale. Twitter doesn't specifically break out infrastructure costs, but they're the first item mentioned in the company's breakout of cost of revenue, a cost line totaling $1.14bn last year. If that's the scale at which it makes sense to switch to an external service provider, the build-vs-buy decision is probably driven more by internal factors like management's attention and the company's engineering culture, rather than some cutoff where the external service provider's royalty on growth is too expensive.
(Disclosure: Long AMZN.)
AWS now offers "Chaos Engineering," a way to systematically stress-test systems by simulating mistakes (unplugged server, deleted database, misconfiguration). The original concept seems to come from Netflix, and later turned into the title of a great memoir about working at Facebook. The trouble with disaster planning is that the big disasters are unplanned; in retrospect, they fit into the weaknesses in a disaster preparedness plan like a key fits a lock. So outsourcing this to a third party is not just a tradeoff of money compared to engineering time; it's a way to experience someone else's idea of a fault.
These insurance contracts will be a very interesting theoretical exercise, both for space companies and for the reinsurers who ultimately price them. The social cost of Kessler Syndrome is fairly low right now, but the cost according to SpaceX or Blue Origin, both of which want to make sure humanity is not confined to earth, could be in the trillions of dollars. This makes any behavior-altering insurance a steal from their perspective.
The Login Layer
Microsoft is launching a new password manager. There are pure-play password managers, like 1Password, but owning the login is also a useful way for a company to put its products in the center of the user experience. In Microsoft's case, this is also a way to take advantage of risk aversion: since passwords are inconvenient, a universal login saves time, but since they're such an important vector for hacks, it takes a lot of effort for a vendor to get trusted enough to offer them as a service. It's also a good way to collect data on which software is used by whom, although Microsoft will no doubt be careful about this.
(Disclosure: long DBX and MSFT.)