When the application will no longer have a moat, how should the value be captured

作者：Packy McCormick，Not Boring

Compile: Sleepy, CultOut

I have been thinking that it is not difficult to build an App nowadays. At this time, we will face these questions: "Where will the value be captured?" "Should a moat be built?" compete"……

This article is my reflection on these questions.

Applets and growing protocols

Today, it's easier than ever to build a fun app. But keeping these apps running and turning them into enduring companies is harder than ever.

These two things are opposite and blend together, like Yin and Yang.


Small applications are a new model with great potential, but there is no effective business model yet. Applets create more potential value than they can capture, and the combination of applets and protocols can fill this gap.

It's not new to create something that's easy to sustain. I've been thinking about this question since I wrote "Shopify and the Easy Hard Things" back in August 2020: the easy hard thing is that if everyone could do something, then There's no benefit to doing it, but you have to do it anyway, just to keep up with the times.

That article was about e-commerce, but I wrote that the same pattern is playing out across industry verticals.

"It's happening in social media, where Substack provides an easy way for authors to try and make themselves the next Ben Thompson. It's happening in gaming, where Epic Games is developing tools and making them free to use to amplify the overall Potential market. It’s happening in artificial intelligence, and OpenAI is making ChatGPT available to everyone so that people can build on top of it.”

In recent months, with the upgrade of GPT-3 to GPT-4, the last sentence of the previous paragraph has been more strongly confirmed. And, it's not just GPT marketing talk, in fact, artificial intelligence does make it easier for anyone to build their own applications to meet more and more niche needs.

I often pay attention to whether these products have a moat and whether they can stand the test of time. We get a lot of completely contradictory views on these issues.


It's a good idea to develop something that people need. As long as you develop a product 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 tweeted this sentiment:


But at the same time, with everything moving so fast, users are like kids in a candy store, trying everything and paying for the sweetest thing before they go on to buy the next one. Take Lensa, the first of this generation of AI apps to take the App Store by storm:


From a peak of more than $2.5 million in daily net income in December, Lensa dropped to $206,000 a day in early January. This data is from a few months ago, but I think the situation may not pick up in these few months. Either way, it's an incredible achievement. The app's founders built something people loved, made a fortune doing it, and then slowly faded away as the hype of the AI avatar cooled and competitors flooded in.

Not just Lensa. How many of the following apps do you expect to generate more than $200,000 in monthly revenue a year from now? How many will grow into big companies? ,


I suspect that we will see this play out time and time again in the coming months and years. Building apps will only get easier, and their capabilities will only get more amazing. People will still try the newest products, pay for them, and keep trying newer ones.

So if you're building a small application, what do you do?

One way to deal with this situation is to try to find a moat. Maybe you added social features to create network effects. Maybe you capture valuable proprietary data to personalize and improve your product so people don't want to leave. No doubt some will be able to build moats and we may see some billion dollar companies created by one person or a small group of people.

For most, though, this will be a losing battle.

The second way to deal with this situation is to keep costs as low as possible and try to generate as much revenue as possible when it is profitable. We have seen, and will continue to see, a small app generate hundreds of thousands of signups and millions of dollars in revenue within a few weeks, similarly, building something that people are willing to pay for, even if it’s just an impulse purchase , that would be great too. Go make your millions and move on to building new little apps, or go to the beach and enjoy some time.

But I think there might be a third way. Smaller apps with shorter lifecycles can partner with longer-lived protocols to build something bigger and more enduring.

We're going to explore this third way today.

Small Apps and Social Apps

Last week, Sam Lessin of Slow Ventures wrote a compelling article about social apps as consumer fads rather than persistent networks.


The same thing happens again and again - Yo, Yik Yak, Vine, Poparazzi, BeReal, Clubhouse, the list goes on. Social apps use new mechanisms to reach greater heights, attract users and investors, and then disappear when the next new thing comes along. Facebook, Instagram, Twitter and Snap still dominate and appear to be immune to impact. If any challenger's mechanics are good enough, they can be directly cloned.

Occasionally, a new giant is born, the most recent example being TikTok. But more often than not, they also use up the last of their energy and fade away. Nikita Bill was the only smart guy here, and he managed to escape the top.

