When the application no longer has a moat, how should value be captured?

Original Title: Small Applications, Growing Protocols

Author: Packy McCormick, Not Boring

Compiled by: Sleepy, CultOut

I have been thinking that building an app is no longer a difficult task nowadays, and we are faced with these questions: "Where will value be captured?", "Should we build a moat?", "How to build a moat?", "How to deal with various competitions?"…

This article is my reflection on these questions.

Small Applications and Growing Protocols

Today, creating an interesting application is easier than ever. However, making these applications sustainable and turning them into lasting companies is harder than ever.

These two things are relative yet intertwined, like yin and yang.

Small applications represent a highly potential new model, but there is currently no effective business model. The potential value created by small applications exceeds the value they can capture, and combining small applications with protocols can fill this gap.

Creating is easy, maintaining is hard; this is not new. Since I wrote the article "Shopify and Those Easy Yet Difficult Things" in August 2020, I have been pondering this issue: the easy yet difficult things refer to if everyone can do something, then doing that thing has no benefits, yet you still have to do it just to keep up with the times.

That article was about e-commerce, but I noted that the same pattern is playing out across various verticals in different industries.

"It is happening in the self-media field, where Substack provides authors with a simple way to try to become the next Ben Thompson. It is happening in the gaming field, where Epic Games is developing tools and offering them for free to expand the overall potential market. It is happening in the AI field, where OpenAI allows everyone to use ChatGPT so that people can build on top of it."

In recent months, with the upgrade from GPT-3 to GPT-4, the last sentence of the previous paragraph has been further validated. Moreover, this is not just GPT marketing rhetoric; in fact, AI has indeed made it easier for anyone to build applications to meet an increasing number of niche demands.

I often focus on whether these products have a moat and whether they can stand the test of time. On these issues, we have received many completely contradictory viewpoints.

Developing what people need is a good idea. As long as you develop products that people love, you don't have to worry about growth or moat issues; whoever has more users will be more successful. OpenAI CEO Sam Altman recently expressed this viewpoint on Twitter:

But at the same time, because everything is evolving so quickly, users are like kids in a candy store, wanting to try everything, then paying for the sweetest thing, and then moving on to the next. Take Lensa, the first app in this generation of AI applications to create a storm on the App Store:

From a peak of over $2.5 million in daily net revenue in December to Lensa dropping to $206,000 per day in early January. This data is from a few months ago, but I feel that the situation may not have improved in the past few months. Regardless, this is an incredible achievement. The app's founders created something that people loved and made a lot of money from it, only to gradually fade away as the hype around AI avatars cooled and competitors flooded in.

It's not just Lensa. How many of these applications do you expect to have monthly revenues exceeding $200,000 a year from now? How many will grow into large companies?

I suspect that in the coming months and years, we will see this scenario play out again and again. Building applications will only become easier, and their functionalities will only become more astonishing. People will continue to try the latest products, pay for them, and then move on to the next.

So, if you are building a small application, what should you do?

One way to handle this situation is to try to find a moat. Perhaps you add social features to create network effects. Maybe you capture valuable proprietary data to personalize and improve your product, making people reluctant to leave. Undoubtedly, some will be able to build a moat, and we may see some billion-dollar companies created by one person or a small group of people.

However, for most, this will be a losing battle.

The second way to handle this situation is to minimize costs as much as possible and try to generate as much revenue as possible when profitable. We have seen, and will continue to see, a small application generating hundreds of thousands of registrations and millions of dollars in revenue within weeks. Similarly, building something that people are willing to pay for, even if it is just impulse spending, is great. Go earn your millions and then continue developing new small applications or enjoy some time at the beach.

But I think there might be a third way. Short-lived small applications can collaborate with enduring protocols to build something larger and more lasting.

Today, we will explore this third way.

Small Applications and Social Applications

Last week, Sam Lessin from Slow Ventures wrote a compelling article introducing social applications as fashion consumer goods rather than lasting networks.

The same thing happens over and over again—Yo, Yik Yak, Vine, Poparazzi, BeReal, Clubhouse, and so on, the examples are countless. Social applications reach new heights by leveraging new mechanisms to attract users and investors, only to disappear when the next new thing emerges. Facebook, Instagram, Twitter, and Snap still dominate and seem unaffected. If any challenger's mechanism is good enough, they can simply copy it.

Occasionally, a new giant emerges, the most recent example being TikTok. But usually, they also exhaust their last energy and gradually fade away. Nikita Bier is the only smart one here; he successfully escaped the peak.

