When there is no longer a moat around the application, how should value be captured?

23-05-12 13:42
Read this article in 39 Minutes
总结 AI summary
View the summary 收起

Original Title: "Small Applications, Growing Protocols"
Original Author: Packy McCormick, Not Boring
Translated by: Sleepy, BlockBeats


I have been thinking that building an App is no longer a difficult task nowadays. However, we will face these questions: "Where will the value be captured?", "Should we establish a moat?", "How to establish a moat?", "How to deal with various competitions?"...


This article is my reflection on these issues.


Small applications, growing protocols


Brief dancing, small application flashing, then disappearing, endless changes constantly expanding. - ChatGPT


Nowadays, it is easier than ever to build an interesting application. However, it is more difficult than ever to turn these applications into sustainable companies that can continue to operate over time.

These two things are relative and complementary, just like yin and yang.



小应用是一种极具潜力的新模式,但是目前还没有行之有效的商业模式。小应用所创造的潜在价值比他们能够捕获到的价值更多,而如果小应用和协议结合便能填补这一空白。

The mini-application is a highly potential new model, but there is currently no effective business model. The potential value created by mini-applications is greater than the value they can capture, and if mini-applications are combined with protocols, they can fill this gap.


Creating is easy, maintaining is difficult, and this is not a new concept. Since I wrote the article "Shopify and the Easy Difficulties" in August 2020, I have been thinking about this issue: easy difficulties refer to if everyone can do something, then there is no benefit in doing it, but you still have to do it just to keep up with the times.


That article is about e-commerce, but I wrote that the same pattern is playing out in the vertical fields of various industries.


"It's happening in the self-media field, where Substack provides authors with a simple way to try to become the next Ben Thompson. It's happening in the gaming industry, where Epic Games is developing tools and offering free use to expand the overall potential market. It's happening in the artificial intelligence field, where OpenAI is making ChatGPT available to everyone to build upon."


In recent months, with GPT-3 upgrading to GPT-4, the last sentence of the previous paragraph has been further confirmed. And this is not just GPT marketing rhetoric, in fact, artificial intelligence does make it easier for anyone to build their own applications to meet increasingly niche demands.


I often pay attention to whether these products have moats and whether they can withstand the test of time. On these issues, we have received many completely contradictory views.



Developing things that 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 view on Twitter:



However, at the same time, due to the rapid development of everything, users are like children in a candy store, wanting to try everything and then paying for the sweetest thing before moving on to the next. For example, Lensa, the first AI application to cause a storm on the App Store in this generation:



From the peak of earning over 2.5 million US dollars in net income every day in December, to the early January when Lensa dropped to a daily income of 206,000 US dollars. This data is from a few months ago, but I don't think the situation has improved much in the past few months. In any case, this is an incredible achievement. The founder of the application created something that people love and made a lot of money from it, and then slowly faded away as the hype of AI avatars cooled down and competitors emerged.


Not just Lensa. How many of these applications do you expect to have monthly revenue exceeding $200,000 in a year? How many will grow into big companies?



I speculate that in the coming months and years, we will see this situation play out time and time again. Building applications will only become easier, and their capabilities will only become more amazing. People will still try the latest products, pay for them, and then continue to try newer ones.


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


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

However, for most people, this will be a failed battle.


The second method to deal with this situation is to minimize costs as much as possible and generate as much revenue as possible when it is profitable. We have seen and will continue to see that a small application can generate hundreds of thousands of registered users and millions of dollars in revenue within a few weeks. Similarly, building something that people are willing to pay for, even if it is just impulse buying, is great. Go make your millions of dollars, then continue to develop new small applications or go enjoy some time on the beach.


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

We are going to explore this third method today.


Small Applications and Social Applications


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



The same thing happens over and over again - Yo, Yik Yak, Vine, Poparazzi, BeReal, Clubhouse, and so on. Examples like these are numerous. Social applications use new mechanisms to reach new heights, attracting users and investors, only to disappear when the next new thing appears. Facebook, Instagram, Twitter, and Snap still dominate and seem unshaken. If any challenger's mechanism is good enough, they can simply become a copycat.


Occasionally, a new giant is born, and the most recent example is TikTok. However, in most cases, they will exhaust their last bit of energy and gradually disappear. Nikita Bier is the only smart person here, and he successfully escaped the peak.


