The Menu Is Gone
When anything can be built on demand, the moat moves from what you’ve made to what compounds through the making.
There’s a feeling settling across the B2B software world right now, and it’s worth naming before arguing with it. The feeling is: why pre-build anything?
Walk into a customer. Ask them what they want. Define it with them. Get it built. That’s it. No menu, no catalogue, no pre-packaged solution. Just a kitchen, a good set of ingredients, and the ability to cook what the person in front of you actually wants to eat.
The old model was the restaurant. You wrote the menu in advance, shipped the dishes, defended them against copycats. The new model is a kitchen with a master chef who can cook almost anything, on demand, in minutes. Which is wonderful for the customer. And a problem for anyone whose business was built on selling menus.
So the question every founder is now living with: when anything can be built, what is worth building in advance? or what is the right approach to build things in advance?
Where the metaphor breaks
The framing above contains a convenient lie, and it’s worth puncturing before it hardens.
Build-on-demand only works if the customer can specify what “on demand” means. Most of the time, they can’t, atleast completely and comprehensively.
They know the problem they’re tired of, the screen they hate, the meeting that keeps going badly — but they don’t know what a good solution looks like until they see one. The whole discipline of product management exists because “just ask the user” doesn’t work when you just leave it on the customer.
So the service-as-software story — customer walks in, defines the need, system builds, job done — breaks down quietly at the first step. You can generate whatever the customer specifies. But specifying what’s actually worth building is still work, and it’s work most customers aren’t equipped to do well on their own. It needs a lot of understanding of “what else” is there out there, what is best way to solve the problem they are highlighting and so on.
Which means the business hasn’t been displaced. It’s been relocated. The valuable thing is no longer the code that gets written after the spec. It’s the spec itself — the ability to translate a messy organisational problem into something the kitchen can cook. That’s still a product. It just no longer looks like one.
What’s actually dissolving
The moats we used to rely on are softening faster than most people want to admit. Investors are telling founders behind closed doors what they won’t say on stage: thin wrappers, horizontal tools, and generic productivity software are being repriced downward.
Every integration you laboured to ship is becoming a utility — MCP and similar standards are turning “being the connector” into something closer to TCP/IP. Every UI workflow you optimised to keep humans productive inside your software matters less when agents are doing the work humans used to do. Every feature moat you built with six months of engineering is now a weekend project for someone with strong product sense and good prompts.
This isn’t hype. It’s what the pricing on capital has started saying. The products that still command premium aren’t surviving on feature lists. They’re surviving on something the feature list doesn’t describe.
Where the moat moves
Two broad lines of thought in this conversation are worth reading carefully.
The first is Sequoia’s recent Services: The New Software, which lays out the argument in starkly simple terms: if you sell the tool, you’re in a race against the model. If you sell the work, every improvement in the model makes your service better. Their framing is copilot to autopilot — copilots sell tools, autopilots sell outcomes. The shape of a defensible AI business is moving from shipping artefacts to delivering work.
The second is a Harvard Business Review argument, further synthesised by many others: when every company can use the same AI models, context becomes the competitive advantage. Their data is striking — two companies using identical AI tools can produce dramatically different outcomes, based almost entirely on how much of their specific context and learning the tools have absorbed.
This reframes the moat question. The moat is no longer the artefact. It’s the architecture of absorption — how deeply the system learns from each interaction, and how that learning compounds for the customer who keeps showing up.
A hierarchy worth internalising
There’s a useful distinction making the rounds in strategy circles, and it’s the clearest frame I’ve seen for thinking about which data actually defends a business:
Exhaust data is logs, telemetry, raw activity traces. Everyone generates it. Nobody’s defended by it.
Operational data is transactions, workflows, the actual work product. More valuable, but structurally similar across competitors — everyone in a category captures roughly the same shape of it.
Interactional data is how users engage with your system: their choices, corrections, preferences, tradeoffs. Defensibility starts here, because this data is inseparable from how the system was designed to elicit it.
Learning data — reinforcement signals, evaluation feedback, human-in-the-loop corrections — is the rarest. It doesn’t emerge accidentally. It exists only when the system is deliberately architected to capture it.
The sharper point, from the same piece: what competitors cannot easily replicate is not the data itself. It’s the behaviour that generated the data in the first place. A competitor can buy a dataset. They cannot buy the specific interaction design that produced it.
The uncomfortable consequence
As a builder the thought that I fight with every day is - if the moat is feedback architecture, then the moat does not exist on day zero.
That’s the part I find difficult and I trust other founder do too. The old idea of a moat was structural — something you could describe in a seed deck, ringfence with engineering effort, and point to before your first customer arrived. The new idea is temporal. You can’t point to it on day one. You can only point to the design that will produce it, and then wait for it to compound.
Which leaves founders with a harder job than the old one. You’re no longer defended by what you’ve built. You’re defended by what your product is becoming — day by day, customer by customer. Every interaction either thickens the moat or doesn’t. Every feature you ship either generates learning data, or it’s just code.
So the disillusionment about pre-building is, in one sense, correct. The old form of it — write the menu, defend the menu — is fading. But something more demanding has taken its place. You still build. You just build a machine for learning, not a machine for serving.
The menu is gone. The kitchen remains. And now the kitchen has to get smarter every night, or the one next door will.
The author is building Auron — an AI-powered voice and conversation intelligence platform that captures and enriches organizational knowledge from meetings, calls, and conversations. Auron turns every interaction into structured signal that teams can act on.