Sam compares social applications to fashion consumer goods, which is a great metaphor. Try it on, show it off, then throw it away. Like Shein, it all seems wasteful. All the time, money, and energy are spent on acquiring and retaining users, yet users quickly shift their allegiance to new applications.

Reading Sam's article reignited my thoughts on small applications and added a new dimension to my thinking: time.

This is not to say that small applications cannot grow; they can. The problem is that the vast majority of small applications cannot maintain scale over the long term. What if they accept this and view it as their advantage?

Small Applications Supernova and Protocol Dyson Sphere

As Replit, AI, APIs, Urbit, and Web3 protocols make building applications easier, we have seen an explosive growth of small applications built for more specific use cases and user types.

Some small applications will be so small that they are built by one person for one person, while others will ride the wave of the times to reach millions of users but will quickly disappear. These are all temporary, even if these "small" applications become "big" for a period.

This is the kind of small application I am talking about here. They are like supernovae, burning brightly, exploding, and then vanishing.

Competition (including direct competition and more general attention competition) and the "kids in a candy store" phenomenon will make the transition from small applications to large application companies very difficult, just like in the case of social applications.

But some of these small applications will succeed for a time. What if we could build a Dyson sphere around the supernovae of these small applications, capturing and utilizing their energy?

In a 1960 paper titled "Searching for Artificial Stellar Sources of Infrared Radiation," physicist Freeman Dyson proposed a system to capture all the energy emitted by stars, providing nearly limitless power for human civilization. This idea, named the "Dyson Sphere" after its creator, has been popular for the past 63 years, appearing in countless works of science fiction, although its current feasibility is limited because the energy required to construct it exceeds that of our entire ecosystem.

We are looking for something similar in the digital realm: a way to harness the energy that successful small applications emit during their popularity and quickly accumulate valuable data before they fade away.

Protocols that allow users to carry their identity, data, and relationships within small applications are strong candidates. Of course, this is also part of the premise behind decentralized social protocols like Farcaster and Lens, as well as data protocols like Ceramic Network. Ceramic (a company invested in by Not Boring Capital) described this opportunity in their article "Into the Dataverse" last year:

"In our vision, the Metaverse should run on the Dataverse: a composable, network-scaled data ecosystem owned by everyone rather than by any one person. Developers will build interchangeable interfaces and online experiences that interact directly with the Dataverse and its composable data. In the Metaverse, the Dataverse can be said to play the most important role: a shared, high-performance, always-available graph of all the data that all applications create and use."

But I believe that small applications and protocols can focus more on their respective roles in the context of time. Small applications will burn brightly and explode, while smart protocols will go to great lengths to ensure they are capturing energy in the process, akin to an upgraded version of "Fat Protocols, Thin Applications," with an added dimension of time.

Fat Protocols, Thin Applications

There is a popular framework created by Joel Monegro at Union Square Ventures known as "Fat Protocols, Thin Applications."

In 2016, before these ideas became obvious, Monegro wrote the first part: Fat Protocols.

The general idea is that on the web, protocols like TCP/IP, HTML, and SMTP create a lot of value, but most of that value is captured by applications like Facebook and Google. However, on the blockchain, the value capture equation may be flipped: protocols can both create and capture most of the value driven by applications built on top of them.

"Two things will lead to this happening with most blockchain-based protocols," he wrote, "the first is a shared data layer, and the second is the introduction of cryptocurrencies with speculative value as an access barrier."

In a follow-up in 2020, starting from his own fund Placeholder, Monegro wrote the second part: Thin Applications.

In it, he emphasized the pros and cons of building applications on top of crypto protocols. In summary, he believed that while "crypto service architecture is great for startups because they can build quickly and cheaply with high capital efficiency," "many seem unclear about how they create long-term business value and defensibility when everything is open."

This setup is good for users, addressing many of our grievances about the web. But it raises new questions about the defensibility of the application layer. How do you create long-term business value and defensibility when everything is open and competitors can easily substitute for each other?

If you substitute Web3 protocols for AI APIs, then the debate around long-term business value and defensibility in the face of fierce competition is also what people are debating today.

At the end of the article, Monegro proposed three ways applications might create long-term value and defensibility:

• Build cost moats: concentrate costs and externalities not accounted for by the protocol.

• Vertical integration: successful applications may accumulate enough users to "become their own suppliers."

• User staking: use tokens to allocate value and user benefits.

Three years later, some applications have employed these three strategies with varying degrees of success, and most of the value has been captured by the protocols. You need to scroll down to the 20th position on the CoinMarketCap list of top tokens by market cap to find an application token—Bitfinex's UNUS SED LEO Token, and it is the 22nd position before you find an application you have heard of: Uniswap. Even Uniswap's UNI Token is tied to the protocol rather than the Uniswap application, but it is the closest one in the top 30.

