Discover more from Not Boring by Packy McCormick
Small Applications, Growing Protocols
A Small Essay on the Big Potential of Small Apps
Welcome to the 1,014 newly Not Boring people who have joined us since last Monday! If you haven’t subscribed, join 202,804 smart, curious folks by subscribing here:
Today’s Not Boring is brought to you by… Oceans
Oceans is a white glove outsourcing firm purpose built to help small businesses, busy executives, and high growth companies easily find and work with high quality EA+’s. All Oceans talent comes from Sri Lanka.
Why Sri Lanka? Simple: it has the best talent-to-price ratio on the planet. Oceans recruits, vets, trains, and employs top talent in the region from name brand firms and universities. Folks like Lawrence and Nihara (above) would fetch $100K+ salaries in the US, but with Oceans you can hire them as an EA+ for a fraction of the cost.
Oceans is already serving notable clients like Austin Reif (Morning Brew), Ndamukong Suh (Philadelphia Eagles), Joe McCann (Asymmetric Financial) and dozens of high growth SMBs. Over 20 Not Boring readers have already hired an EA+ through Oceans. If you’re looking to level-up your productivity, check them out today.
Hi friends 👋,
Happy Tuesday! Apologies for getting this one to you a day late. We had a wedding this weekend and an incredible Sixers overtime win on Sunday, and this is one that I didn’t want to rush.
I’ve been thinking a lot about what happens when it becomes trivially easy to build software applications — where value accrues, how and whether to build moats, and what to do about it — and today’s essay is one draft of my thinking.
Let’s get to it.
Small Applications, Growing Protocols
Brief dance in our hands,
Small Apps flicker, then depart,
Endless change expands.
It’s easier than ever before to build great apps. It’s harder than ever before to sustain them, to grow them into enduring companies.
Those two ideas are related, yin and yang.
Business models have not caught up to the potential of this new paradigm. Small Apps create more potential value than they can capture; partnering up with protocols1 could fill the gap.
That easier to create equals harder to defend is not a revolutionary idea. It’s one I’ve been playing with for a while, since I wrote Shopify and the Hard Thing About Easy Things in August 2020: “Here’s the hard thing about easy things: if everyone can do something, there’s no advantage to doing it, but you still have to do it anyway just to keep up.”
That essay was about ecommerce specifically, but I wrote that the same pattern was playing out across industries and verticals.
It’s happening in newsletters, where Substack gives writers an easy way to try to become the next Ben Thompson. It’s happening in video games, where Epic Games is building the tools and literally giving them away for free to expand the Total Addressable Market. It’s happening in AI, where OpenAI is giving everyone GPT-3 to build on top of.
That last sentence has become more apparent in recent months as GPT-3 gave way to GPT-4. And it’s not just the GPT-wrappers, it’s the fact that AI makes it easier for anyone to build apps themselves, for evermore niche use cases.
People like me like to write about whether or not these products have moats, whether they can stand the test of time. We’re already at the backlash to the backlash on that subject:
Making something people want is good advice. Massive winners will be crowned simply by making products that people love without worrying about growth hacking or moat digging. OpenAI CEO Sam Altman recently tweeted something to this effect:
But at the same time, with everything moving so quickly, users are like kids in a candy store, sampling everything, even paying for the sweetest, and then moving on to the next. Check out Lensa, the first of this generation of AI apps to take the App Store by storm:
From a peak of over $2.5 million in net revenue per day in December, Lensa fell to $206k per day by early January. That data is a few months old, but I can’t imagine it’s rebounded. Either way, that’s an incredibly successful outcome. The app’s founders made something people loved, earned a shitload of money for it, and slowly faded away as the AI avatar hype cooled and competitors rushed onto the scene.
It’s not just Lensa. How many of these apps do you expect will be making more than $200k per month a year from now? How many will grow to become Big Companies?
I suspect we’ll see this pattern play out over and over again in the months and years ahead. It’s only going to get easier to build apps, and their functionality will only get more mindblowing. People will try the newest, pay for them, and move on.
So if you’re building a Small App, what are you to do?
One way to approach the situation is to try to dig moats. Maybe you add social features to create network effects. Maybe you capture valuable proprietary data that you use to personalize and improve your product so much people don’t want to leave. Some will undoubtedly be able to build moats, and we’ll probably see a number of billion dollar companies created by one person or a small handful of people.
For most, though, that will be a losing battle. It pushes against the physics of these things.
A second way to approach the situation would just be to build cheaply, avoid raising money, and try to generate as much cash as possible while the getting’s good. We’ve already seen, and will continue to see, developers generate hundreds of thousands of signups and millions of dollars in weeks, and again, building something that people are willing to pay for, if only briefly, is fucking awesome. Go make your millions and rinse, wash, repeat (or go kick it on a beach for a while).
But I think there might be another, third way. Small Apps that recognize their fleeting nature can team up with protocols that are built to last to build something bigger and more durable collectively.
We’re going to explore that third way today.
Small Apps and Social Apps
Last week, Slow Ventures’ Sam Lessin wrote a compelling screenshot essay on Social Apps as consumable fashion instead of enduring networks.
The same thing keeps happening over and over again – Yo, Yik Yak, Vine, Poparazzi, BeReal, Clubhouse. The list goes on. Social apps ride new mechanics to ever-greater heights, luring both users and investors, before fizzling out when the next new thing comes along. Facebook, Instagram, Twitter, and Snap remain dominant, seemingly impervious to the onslaught. If any of the challengers’ mechanisms are good enough, they can just copy.
Very occasionally, a new giant emerges. TikTok is the most recent example. But usually, they burn out and fade away. Nikita Bier is the only smart one here. He sells at the top.
Sam compares social apps to consumable fashion, and it’s a good analogy. Try it on, show it off for a bit, and throw it away. Like Shein, it all seems so wasteful. All of that time, money, and effort spent on acquiring new users and retaining existing ones, only to see them flitter off to the Next Big Thing.
Reading Sam’s essay re-sparked the Small Apps idea, and added a new dimension to my thinking: time.
It’s not that Small Apps can’t get big; they can. It’s that the vast, vast majority can’t stay big for a long time. What if they accepted that and used it to their advantage?
Small App Supernovae and Protocol Dyson Spheres
As things like Replit, AI, Vercel, APIs, Urbit, and web3 protocols make it easier to build apps, we’re seeing an explosion of Small Apps built for evermore specific use cases and user types.
Some Small Apps will be so small that they’ll be built by one person for one person, others will ride the zeitgeist to millions of users but fade quickly. These are temporally small even if they get big for a time.
This is the kind of Small App I’m talking about here. They’re like supernovae. They burn brightly, explode, and fade away.
Competition (both direct and more generally for attention) and kid-in-candy-store users will make it brutally tough for Small Apps to turn into Big App Companies, as is the case with Social Apps.
But a number of these Small Apps will be successful for a time. What if we could build Dyson Spheres around these Small App supernovae that capture and harness their energy?
In a 1960 paper, Search for Artificial Stellar Sources of Infrared Radiation, physicist Freeman Dyson proposed a system to capture all of the energy a star gives off to give civilization virtually unlimited power. This idea has been named the Dyson Sphere after its creator, and it’s gained popularity through its inclusion in countless works of science fiction over the past 63 years, even though its current feasibility is limited by the fact that its construction would require more matter than is available in our entire ecosystem.
We’re looking for something similar in the digital realm: a way to harness the energy that successful Small Apps spit off when they get really big and accumulate valuable data really quickly, before they explode.
Protocols that let users carry their identity, data, and relationships across Small Apps are a strong candidate. This is, of course, part of the premise behind decentralized social protocols like Farcaster and Lens, and data protocols like Ceramic Network. Ceramic (Not Boring Capital portfolio company) describes the opportunity in their excellent post from last year, Into the Dataverse:
Our vision of the Metaverse will run on the Dataverse: a composable, web-scale data ecosystem—owned by everyone and no one. Developers will build interchangeable interfaces and online experiences that directly interact with the Dataverse and the composable data that lives there. The Dataverse will play arguably the most important role within the Metaverse: a shared, high-performance, always-available graph of all data created and used by all applications.
But I think Small Apps and Protocols can focus more intentionally on their respective roles in the context of time. Small Apps will burn brightly and explode, and smart Protocols will do whatever it takes to ensure that they’re the Dyson Sphere capturing the energy in the process.
I think about it like an update of Fat Protocols, Thin Applications with a time dimension.
Fat Protocols, Thin Applications
There is a popular framework, developed by Joel Monegro when he was at Union Square Ventures, known as “Fat Protocols, Thin Applications.”
In 2016, before any of this stuff was obvious, Monegro wrote the first part: Fat Protocols.
The general idea is that on the web, protocols like TCP/IP, HTML, and SMTP created a ton of value, but most of that value was captured by applications like Facebook and Google. On blockchains, however, the value capture equation might be flipped: protocols could both create and capture most of the value driven by the apps built on them.
“There are two things about most blockchain-based protocols that cause this to happen,” he wrote. “The first is the shared data layer, and the second is the introduction cryptographic ‘access’ token with some speculative value.”
In a 2020 follow-up, written from his own fund, Placeholder, Monegro covered the other side of the equation: Thin Applications.
In it, he highlighted the benefits and drawbacks of building applications on top of crypto protocols. Essentially, he argued that while a “cryptoservices architecture is great for startups” because they can build quickly, cheaply, and with a high level of capital efficiency, “wheat seems unclear to many is how exactly they can create long-term business value and defensibility when everything is open.”
This setup is great for users and addresses many of our gripes with the web. But it raises new questions about defensibility at the application layer. How do you create long-term business value and defensibility when everything is open and competitors can so easily substitute each other?
La plus ça change… This debate around long-term business value and defensibility in the face of tremendous competition is the same one raging today if you swap out web3 protocols for AI APIs.
At the end of the piece, Monegro laid out three ways that applications might create long-term value and defensibility:
Building a cost moat: centralizing costs and externalities unaccounted for by the protocols.
Vertical integration: successful applications may amass enough users to “become their own supply”.
User-staking: leveraging tokens to distribute value and upside to users.
Three years later, a number of applications have used these three strategies to varying degrees of success, but the fact remains that most value has been captured by the protocols. You need to scroll down to #20 on CoinMarketCap’s list of top coins by market cap to find an application token – Bitfinex’s UNUS SED LEO token – and to #22 to get to an application you’ve heard of: Uniswap. Even Uniswap’s UNI token is tied to the protocol and not the Uniswap app, but it’s the closest we come in the top 30.
It seems as if the debate is mostly settled: Gravity pulls value down to the protocol. Fat protocols, thin applications.
Instead of trying to fight gravity by creating defensibility and long-term business value, what if protocols and applications intentionally designed themselves around the idea that Small Apps can’t expect to create defensibility and long-term business value? What if they worked with gravity?
Small Apps, Growing Protocols
If you assume that Small Apps are supernovae, likely to burn brightly, explode, and fade away, then you can design a system that captures the energy and mass they spit off to be put to productive use. Fortunately, this is much easier than building a real Dyson Sphere.
Earlier, we talked about the couple of approaches Small Apps could take:
Go For It. Raise venture capital, hire a bunch of people, keep adding functionality, experiment with ways to retain customers long-term, and try to build a sustainable standalone business that could be worth billions.
Lifestyle Business. Don’t raise venture capital, keep the team very lean, and try to grab as many users and as much cash as humanly possible until you get acquired or fade away.
Of course, there’s a spectrum – you might raise just a little bit of venture capital at a low valuation so that even a small acquisition is meaningful, for example.
But earlier, I mentioned another, third way, and this is it: Small Apps, Growing Protocols.
A visual might help as we explore the idea:
Small Apps coming and going, burning bright and fading away, contributing new users, data, and relationships to the protocol in the process. Small Apps essentially become a swarm of customer acquisition channels for the protocol.
The protocol lives on, and Small App developers share in the upside as the Protocol grows. Each group plays a role, and each is rewarded commensurate with their contribution.
If you assume that Small Apps can get very big – acquire millions of users, generate millions of dollars – but typically can’t build a defensible business, then you could design the business in a way that looks a lot like the Lifestyle Business above. Don’t raise venture capital, keep the team very lean, and try to grab as many users and as much cash as possible. Those users, and their data and relationships, are the prize here.
You can keep the cash you pull in, the protocol doesn’t care. It just wants those users and their data and/or relationships. Facebook built a $600 billion business on the back of its 3 billion users, their nearly infinite friendships with each other, and everything Facebook knows about them. Reddit and StackOverflow, among others, are beginning to charge OpenAI for access to the conversations on their platforms. Users, relationships, and data, long the lifeblood of the internet, are now more valuable than ever.
Small Apps can acquire those things efficiently by virtue of their novelty, shininess, and specificity, but each one independently can’t come anywhere near 3 billion users.
Freed from worrying about the long-term, your job is to create the shiny new mechanisms and exciting products that grab as many users as possible as quickly as possible. Build products that niche communities adore, do one thing better than anyone else, differentiate as hard as you can to stand out and acquire users.
The difference with the Lifestyle Business is that in this scenario, the Small Apps are built on top of protocols that can be long-term defensible. 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 over time as possible.
Growing Protocols assume that users won’t stick with any one product for too long, but if they can acquire enough users through the constellation of Small Apps built on top of them, they can host an ecosystem that, collectively, looks like an ever-evolving Super App from the user’s perspective. One username, all of your data, all of your friends, many apps.
No single app will be able to challenge Facebook’s 3 billion+ users, but perhaps a constellation of apps could. And over time, as more users live on the protocol, it will be easier for any new Small App to tap into those users to overcome the cold start problem, and potentially, to get sustainably big.
You might be asking yourself: why would any entrepreneur sign up to fatten the protocol’s pockets and give up control of its users and their data?
I hear you, but hear me out: tokens.
Incentivizing Small App Developers
I promise, I didn’t start out with the intention of making this a crypto piece, and it isn’t, really. I came at it from the opposite direction:
Small Apps can get big quickly and fade just as fast
That seems wasteful and unlikely to challenge incumbents
We should harness the energy Small Apps create during their brief life
Open protocols might be a good way to capture those 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, when used correctly
I even tried to think of ways to do this without crypto — M&A, regular old open protocols, revenue sharing, equity swaps — but none are practical, and to my knowledge, no other approach to this problem has worked.
So we’re left with web3 protocols and tokens, with some upgrades.
One of the issues with the way application tokens have mostly been used thus far is that often, developers use tokens to attract users to products that aren’t particularly compelling. Many of my favorite web3 products haven’t issued a token, and some never will.
For those that have, tokens can be a band-aid, attracting users looking to make some quick money in the hopes that they stick around until the product gets good enough to be compelling on its own. Essentially, the question has been: how much do we need to pay people to use this app and stick around?
But what if you flipped that?
Instead of giving tokens directly to users in order to incentivize them to use sub-par products, protocols could give a large allocation of their tokens to developers to build excellent products on their protocols and share in the upside if the protocol succeeds.
The applications could keep those tokens themselves, or use them to attract new users in the hopes of getting even bigger and earning more tokens.
The exact token distribution mechanism would need to be worked out case-by-case, and going deep on that is beyond the scope of this post, but I would imagine that it would look something like:
Small upfront grant for each application
Token Incentives based on number of New Users, and for ongoing data and engagement
Inflation to incentivize staking by applications
Token slashing if New Users turn out to be fake, leave quickly, or don’t engage over time
There could be exceptions as well. An enterprising protocol might give Nikita Bier an outsized grant upfront in exchange for building his next x apps on the protocol, like Netflix paid Adam Sandler another $250 million to make four more Netflix movies.
As more Small Apps 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 of the developers that have contributed to its success share in the upside.
The idea of protocols giving tokens to applications to build on them is not new. This happens regularly in crypto, and many protocols even have venture funds to back projects that plan to build in their ecosystem. Chris Dixon wrote about some of these ideas in Crypto Tokens back in 2017 (there’s always a Chris Dixon essay).
What’s different here is that the applications themselves should be centralized and should not issue their own tokens. Small Apps should use the protocol’s token and push more value to the protocol, where most of the value is bound to accrue anyway. They recognize their ephemerality and are incentivized to make the protocol itself successful.
They should do everything that they would normally do to build the most compelling apps possible, they’d essentially just swap out their database for the protocol’s.
That’s a big ask to make on the surface. Owning users and data is exactly how Facebook got so big! Again, this is not for everyone. The Go For It camp should Go For It. But for most Small Apps, if you’re able to admit that you’re not going to be Facebook, I think this trade has a deeply positive expected value. You can generate revenue in the short-term and share in the protocol’s upside over the long-term.
Importantly, Small Apps that partner with and build on Growing Protocols don’t need to be “crypto” apps. In other words, the protocol doesn’t need to be a defining feature, just as HTTP isn’t the defining feature of most websites. They can build the products that they want to build – social apps, AI chat apps, whatever.
The next BeReal, Poparazzi, and Clubhouse should be built on open protocols, and perhaps the next Lensa should too, so that the user bases and data they build up doesn’t go to waste when they inevitably fizzle out when the next hot app comes along.
In many cases, these apps should use crypto as little as possible. Accept credit card payments. Abstract away as much wallet complexity as possible while letting users retain their username. Cover gas fees. Don’t issue a token. Don’t decentralize governance. Don’t make grand roadmap promises.
Just let the users use the product for the thing the product does best, with the added benefit that they can up and leave to the next product on the protocol and bring their connections and data with them.
Over time, Small App developers could leverage web3’s inherent composability to build products that work with each other. Other developers could build Super Apps composed of pieces of many of the best Small Apps on the protocol. They might bake in crypto payments or other native features. But that’s besides the point of this post; that’s up to developers to figure out over time alongside other technical and economic implementation details.
For this post, the point is simply to identify the trend towards Small Apps, the challenges and opportunities that trend represents, and one potential solution.
Towards an Enduring Small App Ecosystem
Acknowledging the reality of the situation opens up the exploration of new patterns and business models that open up when not every company has to Go For It.
Small Apps are inevitable, whether developers intend for them to be small or not.
As it becomes easier to build great products – the average new software product I randomly discover on Twitter today has 100x the capability of the best software product a decade ago – it becomes harder for any single product to break out, sustain, and form the kernel of an enduring business.
Hard is not impossible. There will be massive, enduring software companies born in the next couple of years. What the defining characteristics of those companies will be is the subject of ongoing debate (Compound’s Michael Dempsey coincidentally wrote a great short post on one potential path yesterday: Thin Layers of AI, Thick Layers of Personality).
But most apps will be Small Apps, even if they get big for a time. They’ll differentiate, do one thing really, really well, attract hundreds of thousands or millions of users, generate a lot of cash, and then give way to the next exciting thing.
In the process, they’ll waste valuable time and resources replicating building blocks they could simply take off the shelf, including user graphs, and when they’re in the thick of it, they’ll waste valuable time and resources banging their heads against the wall trying to figure out how to build defensibility and a long-term business.
I think there’s a third way.
Small App developers can grab all of the advantages of a Lifestyle Business, plus a little upside and immortality potential.
Users can build webs of relationships and banks of data that span apps and become increasingly useful over time instead of jumping from app to app and starting fresh each time.
And protocols have the chance to acquire more users, data, and activity in order to challenge many of the seemingly impenetrable incumbents over time.
In the process, we might lay the foundation for a new way to build big, enduring Super Apps made up of constellations of supernovae built on top of growing, enduring protocols.
Thanks to Dan for editing!
That’s all for today! We’ll be back in your inbox on Friday with your Weekly Dose.
Thanks for reading,
A couple definitions are useful to get us on the same page:
Applications: Digital tools or services that perform specific tasks for users. They are built using underlying protocols and often provide user-friendly interfaces that mask the complexities of the backend systems.
Protocols: Sets of rules and conventions for digital communication and data transfer. They establish the standards that enable different software systems, including applications, to interact and exchange information.
SMTP is the email Protocol; Gmail, Outlook, and Superhuman are three email Applications. Because of SMTP, you can read the same email whether you’re using Gmail, Outlook, or Superhuman, and users of any email application can send emails to each other.