Being a first-time founder was a crash course in everything at once. I’ve come away from that experience with a few new intuitions about startups, and how I want to build them going forward.
I’d like to capture these intuitions while they’re still raw. It’s n=1 samples, so hold it lightly. I’m writing this post for me!
Start with product and work backwards to technology
You’ve got to start with the customer experience and work backward to the technology. You can’t start with the technology then try to figure out where to sell it.
(Steve Jobs, 1997, Worldwide Developer Conference)
Prioritizing tech before product turns good problems to have into bad problems to have. You want to start with product, and work back to technology, taking the shortest path to market by doing things that don’t scale. This lets you iterate toward something that people actually want.
This is more important for startups than for open source or big tech. Big tech has big money. Open source has little money, but lots of time. Startups have little time and little money. If you can’t close the loop with the market, you won’t have the runway to do anything else. Product-market fit is everything.
Get to market as quickly as possible by building novel products with boring technology. Build novel technology only after running out of boring technology, and only when it generates an asymmetric advantage.
A startup pulls a thing from the future into the present
The future is here, it’s just not evenly distributed yet.
(William Gibson)
A startup’s job is to spot a thing from the future, then pull it into the present as quickly as possible.
Noticing things from the future is an act of intuition. It takes a somatic sensitivity to the present, and a willingness to trust your gut. Your unconscious mind can feel out the high-dimensional patterns that are unfolding in the environment around you. That’s what it’s there for.
Systems fool us by presenting themselves as a series of events.
(Donella Meadows, 2008, Thinking in Systems)
You can attune this intuition for the future by studying history, by scanning your environment, and by practicing structured methods like scenario planning.
With a sensitive intuition, it is possible to notice things from the future months, or years in advance. Occasionally, a person is so sensitive they can spot things decades ahead. This is a rare gift, and people like this are usually cursed to be Cassandras. They see too far, and no one listens. Many artists are like this.
Art at its most significant is a Distant Early Warning System that can always be relied on to tell the old culture what is beginning to happen to it.
(Marshall McLuhan, 1964, Understanding Media)
The sweet spot for startups is seeing 24 months into the future. This is a stone’s throw into the adjacent possible. It’s far-out enough to be asymmetric, familiar enough to be pitchable, and time enough to build.
…But you have to build fast! The frontier of the adjacent possible is always expanding.
It’s like fog of war in a Civ game. Others are also pushing into the frontier of the possible, coming at it from all directions. Within a couple of years, an idea can go from unthinkable to everywhere.
Time is your most valuable resource. Move quickly.
Draft off of ecosystem tailwinds
Sail with the prevailing winds of the ecosystem, and not against them. Every tech choice should be bog standard, except the one thing that gives you an asymmetric advantage.
Why? Tech is a Red Queen Race.
Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!
(The Red Queen in Lewis Carroll’s Through the Looking-Glass)
You can’t afford to not leverage the dominant platforms, even when the dominant platforms are inelegant, baroque, or ridiculous. React, Node, NPM, JavaScript build systems, Kubernetes, imperative programming, von Neumann Architecture, whatever. Use dominant platforms.
You can’t exit this Red Queen Race, in the same way that a whale can’t relitigate its evolutionary pathway. Gills would be great, but the whale works with what it has got—it holds its breath. Ineligant? Baroque? Ridiculous? Doesn’t matter! The path of evolution is always through the adjacent possible.
Dominant platforms set the table stakes. The relevant competition shifts to things on top. If you try to relitigate this tech stack, you’ll spend your runway just catching up to baseline. Meanwhile, your competition is drafting off of the tailwind. You aren’t building in a vacuum.
I have two anecdotes about this. The first is about building the text editor for Subconscious. Now, building a text editor is a nightmare on the web. I hoped iOS would be better, but while the low-level text APIs are better, you quickly run out of platform to do anything complex. After a couple months of struggling with low-level TextKit APIs, I npm installed ProseMirror. I made as much progress in two days as in two months. That’s the ecosystem tailwind.
Yes, text editing is a nightmare in browsers, but the Red Queen Race for rich text has been running for a long time on the web. This evolutionary arms race has resulted in an arsenal of tools for building web-based editors. iOS, meanwhile, has been insulated from this evolutionary arms race. It’s like an island populated by flightless birds.
Another anecdote: Copilot. Copilot is great! It helps you speedrun boilerplate, and rapidly orient within unfamiliar codebases. There are Copilot plugins for every major code editor, but if you’re building for iOS, you have to use Xcode. No Copilot for you. Stuck on iOS island, like a dodo.
Don’t get stuck on a tech island. Sail with the prevailing winds of the ecosystem.
A seed-stage startup gets to spend one risk token
Subconscious tried to innovate in two ways:
Technology: by building a decentralized knowledge graph protocol.
Product category: by inventing a new kind of tool for thought (not just another Roamlike).
That’s two innovation tokens:
new tech + new category = two risk tokens
In retrospect, I think we spent one innovation token too many.
During the seed stage, you probably have runway for just one innovation token. You must spend that innovation token unlocking your asymmetric advantage.
If you want to innovate on product category, you must spend your innovation token entirely on product creation. You must build, throw away, build, throw away, until you find the chemistry that makes your product go boom.
This means choosing a boring, battle-tested stack that solves 80% of the problem, so that building and throwing away is fast and cheap. If you’re innovating on product category, you can’t afford to innovate on tech, since you would have to throw it away anyway, while iterating toward product-market fit. On the other hand...
If you want to innovate on technology, you must spend your risk token on that technology. You need to be confident it’s a disruptive technology. The simple act of introducing this technology into an existing product category should be enough to make category go boom.
This means identifying an existing product category, with existing PMF, that is being held back by the limits of the current technological paradigm. If you’re innovating on technology, you can’t afford to innovate on product category, since your goal is to upend an existing value chain.
Roughly speaking, innovating on product maps to new market disruption, while innovating on technology maps to low-end disruption. These are different strategies, and a startup is pursuing one or the other. There are exceptions (OpenAI), but they are rare.
So, what could Subconscious have done differently? A one-ply take might look like this:
Since we were pursuing a protocol strategy, we could have built a Roamlike. The designer in me balks at copying and commoditizing. However, in the time we were building, we saw Obsidian do exactly that, and achieve product-market fit. At the same time, I am not convinced “commoditize Roam” is a VC-scale opportunity. Obsidian has taken the right approach by bootstrapping.
Flipping it around, we could have leaned into new product innovation using a standard SaaS stack, and drafted off of the ecosystem tailwinds of the web. This would have sacrificed our protocol story, but might have meant faster first-contact with the market, and a path to product-market fit.
However, the truth is more complex, and both of these fall flat. Ultimately, AI disrupted Tools for Thought as a coherent concept. LLMs have that signature quality of all disruptive technologies: they upend you incidentally.
So, know how you’re disrupting. Do just that.
Decentralized protocols are hard
The challenge emerges from two directions:
Distributed systems are hard.
Decentralized protocols are tech islands.
Berni Seefeld likes to say that there are two kinds of hard:
Algorithm-hard: you need the right PhD to solve it.
Coordination-hard: you need to align multiple stakeholders with different incentives.
It is well-known that distributed systems are algorithm-hard. However, the hardest thing about building a decentralized protocol is not the vector clocks or CRDTs, it is that you do not have 30+ years of ecosystem momentum behind you. Trying to manifest an ecosystem from scratch is a coordination-hard problem. As cdata says, “it’s network or nothing”.
Well, so, decentralizing the internet is difficult. I still think it is a worthwhile goal. We are building the foundations of the network society we’ll be living in for the next 100 years, and decentralization enables freedom, resilience, and permissionless innovation.
So, I’d like to decentralize the internet somewhat. What to do? Two potential approaches:
Build centralized-yet-decentralizable SaaS. Do as much as you can using the traditional web stack, changing as little as possible, and only where it changes the power relationship to the server. Pulling this off is like performing a judo move, aligning forces so that the problem solves itself—lateral thinking with weathered technology.
Look for places where decentralization is disruptive. As Cosma Shalizi puts it, “one of the lessons from the theory of natural selection is that a degree of isolation can be a great help to a new strategy in gaining a foothold.” Decentralized protocols are a tech island, but for this precise reason, they might just evolve new disruptive strategies. Look for those strategies, and focus on the ones that close economic loops, or change cost structures.
Recursively de-risk
The typical process for building something looks like this:
Understand the problem
Make a plan
Divide and conquer
Deliver to market
Let’s call this the top-down approach. We found that a startup benefits from inverting this process:
Sketch out the idea as quickly as possible
Identify the top risk, blocker, or unknown
Do the cheapest thing to de-risk it
Go to 2
Top-down planning is feed-forward. You won’t find out if your idea actually works until the very end. Recursive de-risking generates feedback quickly and cheaply, allowing you to find out early what works and what doesn’t.
Software economics is a barbell
Networked software has unusual economics:
Fixed costs are cheap
Labor is expensive
ARPU is low
Copying software is zero marginal cost
Adding a user is zero marginal cost
Network effects are powerful
The entire world is your addressable market
The entire world is competition
You can’t run networked software like a local cafe. Labor is too expensive and ARPU isn’t high enough for a small market. You have no local moat. Your ability to scale globally is limited by your cash on hand.
The most effective software economics are squished toward the extremes, like a barbell:
Open source projects lean into the fact that software is zero-marginal cost to copy, by making it even easier to copy. Open souce factors out the cost of labor by shifting to voluntarist economy of free giving and free copying.
Venture-funded startups accept that labor will be the dominant cost up front, but marginal in the long run as network effects and zero marginal cost take over. So, VC pulls money forward from the future, betting on that big payoff. Because of the weird physics of networked software, it either fails or succeeds big—10x or more.
The barbell economics of software allows open source and VC to take huge risks. Open source doesn’t have to justify itself to anyone. You do have to pitch VCs, but the courage of your average VC is far greater than the courage of big tech execs. That’s because they only need one in ten to be a home run. You’re a dandelion seed, VC is in the dandelion seed scattering business.
This higher risk-tolerance means more trial and error means more innovation. Both models allow for unbounded upside when a hit is discovered.
Startups are r-selected
A startup is a dandelion seed not an elephant, r-selected not K-selected.
R-selected species are explorers. They rapidly colonize new spaces. Picture an empty field. What fills it first? Weeds. That’s why we call them green fields.
Weeds inherit the earth. (Stewart Brand)
K-selected species emerge later. Once the niche begins to get crowded, it pays to grow tall, like a tree, instead of far and wide, like a dandelion.
Startups aren’t K-selected. They don’t compete for crowded niches. They expand into new frontiers. If they can’t find one, they create it.
There is a kind of wu-wei to admitting you are r-selected. Move fast, take risks, be opportunistic. Don’t get precious. Try a lot of things, and don’t be afraid to die.
A startup needs just one truly great asymmetric insight. Beyond this, 10D chess has diminishing returns. It’s guerrilla warfare, not siege warfare. Identify your angle, then move with speed, surprise, and violence of action to make contact with the market as quickly as possible.
Per ardua ad astra. -G