Sam compares social apps to consumer fashion, and it's a good analogy. Try it on, show it off, and ditch it. Like Shein, it all seems like a waste. All the time, money and energy is spent on new acquisitions and retention, but users are rapidly shifting their positions to new applications.

Reading Sam's article reinvigorated my thinking about applets and added a new dimension to my thinking: time.

That's not to say that small apps can't go big, they can. The problem is that the vast majority of small applications cannot scale for long. What would happen if they accepted this and used it to their advantage?

Small App Supernova and Protocol Dyson Sphere

As things like Replit, AI, APIs, Urbit, and the Web3 protocol make building apps easier, we're seeing an explosion of smaller apps 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, and some small applications will ride the wave of the times to reach millions of users, but will soon disappear. These are temporary, even if these "small" apps become "big" over a period of time.

That's the kind of applet I'm talking about here. They burn brightly, explode, and die like supernovas.


Competition (both direct and more generally for attention) and "kids in a candy store" will make the transition from small apps to big app companies very difficult, as is the case with social apps.

But some of these small apps will be successful for a while. What if we could build Dyson spheres around these supernovas of small apps, capturing and harnessing their energy?

In a 1960 paper, "The Search for Artificial Stellar Sources of Infrared Radiation," physicist Freeman Dyson proposed a system to capture all the energy emitted by stars to power human civilization almost infinitely. The idea, named the "Dyson sphere" after its creator, has gained popularity over the past 63 years, appearing in countless works of science fiction, although its current viability is limited because of the energy required to build it More than our entire ecosystem.

We're looking for something similar in the digital space: a way to harness the energy that those successful little apps spit out when they're popular, and quickly amass valuable data before they fade away.


Protocols that let users carry their identities, data, and relationships within applets are strong candidates. Of course, this is part of the premise behind decentralized social protocols like Farcaster and Lens, and data protocols like Ceramic Network. Ceramic (a Not Boring Capital portfolio company) described this opportunity in their article "Into the Dataverse" last year:

“In our vision, the Metaverse runs on the Dataverse: a composable, web-scale data ecosystem owned by everyone, not someone. Developers will build interchangeable interfaces and online experiences, with The Dataverse interacts directly with the composable data within it. The Dataverse plays arguably the most important role in the Metaverse: a shared, high-performance, always-available graph of all data created and used by all applications."

But I think applets and protocols could be more focused on their respective roles in the context of time. Applets will burn and explode brightly, and clever protocols will stop at nothing to ensure they are Dyson spheres capturing energy in the process. I think this is like an upgraded version of "Fat Protocol, Thin Application", with an additional time dimension.

Fat protocol, thin application

There is a popular framework, coined by Joel Monegro at Union Square Ventures, called "Fat Protocols, Thin Applications".

In 2016, before these things became obvious, Monegro wrote the first part: the fat protocol.

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


“With most blockchain-based protocols, two things will cause this to happen,” he wrote, “the first is a shared data layer, and the second is the introduction of cryptocurrencies, which have some speculative value, as a barrier to access. "

In a follow-up report in 2020, starting with his own fund Placeholder, Monegro wrote about another segment: thin apps.

In it, he highlights the benefits and drawbacks of building applications on top of cryptographic protocols. In conclusion, he argues that while "crypto-as-a-service architectures are great for startups" because they can be built quickly, cheaply, and with high capital efficiency, "what many people don't seem to understand is that when How exactly do they create long-term business value and defensibility when everything is open.”

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

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

At the end of the article, Monegro proposes three ways in which an application might create long-term value and defensibility:

• Building a cost moat: concentration costs and externalities not accounted for by the agreement.

-Vertical integration: Successful apps may accumulate enough users to "become their own supplier".

-User pledge: use Token to distribute value and user's interests.

Three years later, some applications have used all three strategies with varying degrees of success, and most of the value has been captured by the protocol. You need to scroll down to number 20 on CoinMarketCap's list of top tokens by market capitalization to find an application token - Bitfinex's UNUS SED LEOToken, and number 22 to find an application you've heard of: Uniswap. Even Uniswap’s UNIToken is pegged to the protocol, not the Uniswap application, but this is the closest one in the top 30.


It seems that the debate is mostly over: value comes back to protocols. Fat protocols, thin applications.