It seems the debate has largely concluded: value returns to the protocol. Fat Protocols, Thin Applications.

What if protocols and applications are not trying to combat gravity by creating defensibility and long-term business value, but are intentionally designed around the idea that "small applications cannot expect to create defensibility and long-term business value"? What if they go with the flow?

Small Applications, Growing Protocols

If you assume that small applications are supernovae that may burn brightly, explode, and then vanish, then you can design a system to capture the energy and mass they emit for production. Fortunately, this is much easier than building a real Dyson sphere.

Earlier, we talked about a few approaches that small applications can take:

• Just do it. Raise venture capital, hire a team, continuously add features, try to find ways to retain customers long-term, and attempt to build a sustainable independent business that could be worth billions.

• Lifestyle businesses. Don’t raise venture capital, keep the team very lean, and try to capture as many users and as much cash as possible until you are acquired or gradually fade away.

Of course, you can also raise a little venture capital at a very low valuation, so even a small acquisition makes sense.

But earlier, I mentioned another, third way, and here it is: small applications, growing protocols.

As we explore this idea, this diagram may be helpful:

Small applications come and go, burning brightly, gradually fading away, contributing new users, data, and relationships to the protocols in the process. Small applications essentially become a channel for customer acquisition for the protocols.

The protocol continues to exist, and small application developers share in the rising rewards as the protocol grows. Each group plays a role, and everyone is rewarded in proportion to their contributions.

Small Applications

If you believe that "small" applications can become very "big"—gaining millions of users and generating millions of dollars in revenue—but usually cannot build a defensible business, then you can design your business in a way that looks very much like the lifestyle businesses mentioned above. Don’t raise venture capital, keep the team very lean, and try to capture as many users and as much cash as possible. These users, along with their data and relationships, are the treasure here.

You can keep the cash you pull in; the protocol doesn’t care about that. It just wants those users and their data and (or) relationships. Facebook built a $600 billion business with the support of its 3 billion users, whose social relationships with each other are virtually endless, and Facebook knows them inside out. Companies like Reddit and StackOverflow have started charging OpenAI for access to conversations on their platforms. Users, relationships, and data, long considered the lifeblood of the internet, are now more valuable than ever.

Small applications can effectively acquire these things through their novelty, topicality, and uniqueness, but no single application can come close to 3 billion users.

Free from the concerns of long-termism, your job is to create compelling new mechanisms and exciting products to capture as many users as possible as quickly as possible. Build products that niche communities love, do it better than others, differentiate as much as possible to stand out, and acquire users.

Growing Protocols

Unlike lifestyle businesses, in this case, small applications are built on protocols that can be defensible over the long term. These protocols do not need to propose shiny new mechanisms or features; they need to make it easy to build on top of them and accumulate as many users and as much data as possible over time.

Growing protocols assume that users will not stick around on any one product for too long, but if they can acquire enough users through a portfolio of small applications built on these products, they can have an ecosystem that, from the user's perspective, looks like an ever-evolving super app. One username, all data, all social relationships, many applications.

No single application can challenge Facebook's 3 billion users, but perhaps a series of applications can. Over time, as more users live on the protocol, any new small application will find it easier to leverage these users to overcome the cold start problem and potentially achieve sustainability.

You might ask: how can founders be willing to give up control over users and their data to increase the protocol's revenue?

My answer is: Tokens.

Incentivizing Small Application Developers

I assure you, I did not initially intend to write this piece as a crypto industry article, and it really isn’t. I am coming at it from the opposite direction:

• Small applications can expand rapidly but can also fade quickly.

• This can be seen as wasteful and unlikely to challenge existing giants.

• We should harness the energy created by small applications during their brief lives.

• Open protocols might be a good way to capture these users and their data.

• But how do you convince developers to give up control over their data?

• If used correctly, tokens can actually be very useful for aligning incentives.

I even tried to think of ways to do this without cryptocurrency—mergers and acquisitions, good old-fashioned open protocols, revenue sharing, equity swaps—but none were practical, and to my knowledge, there is no other way to solve this problem.

Thus, we are left with Web3 protocols and tokens, with some upgrades.

So far, one problem with the way application tokens are typically used is that developers often use tokens to attract users to products that are not particularly compelling. Many Web3 products I like have never issued tokens, and some even say they never will.

For some, tokens are like band-aids, attracting users looking to make quick money, hoping they will stick around until the product becomes good enough to attract more people. Essentially, the question has always been: how much do we need to pay people to use this application and stick with it?

But what if you think about it the other way around?

