Build vs buy for crypto projects
There’s a business concept called “build vs buy.” Given a business need, should the business buy a product or service from another company or build their own? For traditional businesses, the answer is almost always buy. But for crypto projects, the incentives flip, and it can make more sense to build.
Amazon Web Services (AWS) is a useful example of critical infrastructure almost every technology company buys. The Lyft S1 filing showed that the ride-sharing company committed to spending $80M per year for the next three years (Uber, Pinterest, Slack also use AWS). These are material costs, but the near universal usage of AWS acts as a sort of existence proof that the benefits of buying AWS outweigh the costs.
I think about the math like this. For buy and build, what are the:
Value created and captured
For buying AWS, you minimize the cost of building datacenters and standing up a cloud service, minimize the execution risk of building the service, and can focus on the parts of your business your customers care about (e.g. ridesharing experience).
For building your own data centers, you minimize the cost paid to Amazon, you minimize the risk that Amazon censors or copies your business, and you don’t create new value.
Most companies believe that the net benefits of buying outweigh the net benefits of building cloud services. (Dropbox is a notable exception).
Why is this different for crypto projects?
Relative to traditional businesses, crypto projects have (1) higher risks from buying, (2) lower risks from building, and (3) higher potential value captured from building.
Higher risks from buying
As Rocco explains in his post “On value capture at layer 3” that businesses building on top of crypto networks (both layer 1 and layer 2) face substantial risks:
it’s important for individuals with interests in these businesses to take note of the risks associated with building on the foundational layers of choice, and how the future of those protocols will impact the business. It’s also important to note that many of these services will become commoditized over time.
One governance decision with poor voter turnout can ruin a business. A compromised base chain can destroy everything above it. This space is still in its infancy and anything can happen in the next half hour.
A business like Veil (an app for prediction markets that’s built on Augur that’s built on Ethereum) faces direct risks from Augur and inherits the risks of Ethereum.
Lower risks from building
I’ve written previously that crypto projects enjoy fewer competitive moats than traditional businesses because of the relative ease of copying other peoples’ code. In that post, I focused on direct competitors (e.g. smart contract protocols competing with one another), but availability of code makes it easier to build vs buy infrastructure as well.
To continue with the Veil example, Veil could decide to build their own prediction market protocol (replacing Augur) and their own decentralized exchange protocol (replacing 0x). It would not be trivial, but the availability of code and years of learning in public make it easier.
Higher potential value captured from building
And on value capture, most projects are not yet designed to capture value. I like Kyle Samani’s recent framing as:
Layer 1 tokens exist for only one reason: to secure the chain against 51% attacks.
The only way a layer 2 protocol can capture value is if it stores some sort of external and valuable state.
A token is only worth something if it affords security or stores external and valuable state. This describes only a few crypto projects. The rest now realize that their token do neither of these things, and are taking steps to modify their projects so their token does capture value. These projects will want to own the piece of the infrastructure that satisfies one of these conditions.
In other words, today’s crypto projects have an incentive to build rather than buy the infrastructure that captures value for a token1. (An example to keep an eye on is layer 2 scaling. Many Ethereum based projects will roll their own e.g. Plasma rather than use a third party).
The implications are interesting here (e.g. horizontal expansion of layer 2 projects, vertical expansion from all layers, conflicts of interest) but out of scope for this post. Here, I want to make a simple point that we should expect more “build” decisions from crypto projects as applications attract more users and projects seek to capture value from those users.
Most likely, they will compete at Layer 2. Layer 1 has a lot in common with cloud infrastructure. Like proof of work mining, cloud infrastructure requires a ton of capital expenditures like physical buildings, GPUs, and custom hardware. The more someone invests in cloud infrastructure or proof of work security, the more expensive it is to create a competitor. So just as rolling your own cloud infrastructure is becoming harder to justify, rolling your own layer 1 is becoming harder to justify. Though one could argue that because of remaining uncertainty about the right trade-offs at layer 1, security (e.g. miners) could flock to a chain with a better design. ↩