Sam compares social apps to fashion consumer goods, which is a good analogy. Try it on, show it off, and then throw it away. Like Shein, all of this seems wasteful. All the time, money, and energy are spent on user acquisition and retention, but users quickly move on to new apps.


Reading Sam's article has reignited my ideas about small applications and added a new dimension to my thinking: time.


This does not mean that small applications cannot become big, they can. The problem is that the vast majority of small applications cannot maintain scalability in the long term. If they accept this and see it as their advantage, what will happen?


Small application supernova and protocol Dyson sphere


With the emergence of Replit, AI, API, Urbit, and Web3 protocols, building applications has become easier, and we have seen an explosive growth of small-scale applications built for more specific use cases and user types.


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


This is the kind of small application that I'm talking about here. They're like supernovas, burning brightly, exploding, and then disappearing.



Competition (including direct competition and more common attention competition) and "children in candy stores" will make the transition from small application to large application companies very difficult, just like the situation with social applications.


But some of these small applications will achieve success in a period of time. What if we could build a Dyson sphere around the supernova of these small applications, capturing and utilizing their energy?


In a 1960 paper titled "Search for Artificial Stellar Sources of Infrared Radiation," physicist Freeman Dyson proposed a system to capture all the energy emitted by a star, providing almost unlimited power for human civilization. This idea was named after its creator as the "Dyson Sphere" and has been popularized in countless science fiction works over the past 63 years, despite its limited feasibility at present due to the amount of energy required to build it being more than that of our entire ecosystem.


We are looking for something similar in the digital field: a method that utilizes the energy expelled by successful small applications when they are popular, and quickly accumulates valuable data before they disappear.



The protocol that allows users to carry their identity, data, and relationships in a small application is a strong candidate. Of course, this is also part of the premise behind decentralized social protocols such as Farcaster and Lens, as well as data protocols such as Ceramic Network. Ceramic (a company invested by Not Boring Capital) described this opportunity in their article "Into the Dataverse" last year:


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


However, 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 spare no effort to ensure that they capture the energy of the Dyson sphere in the process. I think this is like an upgraded version of "Fat Protocol, Thin Application" with an added dimension of time.


Fat Protocol, Thin Application


There is a popular framework called "fat protocols, thin applications" created by Joel Monegro during his time at Union Square Ventures.


In 2016, before these things became obvious, Monegro wrote the first part: Fat Protocol .


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



"Regarding most blockchain-based protocols, there are two things that can lead to this situation," he wrote, "the first is the shared data layer, and the second is the introduction of cryptocurrency with certain speculative value as an access threshold."


In the follow-up report of 2020, starting from his own fund Placeholder, Monegro wrote about another part: thin applications.


He emphasized the benefits and drawbacks of building applications on top of encryption protocols. In summary, he believes that while "encryption service architecture is great for startups" because they can build quickly, cheaply, and with high capital efficiency, "many seem unclear on how to create long-term business value and defensibility when everything is open."


This setting is very good for users, solving many of our dissatisfactions with the internet. However, it raises new questions about the defensibility of the application layer. When everything is open and competitors can easily substitute for each other, how do you create long-term business value and defensibility?


If you replace the Web3 protocol with artificial intelligence API, the debate around long-term business value and defensibility in the face of fierce competition is also what people are discussing today.


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


-Cost Barrier: Concentrated costs and externalities not included in the protocol.

-Vertical integration: Successful applications may accumulate enough users to "become their own suppliers".- User staking: Using tokens to allocate value and benefits to users.


Three years later, some applications have used these three strategies and achieved varying degrees of success, with most of the value captured by the protocols. You need to scroll down to the 20th ranked token on CoinMarketCap's top tokens list by market capitalization to find an application token - Bitfinex's UNUS SED LEOToken, and it's not until the 22nd position that you can find an application you've heard of: Uniswap. Even Uniswap's UNIToken is tied to the protocol rather than the Uniswap application, but it is the closest one in the top 30.



It seems that the debate has come to an end: value returns to the protocol. Fat protocol, thin application.


If protocols and applications are not trying to fight gravity by creating defensibility and long-term commercial value, but intentionally designing themselves around the idea that "small applications cannot expect to create defensibility and long-term commercial value", what if they go with the flow?