What if protocols and applications, instead of trying to defy gravity by creating defensibility and long-term business value, intentionally designed themselves around the idea that small applications cannot expect to create defensibility and long-term business value? What if they go with the flow?

Small app, growing protocol

If you assume that small applications are supernovae, that may burn violently, explode, and disappear, then you can design a system that captures the energy and mass they spit out and use it in production. Fortunately, this is much easier than building a real Dyson sphere.

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

• it's done. Raise venture capital, hire a bunch of people, keep adding features, try to keep customers long-term, and try to build a sustainable standalone business that could be worth billions of dollars.

-Lifestyle business. Don't raise venture capital, keep the team very lean, and try to grab as many users and as much cash as possible until you get acquired or fade away.

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

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

This diagram may help as we explore this idea:


Applets come and go, burn bright, and fade away, contributing new users, data, and relationships to the protocol in the process. The applet essentially becomes a bunch of customer acquisition channels for the protocol.

The protocol lives on, with applet developers sharing in the rising revenue as the protocol grows. Every group has a role to play, and everyone is rewarded commensurately with their contributions.

Small Apps

If you think that a "small" app can become very "big"—acquire millions of users, generate millions of dollars in revenue—but generally fail to build a defensible business, then you can start with an approach that looks a lot like Design your business the way above for a lifestyle business. Don't raise venture capital, keep the team very lean, and try to grab as many users and as much cash as possible. These users, and their data and relationships, are the treasure trove here.

You get to keep the cash you pull, the protocol doesn't care about that. It just wants those users and their data and/or relationships. Facebook has built a $600 billion business on the back of its 3 billion users, whose social connections with each other are nearly endless, and Facebook knows them all. Companies like Reddit and StackOverflow have begun charging OpenAI to access conversations on their platforms. Users, relationships, and data, long the lifeblood of the internet, are now more valuable than ever.

Small apps can effectively get these things by virtue of their novelty, topicality, and uniqueness, but each individual app is unlikely to approach 3 billion users.

Freed from long-term concerns, it's your job to create compelling new mechanics and exciting products that capture as many users as possible as quickly as possible. Build a product that is loved by a niche community, do it better than others, and differentiate as much as possible to stand out and acquire users.

Growing Protocols

Unlike the lifestyle business, in this case the applet is built on a protocol that can be defended in the long run. These protocols don't need to come up with 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 a period of time.

The ever-growing protocol assumes that users won't stick with any one product for long, but if they can get enough users through a portfolio of small apps built on top of those products, they can have an ecosystem that, from a user perspective, See, the ecosystem looks like a growing super app. One username, all data, all social connections, many apps.

No single app can challenge Facebook's more than 3 billion users, but perhaps a family of apps can. Over time, as more users live on the protocol, it will be easier for any new applet to leverage those users to overcome the cold start problem and potentially achieve sustainable growth.

You might ask: how could any founder be willing to give up control over users and their data to grow the protocol’s revenue?

My answer is: Token.

Incentivize small app developers

I promise, I didn't intend to write this manuscript as a crypto industry manuscript in the first place, and it really is not. I'm thinking from the opposite direction:

-Small apps can scale quickly and die quickly

• It's arguably wasteful and unlikely to challenge the incumbents

• We should harness the energy created by the applet in its brief life

• open protocols could be a good way to capture these users and their data

• but how do you convince developers to give up control of their data?

• Tokens are actually very useful for aligning incentives if used properly

I've even tried to think of ways to do it without cryptocurrencies - mergers and acquisitions, regular old-fashioned open agreements, revenue sharing, equity swaps - but none are practical, and as far as I know, there's no other way solve this problem.

So we're left with the Web3 protocol and tokens, with some upgrades.

One problem with most of the way app tokens have been used so far is that, typically, developers use tokens to attract users to products that aren't particularly compelling. Many of the Web3 products I like have never issued tokens, and some even say they will never issue tokens.

To some, tokens are like a Band-Aid, attracting users who want to make a quick buck in the hope that they can 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 app and stick with it?

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

Instead of directly giving users Tokens to motivate them to use unqualified products, the protocol can allocate a large number of Tokens to developers, allowing them to build excellent products on their own protocol and share the benefits after the agreement is successful.

