At DoorDash, we’re building more than just an app. We’re building a system of products to enable on-demand delivery for local cities.
People don’t use DoorDash because we have a pretty, easy-to-use app that allows you to order food. People use DoorDash because we provide the fastest and most reliable delivery service. At the end of the day, people aren’t purchasing pretty pixels but an amazing delivery experience: does food show up fast and on-time, consistently? As a result, for the past year, most of our resources has actually been focused on developing the underlying logistics technology that fulfills deliveries in real-time.
Building such a system can get pretty complicated, especially at scale. There are many sides involved in this delivery ecosystem: consumers, drivers and merchants. Traditionally, most delivery companies only focused on one of the three sides. For example, we have lead-generation companies, like Grubhub and Seamless, that merely pass delivery orders onto restaurants. On the other hand, we see many local courier services that only focus on providing drivers.
But we took a different approach. We started DoorDash because we wanted to build the best local delivery service. From first principles, the only thing that made sense was to build a full stack delivery service. By partnering with merchants, contracting our own fleet of drivers, and building our own logistics software, we were able to control the entire delivery experience to make it more efficient for everyone.
Taking such a “full stack” approach offers us several benefits:
- Superior experience. Instead of being at the mercy of individual merchants, we can design the delivery experience the way we want it to be
- Better pricing. Instead of putting the full burden on one side, we share the delivery cost: we can charge lower delivery fees for consumers and take lower commissions from the merchants
- Increased efficiency. Since we have deep integration within merchants and drivers, we can fulfill the same number of deliveries with less time and far fewer drivers, by eliminating inefficient transactions and driver downtime
System of Products
The challenge with a full stack approach is that we have to build for many audiences: a system of products that involves all sides to work together. At DoorDash, there are four sets of products:
This is the side that most of you are familiar with — the web and mobile interfaces that allows consumers to place orders. This is the simplest product to build and relatively straight forward: press a button and food shows up.
Once an order gets placed, we have to send that to the merchant. This requires us to build products around merchant integration: what is the fastest and cheapest way to send orders to restaurants (without a human manually calling in orders)? The challenge here is designing for a wide range of merchants: everything from a mom-and-pop shop up to national chains. There is no one solution that fits all.
Next, the order needs to be assigned to a driver. The main problem we have to solve here is thinking about using mobile to coordinate an on-demand workforce. We’ve built software that drivers can install onto their phones that allows them to accept orders whenever they have downtime. There are many interesting challenges around fleet coordination and supply matching.
This is the central brain that monitors and controls everything that goes on in our system, making decisions on when to send orders to merchants, which drivers to assign orders to and alerting operations when things go wrong. Dispatch is by far our most complicated piece of technology we’ve built and forms the lifeblood of DoorDash.
Areas to Design For
Having spent the last year building out our system, there are several areas we’ve learned to design around:
All three of our products are mobile. Even two years ago, something like DoorDash wouldn’t have been possible, because smartphone adoption wasn’t pervasive. Now, everybody has a supercomputer in their pockets and we can tap into that potential.
Mobile has enabled us to design an efficient delivery network that eliminates the need for heavy infrastructure and fixed costs. Everything becomes on-demand.
The complexity in our system arises because there are so many moving pieces involved in a delivery. It is just as important to think through the interactions and protocols between products, in addition to the individual products themselves.
For example, if a consumer changes the order, we need to alert the restaurant. If the restaurant experiences kitchen holdup, we need to reassign the driver (as opposed to wasting time sitting at the restaurant) and the consumer needs to be notified. If a delivery messes up, dispatch needs to figure out in real-time what went wrong (driver spilled food or kitchen missed item?) and take the appropriate actions.
The key is that all the products are constantly talking to each other and working together to make a delivery happen. Now, multiply that by 100,000 deliveries at the same time, and you’ve got yourself an interesting operations problem with scale, automation and efficiency.
By taking a system approach to designing DoorDash, it lends itself very well to modularity. This is an integrated system, yet consists of independent products. If we wanted to deliver flowers tomorrow, we can simply swap out the consumer piece, but still utilize the same dispatch and driver technologies.
DoorDash was never a food company — and it certainly won’t be moving forward. We’ve always designed it to be a generalizable delivery network from day one. We’re only scratching the surface on the potential this system can offer. As we continue with our phenomenal growth, we’ll have to continuously evolve our system of products to keep up with scale. And hopefully, if we do our jobs right, this will become a system that will one day power urban logistics in cities all over the world.