Instead of directly giving users tokens to incentivize them to use subpar products, protocols could allocate a large number of tokens to developers, allowing them to build great products on their protocols and share in the profits once the protocol succeeds.

These application developers could keep these tokens for themselves or use them to attract new users, hoping to grow and earn more tokens. The specific token allocation mechanism needs to be addressed on a case-by-case basis, and delving into this issue is beyond the scope of this article, but I think it should look something like this:

• Provide small upfront payments for each application.

• Token incentives based on the number of new users, as well as ongoing data and engagement incentives.

• Incentives through application staking.

• If new users turn out to be bots just to farm tokens without long-term engagement, cut token incentives.

There may also be exceptions. An ambitious protocol might give Nikita Bier an oversized grant in exchange for him building his next or next few applications on the protocol, just like Netflix paid Adam Sandler $250 million to make four more Netflix movies.

As more small applications are built on the protocol, more users create usernames on the protocol, and more data and value are exchanged on the protocol, the protocol itself becomes more valuable, and all developers who contribute to its success can share in the rising rewards.

The idea of protocols providing tokens to applications built on them is not new. This happens frequently in the crypto space, with many protocols even having venture funds to support projects planning to build within their ecosystems. Chris Dixon wrote about some of these ideas as early as 2017 in "Crypto Tokens."

What’s different here is that applications themselves should not issue their own tokens. Small applications should use the protocol's tokens and push more value toward the protocol, as most of the value will accumulate there anyway. They need to recognize their transience and be incentivized to make the protocol itself successful.

They should do everything they normally would to build the most compelling applications; they are essentially just swapping their databases for the protocol's.

This is a significant demand on the surface. Having users and data is precisely why Facebook has grown so large. Similarly, this won’t suit everyone. Optimistic idealists should remain optimistic and idealistic, but for most small applications, if you can acknowledge that you won’t become Facebook, I think this will create a very positive expected value. You can generate revenue in the short term and share in the upside of the protocol in the long term.

Importantly, small applications that collaborate with growing protocols and build on them do not need to be "crypto" applications. In other words, protocols do not need to be a defining feature, just as HTTP is not a defining feature of most websites. They can build whatever products they want—social applications, AI chat applications, and so on.

The next BeReal, Poparazzi, and Clubhouse should be built on open protocols, and perhaps the next Lensa should be as well, so that the user base and data they build do not inevitably fade away and go to waste when the next hot application emerges.

In many cases, these applications should use as little cryptocurrency as possible. Accept credit card payments, while allowing users to retain their usernames, and minimize the complexity of wallets as much as possible. Help users pay gas fees, don’t issue tokens, don’t decentralize governance, and don’t make grand roadmap commitments.

As long as users use the product for what it does best, there is an added benefit: they can get up and leave for the next product on the protocol, taking their relationships and data with them.

Over time, small application developers can leverage the inherent composability of web3 to build collaboratively integrated products. Other developers can create super applications composed of many of the best small applications on the protocol. They may incorporate cryptocurrency payments or other native features. But that is not the focus of this article; it will be up to developers to gradually figure out the other technical and economic implementation details.

For this article, the focus is simply to identify the trend of small applications, the challenges and opportunities it represents, and a potential solution.

Building a Lasting Ecosystem of Small Applications

Acknowledging the reality opens up the exploration of new models and business models, which emerge when not every company must do the same thing.

Whether developers intend to make them small or not, small applications are inevitable.

As building great products becomes easier and easier—today, a random new software product I came across on Twitter is 100 times better than the best software products from ten years ago—any single product's core becomes increasingly difficult to break through, maintain, and form a lasting business.

The difficulty does not mean it is impossible. In the coming years, there will be large-scale, lasting software companies born. What are the defining characteristics of these companies? That is the subject of ongoing debate.

But most applications will be small applications, even if they become "big" for a time. They will differentiate themselves, do one thing very, very well, attract hundreds of thousands or millions of users, generate significant cash flow, and then make way for the next exciting application.

In the process, they will waste valuable time and resources replicating components they could simply take off the shelf, including user charts, and when they get stuck, they will waste precious time and resources trying to figure out how to build defensively and long-term businesses.

I believe there is a third way.

Small application developers can capture all the advantages of lifestyle businesses, plus a bit of upside potential and immortality.

Users can build networks of relationships and databases across applications, becoming increasingly useful over time, rather than jumping from one application to another, starting anew each time.

And protocols have the opportunity to gain more users, data, and activity to challenge many seemingly indestructible incumbents over time.

In the process, we may lay the groundwork for a new way to build large, lasting super applications composed of supernova applications built on growing, enduring protocols.