These application developers can keep these tokens themselves, or use them to attract new users, hoping to grow bigger and earn more tokens. The specific Token allocation mechanism needs to be solved one by one, and it is beyond the scope of this article to delve into this issue, but I think it should be like this:

• Small upfront payment for each app

• Token incentives based on the number of new users, as well as continuous data and participation incentives

• Incentives for staking through the app

-If the new user proves to be a fake, just for the purpose of gaining cash but not long-term participation, the Token incentive will be cut

There may also be exceptions. An aggressive deal might give Nikita Beal an overfunding in exchange for him building his next app or next few apps on the deal, like Netflix paid Adam Sandler another $250M Get him to do 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 those who contribute to its success Developers can share the rising income.

The idea of protocols giving applications tokens to build upon is not new. This happens a lot in the crypto space, and many protocols even have venture funds to back projects that plan to build in their ecosystems. Chris Dixon wrote about some of these ideas back in 2017 in Crypto Tokens.

The difference here is that the application itself should not issue its own token. Applets should use the protocol's token and push more value into the protocol, where most of the value will accumulate anyway. They need to recognize their own ephemerality and be motivated to make the protocol itself successful.

They should be doing everything they would normally do to build the most compelling applications, they're basically just swapping their databases for protocol ones.

That's a big ask on the surface. Having users and data is exactly why Facebook has grown so much. Again, this isn't for everyone. Optimistic idealism should continue to be optimistic and idealistic, but for most small apps, if you can admit that you're not going to be Facebook, I think that creates a very positive expected value. You can generate revenue in the short term and share in the protocol’s upside in the long term.

Importantly, applets that work with and build on a growing protocol need not be "crypto" apps. In other words, the protocol doesn't need to be a defining characteristic any more than HTTP is not a defining characteristic of most websites. They can build whatever products they want to build — social apps, AI chat apps, whatever.

The next BeReal, Poparazzi, and Clubhouse should be built on open protocols, and maybe the next Lensa should too, so that the user base and data they build won't go to waste when the next hit app inevitably dies.

In many cases, these applications should use as little cryptocurrency as possible. Accepting credit card payments abstracts away as much wallet complexity as possible while letting users keep their usernames. Help users pay Gas fees, do not issue Tokens, do not decentralize management, and do not make grand roadmap promises.

Just letting users use the product for what that product does best has the added benefit of being able to get up and walk away and find the next product on the protocol, bringing their relationships and data with them.

Over time, applet developers can take advantage of the inherent composability of web3 to build products that work together. Other developers can build super apps, composed of many of the best small apps on the protocol. They may incorporate cryptocurrency payments or other native features. But that's not the focus of this article, it's up to the developer to figure it out in terms of other technical and economic implementation details.

For this article, the focus is simply on identifying trends in small applications, the challenges and opportunities this trend represents, and a potential solution.

Building a Persistent Applet Ecosystem

Acknowledging that reality opens up the search for new models and business models that emerge when not every company has to do the same thing.

Applets are inevitable, whether developers intend to make them smaller or not.

As it becomes easier to build great products—a mediocre new software product I randomly swipe on Twitter today is 100 times the quality of the best software product from ten years ago—it takes any single product to break through, sustain And forming the core of a lasting business is getting harder and harder.

Difficult doesn't mean impossible. In the next few years, there will be large-scale, durable software companies born. What are the defining characteristics of these companies is the subject of ongoing debate.

But most applications will be small applications, even if they become "big" over a period of time. They will differentiate, do one thing really, really well, attract hundreds of thousands or millions of users, generate a lot of cash flow, and then give way to the next exciting app.

In the process, they waste valuable time and resources duplicating artifacts that they can simply grab from the shelf, including user diagrams, and when they get stuck, they waste valuable time and resources trying to Trying to figure out how to build a defensive and long-term business.

I think there is a third way.

Small app developers can capture all the advantages of a lifestyle business, plus a little upside and the potential for immortality.

Users can build relationships and databases that span applications and become more and more useful over time, rather than jumping from one application to another, starting over each time.

And the protocol has the opportunity to gain more users, data, and activity in order to challenge many seemingly indestructible incumbents over time.

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