A common narrative in the Web 3.0 community is that we are in an infrastructure phase and the right thing to be working on right now is building out that infrastructure: better base chains, better interchain interoperability, better clients, wallets and browsers. The rationale is: first we need tools that make it easy to build and use apps that run on blockchains, and once we have those tools, then we can get started building those apps.
But when we talk to founders who are building infrastructure, we keep hearing that the biggest challenge for them is to get developers to build apps on top. Now if we are really in an infrastructure phase, why would that be?
Our hypothesis is that this is not actually how things play out. We are not in an infrastructure phase, but rather in another turn of the apps-infrastructure cycle. And in fact, the history of new technologies shows that apps beget infrastructure, not the other way around. It’s not that first we build all the infrastructure, and once we have the infrastructure we need, we begin to build apps. It’s exactly the opposite.
A big part of why this is even a topic of conversation is that everyone now knows that “platforms” are often the largest value opportunities (true for Facebook, Amazon/AWS, Twilio, etc.) — so there is naturally a rush to build a major platform that captures value. This may be even more true in the distributed web where value often — but not always — accrues in the protocol layer rather than the applications that sit on top.
But, as we will see: platforms evolve from an iterative cycle of apps=>infrastructure=>apps=>infrastructure and are rarely built in an outside vacuum.
First, apps inspire infrastructure. Then that infrastructure enables new apps.
What we see in the sequence of events of major platform shifts is that first there is a breakout app, and then that breakout app inspires a phase where we build infrastructure that makes it easier to build similar apps, and infrastructure that allows the broad consumer adoption of those apps. Kind of like this:
For example, light bulbs (the app) were invented before there was an electric grid (the infrastructure). You don’t need the electric grid to have light bulbs. But to have the broad consumer adoption of light bulbs, you do need the electric grid, so the breakout app that is the light bulb came first in 1879, and then was followed by the electric grid starting 1882. (The USV team book club is now reading The Last Days Of Night about the invention of the light bulb).
Another example: Planes (the app) were invented before there were airports (the infrastructure). You don’t need airports to have planes. But to have the broad consumer adoption of planes, you do need airports, so the breakout app that is an airplane came first in 1903, and inspired a phase where people built airlines in 1919, airports in 1928 and air traffic control in 1930 only after there were planes.
The same pattern follows with the internet. We start with the first apps: messaging (1970) and email (1972), which then inspire infrastructure that makes it easier to have broad consumer adoption of messaging and email: Ethernet (1973), TCP/IP (1973), and Internet Service Providers (1974). Then there is the next wave of apps, which are web portals (Prodigy in 1990, AOL in 1991), and web portals inspire us to build infrastructure (search engines and web browsers in the early 1990’s). Then there is the next wave of apps, which are early sites like Amazon.com in 1994, which leads to a phase where we build infrastructure like programming languages (PHP in 1994, Javascript and Java in 1995) that make it easier to build websites. Then there is the next wave of more complicated apps like Napster (1999), Pandora (2000), Gmail (2004) and Facebook (2004) which leads to infrastructure that makes it easier to build more complex apps (NGINX and Ruby on Rails in 2004, AWS in 2006). And the cycle continues.
We also see this pattern with our most recent iteration of mobile apps: first we had a suite of popular mobile apps that relied heavily on streaming video: Snapchat (2011), Periscope (2014), Meerkat (2015), and Instagram Stories (2016). And now, we are seeing companies building infrastructure that makes it easy for mobile apps to add video: Ziggeo (2014), Agora.io (2014), Mux (2017), Twilio Video API (2017), Cloudflare Stream (2018).
This cycle also correctly explains the sequence of events in Web 3.0. We start with the first breakout app: BTC (2008), on top of the Bitcoin network (as the first infrastructure), followed closely by Silk Road (2011) as the most infamous early crypto app. This inspires new infrastructure like Sidechains and Drivechain (2015), Ethereum Smart Contracts and ERC20 (2015), Lightning (2015) that make it easy to build new apps, and infrastructure like Coinbase (2012) and Metamask (2016) that enable consumer adoption of these new apps. This new infrastructure then enables the next wave of apps: tokens/ICOs (2017) and early dapps (Rouleth and vDice in 2016, CryptoKitties in 2017), which inspire new infrastructure: Infura (2016) and Web3js and Zeppelin (2017). We’re now waiting for the next big apps that will help guide the next wave of infrastructure.
The Adjacent Possible
The common theme in the development of each major platform (electricity, cars, planes, the web, mobile, etc.) is that we build what we can given the tools available to us at the moment. In Where Do Good Ideas Come From, Steven Johnson refers to this as The Adjacent Possible. In other words, you can open the door to the next room, but you can’t really skip steps and open the back door from the front porch. It is hard to successfully build infrastructure that is too far ahead of the apps market.
Each time the apps => infrastructure cycle repeats, new apps are made possible because of the infrastructure that was built in the cycles before. For example, YouTube could be built in 2005 but not in 1995 because YouTube only makes sense after the deployment of infrastructure like broadband in the early 2000’s, which happened in the infrastructure phase following the first hit dot com sites like eBay, Amazon, AskJeeves and my favorite, Neopets.
Chris Dixon and Fred Wilson talk about this concept in a recent episode of the a16z podcast. Chris has a board game from the dot com era called Dot Bomb that makes fun of the silly dot coms of the late 1990’s. And what he points out is that all the ‘silly’ ideas of the dot com era are now the billion dollar unicorns. What is now possible several app => infrastructure cycles into the internet made no sense just one or two apps => infrastructure cycles in.
That is the crux of what we mean by the myth of the infrastructure phase — if we think about an “infrastructure phase” divorced from the apps that will use it, we run the risk of building too far ahead, in a speculative vacuum. We need the cycle of apps=>infrastructure=>apps=>infrastructure to keep us honest.
As there are more and more cycles in each new platform it gets cheaper to build and use those apps. Building usv.com in 1995 would have cost us many orders of magnitude more than it would cost to build today, and creating Web 3.0 apps costs more in cash, effort and time today than it will 15 years from now.
Development Frameworks Versus Investing Frameworks
Putting our investor hats on for a second, it’s important to distinguish between technological frameworks that explain when something can be built, and investment frameworks that explain when something can be a good investment.
The apps=>infrastructure=>apps=>infrastructure cycle explains when apps or infrastructure can be built, but doesn’t necessarily explain when to invest in apps versus when when to invest in infrastructure.
Take light bulbs for example. Yes, they were invented before the grid, but looking at it from an investor perspective, no one sold a lot of lightbulbs until the grid was in place.
Wrapping Up
One question we had is: why is it that apps come first in the cycle, and not infrastructure first? One reason is that it doesn’t make sense to create infrastructure until there are apps asking you to solve their infrastructure problems. How do you know that the infrastructure you are building solves a real problem until you have app teams that you are solving for? It will be a challenge to build crypto infrastructure now until there is a breakout crypto app that other developers want to emulate and need better dev tools and infrastructure to do so.
There is a narrative in the crypto space that first we need to build great tools, and once we have the tools, then we can build apps. But what we hope to have shown is that in other platform shifts, we are able to build the first few apps before there are great tools (though it is more cash and time intensive), and then those early apps inspire us to build tools. And the cycle repeats.
Happy building.
Update (10/5/18): This post has gotten a lot of attention, has generated some great discussion, and has produced some useful feedback.
First: duly noted that we spent most of our time here looking backwards at historical precedent, and thus that our diagram on the decentralized web / web3 / crypto was a) admittedly thin, and b) really just focused on the ETH ecosystem. We have updated that diagram to be a little more clear, and to include important concepts from the BTC ecosystem. Thanks to Dennis Porteaux for the excellent analysis on this.
Second: our favorite piece of feedback is that crytpo networks, in fact, really blur the line between apps an infrastructure, due their open and interopable nature. That is one of our favorite aspects of them. So, for instance, an “app” (like CryptoKitties, or any smart contract, or Bitcoin itself) can be infrastructure if someone builds on it. Of course, there are components of these networks that are **only** infrastructure (Lightning, Zeppelin, etc), but the line is blurred. Whereas in the past a platform (like Amazon or Facebook) had to make a conscious decision to open up APIs and become a platform, crypto apps are generally open and interoperable from day 1. This only makes the apps=>infrastructure=>apps=>infrastructure cycle tighter. Thanks to Denis Nazarov and Jutta Steiner for really articulating this.