At a high level, my preferred process for developing software products goes like this:

1. Identify a need
2. Design a product that satisfies it
3. Engineer a minimum viable implementation
4. Validate, iterate, and scale

I primarily think of crypto as one of many tools in a developer’s toolkit that can be leveraged situationally in #3. Evaluating whether to build (parts of) a product on a blockchain should be pragmatic and similar to evaluating the usage of, say, an in-memory database or a recommendation model. All are technologies, and technologies should be employed to the extent they increase value or reduce cost relative to alternatives.

So…when is it advantageous to build on-chain? Here’s my enumeration of currently-good applications, as well as of drawbacks developers face. I hope that this will lead to more useful products and be productively moderating to both the “crypto is useless” and “crypto is a panacea” crowds 🙂.

————————————————–

Building on-chain can be the best way to…

…facilitate straightforward accounts, payments, and ownership.

A funded wallet is like Facebook Login, Shop Pay, and a bank vault at the same time. A user can authenticate, transfer value to or from people or applications, and be recorded as something’s unambiguous owner with a one-click digital signature. Borders don’t exist and settlements are instant as long as one stays within a blockchain’s ecosystem. What about high transaction fees? L2s have lowered costs by 1+ orders of magnitude and will continue getting more efficient. Volatility? Just use stablecoins. I hope and expect to see more stablecoin-only products.

To get a better feel for this: buy an NFT on Opensea or some tokens on Uniswap.

…bootstrap growth incentives.

Sometimes transacting with a product makes a user the owner of something of arbitrary and questionable value — a pointer to a picture of a monkey, maybe. Sometimes, though, what’s transferred is much more strategic and fundamental: ownership of the product itself, or at least (thanks to the SEC) a utility/governance token whose value is closely correlated. Well-designed token incentives can induce supply and usage as well as advocacy and development, shifting the network scaling playbook from ~subsidize with venture capital to ~subsidize with invented capital (and risk from institutions to users/hodlers).

To get a better feel for this: explore how Helium rewards hotspots, Livepeer rewards transcoders, and Chainlink rewards oracle nodes.

…establish trust.

Blockchains extend open source to open state and execution[1]. By putting your product on-chain where its functionality can be inspected, you can guarantee to users and stakeholders that things work as advertised. Moreover, because contracts are immutable once deployed and transactions are irreversible, you can guarantee that they will always work this way.

To get a better feel for this: look at some verified contracts on etherscan.

…leverage interoperability/composability.

Open source, state, and execution make it easy for products to interact with one another. When you’re building your product, this is advantageous in that you can build it on top of preexisting others to avoid duplicating work. Once your product exists, this is advantageous in that others can build their products on top of yours and – if you structure things thoughtfully – return a cut of the value you enable.

To get a better feel for this: explore the examples listed in Composability is Innovation.

…ensure longevity.

Unless programmed to self-destruct, contracts run for as long as the blockchain on which they’re deployed. If you sufficiently decentralize both your product and your organization[2], someone who wants to halt your product’s usage either needs to halt its blockchain or, more realistically, make usage illegal. State actors totally can do both, but, at least in democratic-ish regimes, their costs rise with the usefulness of the blockchain generally and your product specifically.

Separately, through openness and community ownership, you can organize so that your product’s development continues after you’re gone and further that your product doesn’t become extractive once user growth saturates (both tending to maximize the long-term value of your work).

To get a better feel for this: read the history of bitcoin and Working in Public: The Making and Maintenance of Open Source Software.

On-chain products are currently limited by…

…a small user base and steep onramps.

Awareness and usage are growing fast, but the vast majority of people have never owned crypto. Even fewer have done anything interesting with it. For a user starting from scratch, getting to a funded wallet requires hurdling KYC, seed phrases, and multiple anxious transfers. If using your product requires a wallet, most people won’t right now.

As a workaround: architect your product so the on-chain parts are invisible or optional to users, as with Afriex and Magic.

…slow iteration cycles.

The double edge of contracts’ immutability sword is that it’s hard to modify them when you want to. To make a minor usability improvement or patch a critical bug or run an A/B test, you need to deploy a new contract and move usage over to it. This can be especially tricky when your open project has many cooks in the discord.

As a workaround: use proxy contracts.

…lots of pitfalls and few safety nets.

Immutable open projects throwing off open data and throwing around lots of value are ripe for exploitation, and irreversible transactions mean that exploits are irreversible too. Even though projects might get bailed out by the FBI or a hedge fund, they mostly won’t.

As a workaround: insurance products can help, though to insure against a risk you need to anticipate it first.

————————————————–

Those are the big ones for now! I’d love to hear from you on anything you think I’m missing, and I plan to revisit this periodically as the world evolves.

1: I swear I conceived this framing independently in the shower one day, but alas Balaji beat me to recording it by 3+ years.
2: Both are important: see polymarket.