Small applications, growing protocols


If you assume that small applications are supernovas, they may burn fiercely, explode, and then disappear. In that case, you can design a system to capture the energy and mass they emit and use it for production. Fortunately, this is much easier than building a real Dyson sphere.


Earlier, we talked about several methods that small applications can adopt:


-That's it. Raise venture capital, hire a group of people, constantly add features, try to retain customers for the long term, and try to establish a sustainable independent business, with a market value that could reach billions of dollars.

-Lifestyle enterprise. Do not 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 disappear.


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


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


When we explore this idea, this image may be helpful:



Small applications come and go, burning with brilliance and gradually disappearing, contributing new users, data, and relationships to the protocol in the process. Essentially, small applications become a group of customers that acquire channels for the protocol.


The agreement continues to exist, and small application developers share the rising benefits as the agreement develops. Each group plays a role, and each person receives rewards commensurate with their contributions.


Small Applications


If you think that "small" applications can become very "big" - gaining millions of users and generating millions of dollars in revenue - but usually cannot establish a defensible business, then you can design your business in a way that looks like a lifestyle enterprise. 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, as well as their data and relationships, are the treasure here.


You can keep the cash you bring in, the agreement doesn't care about that. It just wants these users and their data and/or relationships. With the support of its 3 billion users, Facebook has built a $600 billion business with almost endless social connections between these users, and Facebook knows them like the back of its hand. Companies like Reddit and StackOverflow have already started charging fees for accessing conversations on their platforms through OpenAI. Users, relationships, and data, which have long been the lifeline of the internet, are now more valuable than ever before.


Small applications can effectively gain these things through their novelty, topicality, and uniqueness, but no single application can approach 3 billion users.


Free from the worries of long-termism, your job is to create eye-catching new mechanisms and exciting products, and quickly capture as many users as possible. Build products that are loved by niche communities, do better than others, differentiate as much as possible, stand out, and acquire users.


Continuously Growing Protocols


Unlike lifestyle businesses, in this case, small applications are built on protocols that can withstand long-term defense. These protocols do not require flashy new mechanisms or features; they need to make it easy to build on these protocols and accumulate as many users and as much data as possible over time.


The constantly growing protocol assumes that users will not stick to any one product for too long, but if they can gain enough users through a combination of small applications built on top of these products, they can have an ecosystem that, from the user's perspective, looks like a constantly evolving super app. One username, all data, all social relationships, and many applications.


No application can challenge Facebook's more than 3 billion users, but perhaps a series of applications can. As time goes on and more users live on protocols, any new small application will be more likely to leverage these users to overcome cold start problems and may achieve sustainable development.


You may ask: How can a founder be willing to give up control over users and their data in order to increase protocol revenue?


My answer is: Token.


Incentivizing Small Application Developers


I promise that I didn't intend to write this article as a piece on the encryption industry, and it really isn't. I approached it from the opposite direction:


- Small applications can quickly expand or quickly disappear.- This can be considered a waste, and it is unlikely to challenge existing giants.-We should use the energy created by small applications during their short lives.-Open protocols may be a good way to capture these users and their data.

-But how do you convince developers to give up control of their data?-If used properly, Token is actually very useful for adjusting incentive mechanisms.


I even tried to come up with ways to do this without cryptocurrency - mergers and acquisitions, traditional open protocols, revenue sharing, equity swaps - but none of them are practical, and as far as I know, there is no other way to solve this problem.


Therefore, we are left with only Web3 protocol and Token, and some upgrades will be made.


Up to now, one of the issues that exist in the usage of tokens is that developers often use tokens to attract users to products that are not particularly eye-catching. Many Web3 products that I like have not issued tokens, and some even say they never will.


For some people, Token is like a band-aid, attracting users who hope to make quick money and hoping 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 application and stick with it?


But, what if you think the other way around?


Instead of directly giving users tokens to incentivize them to use subpar products, protocols can allocate a large number of tokens to developers to build excellent products on their own protocols and share profits after the protocol succeeds.


These application developers can keep these Tokens themselves or use them to attract new users, hoping to grow and earn more Tokens. The specific Token allocation mechanism issues need to be resolved one by one, and in-depth research on this issue is beyond the scope of this article, but I believe it should be like this:


- Provide small prepayments for each application.-Based on the number of new users, token incentives, as well as ongoing data and participation incentives.-Incentives through application program collateral.-If new users are proven to be fake and only participate for short-term profit, their token incentives will be reduced.


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


With more small applications being built on top of protocols, more users creating usernames on protocols, and more data and value being exchanged on protocols, the protocols themselves become more valuable, and all developers who contribute to their success can share in the rising profits.


The idea of providing tokens to applications to build on top of them is not new. This often happens in the encryption field, and many protocols even have risk funds to support projects that plan to build in their ecosystem. Chris Dixon wrote about some of these ideas as early as 2017 in "Crypto Tokens".


Here the difference is that the application itself should not issue its own tokens. Small applications should use the protocol's tokens and push more value towards the protocol. In any case, most of the value will accumulate here. They need to recognize their transience and be motivated to make the protocol itself successful.


They should do what they usually do to build the most remarkable applications, essentially just replacing their database with a protocol.


This is a big ask on the surface. Having users and data is precisely why Facebook has seen such massive growth. However, it's not for everyone. Optimistic idealists should continue to stay optimistic and idealistic, but for most small apps, I think it would be a very positive expected value to acknowledge that you won't become Facebook. You can create revenue in the short term and share in the upside of the agreement in the long term.


It is important to note that small applications built on and in cooperation with growing protocols do not necessarily need to be "cryptographic" applications. In other words, the protocol does not need to be a defining feature, much like how HTTP is not the defining feature of most websites. They can build whatever product they want - social apps, AI chat apps, 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 will not inevitably disappear and be wasted when the next popular application emerges.


In many cases, these applications should use cryptocurrencies as little as possible. Accept credit card payments, while keeping the complexity of the wallet as low as possible for users to retain their usernames. Help users pay for Gas fees, do not issue Tokens, do not manage decentralization, and do not make grand promises on the roadmap.


As long as users use the product for what it is best at, there is another benefit - they can get up and leave to find the next product on the agreement, taking their relationships and data with them.


As time goes on, developers of small applications can utilize the inherent composability of web3 to build products that work together. Other developers can build super applications composed of many of the best small applications on the protocol. They may incorporate cryptocurrency payments or other native features. However, this is not the focus of this article, and it is up to developers to gradually figure out the other technical and economic implementation details.


For this article, the focus is only on determining the trend of small applications, the challenges and opportunities represented by this trend, and a potential solution.


Establishing a sustainable ecosystem for small applications


The recognition of the current situation has opened up exploration into new models and business models. When not every company has to do the same thing, these models will emerge.

No matter whether developers intend to make them smaller or not, small applications are inevitable.


With the increasing ease of creating great products - I randomly stumbled upon a new software product on Twitter today that is 100 times better in quality than the best software product from 10 years ago - the core of breaking through, maintaining, and forming lasting business for any single product is becoming increasingly difficult.


Difficulties do not mean impossibility. In the next few years, there will be large-scale and persistent software companies emerging. What are the decisive characteristics of these companies is the topic of ongoing debate.


However, most applications will be small applications, even if they become "big" over time. They will differentiate themselves by doing one thing very, very well, attracting hundreds of thousands or millions of users, generating a lot of cash flow, and then giving way to the next exciting application.


During this process, they will waste valuable time and resources copying components they could simply take off the shelf, including user charts, and when they get stuck, they will waste valuable time and resources trying to figure out how to build defensive and long-term business.


I think there is a third method.


Small application developers can seize all the advantages of lifestyle enterprises, plus a little room for growth and immortal potential.


Users can establish a network of relationships and databases that span across applications, which become increasingly useful over time, instead of jumping from one application to another and starting over each time.


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


During this process, we may lay the foundation for a new way to establish large, persistent super applications consisting of supernova applications built on growing, persistent protocols.


Original article link


欢迎加入律动 BlockBeats 官方社群:

Telegram 订阅群:https://t.me/theblockbeats

Telegram 交流群:https://t.me/BlockBeats_App

Twitter 官方账号:https://twitter.com/BlockBeatsAsia

举报 Correction/Report
This platform has fully integrated the Farcaster protocol. If you have a Farcaster account, you canLogin to comment
Choose Library
Add Library
Cancel
Finish
Add Library
Visible to myself only
Public
Save
Correction/Report
Submit