Cezar Babin’s Blog

Winner-take-all requires a winner

The software industry spent three decades producing winner-take-all outcomes. The entire VC model depends on it. What if AI applications simply don't generate them?

Every previous technological cycle came with its own set of startup challenges, and venture was the right tool to combat them: winning new surfaces like the browser, rewiring procurement, proving reliability long before the market bought in. SaaS was disruptive to the business model of software. Cloud was foreign, requiring enterprises to abandon the comfort of their own data centers. Mobile demanded entirely new interaction paradigms. These cycles were contrarian, misunderstood, or structurally disruptive. Venture capital thrived because incumbents were slow to respond and startups had the window to build compounding advantages before anyone else showed up.

AI is none of these things. It works. Every CEO wants to adopt it now. For the first time in decades, startups and incumbents are chasing the same territory with the same urgency. It's an execution race. And if all that is being funded is a go-to-market apparatus, the advantage evaporates the moment a well-run competitor watches the first mover navigate the product maze, and then walks the cleared path at half the cost.

Risk capital, to be justified, has to offer asymmetric returns. To paraphrase Howard Marks: for great returns it's not enough to be right, everyone else has to be wrong. In AI, everyone is right. So even in the best case, the results of these investments will be average. Average is not how venture funds work.

The product isn't a product

The cost of building software is collapsing toward zero. This single fact restructures everything about product competition in AI. When anyone can build anything, product advantages don't compound. Without network effects or deep operational complexity, all you are doing as a first mover is charting the path for everyone behind you.

AI application companies positioned themselves as middleware: sitting between foundation models and enterprise customers, filling gaps that raw models couldn't handle. Limited context windows, hallucinations, no access to private data. Early movers like Harvey, Hebbia, and Legora deserve credit for identifying and solving them. But these gaps are closing with every model generation and labs are now delivering comparable experiences with far less boilerplate.

Speed of execution is not a moat. Being first to market, as Thiel would put it, means you are paid to make the expensive mistakes that help everyone else. Unless you hold the last technological advantage in a chain, you are perpetually exposed to whoever builds next. And in AI, "next" arrives every few months.

Scale doesn't save you either. In a world where generating code costs nearly nothing, it becomes viable to build narrowly scoped, domain-expert agents that outperform general-purpose tools on every metric that matters. A specialized regulatory compliance agent will always beat a do-everything legal AI for the customers who care most. 

Even when you do capture a market, there is no pricing power. The knowledge that your software can be replicated shifts leverage to the buyer. They don't need to actually switch. 

It's the distribution, stupid

So the product isn't durable. What about distribution?

Distribution has always been the decisive advantage in vertical software: the company that pushes through procurement barriers, in a category where innovation is exhausted and the channel carries friction, occupies a position that is nearly impossible to dislodge. This is last mover's advantage.

The counterarguments 

Some will say go-to-market and product are inseparable and that FDEs are really de facto product managers that embed with customers, extract tacit knowledge, and feed those insights back into the software over time. Yet, any feature that proves critical for a particular customer is trivial to copy. The real question is not whether FDEs contribute to product development, but whether that contribution translates into pricing power. It doesn't. Customers that know what they want can increasingly get those modifications built directly with AI coding agents.

Others point to switching costs. Once an enterprise has spent months implementing one vendor's system, trained workflows around its quirks, and built institutional knowledge about its failure modes, the appetite for starting over dwindles. But the calculus is shifting. Many buyers already view AI products as simultaneously expensive and easy to replace. As costs continue falling, the ROI equation for building and customizing internally only becomes more attractive. Switching costs matter less when the alternative is not switching to a competitor but building your own.

The outcome-based pricing thesis is the strongest case: land with a customer, iterate on their specific workflows, then transition to pricing tied to measurable results. If executed well,, this is genuinely disruptive. But the implication is non-trivial. Outcome-based pricing means assuming responsibility for a function that was previously strategic to the buyer. At that point, one is no longer just a vendor, but a direct competitor to the customer.Any provided solution must be costly enough to justify outsourcing while remaining sufficiently non-strategic that the buyer is comfortable handing it over. Navigating this balance at scale will prove challenging.

A new distribution engine

OpenAI launched an Apps SDK on Monday (see here). This effectively means that developers can now build apps inside ChatGPT:

Search, not AI, is still the foundation of knowledge work. 

The Google search box was not just a necessary precursor to Artificial Intelligence, good search already looks a lot like it. Take the question “what is the boiling point of alcohol?”. AI can work through the physics and derive the answer, or it can just…look it up.

In a perfect world, where every question has a ready answer, you search. In the real world, some answers exist and others have to be worked out. Or, you let AI do the thinking.

Thinking, rather than searching is what can cause bad AI outputs (or hallucinations). A published source is usually more reliable than an answer an LLM derives from scratch. At worst, retrieval might miss a relevant document, but derivation can fabricate one.

This is clearest in serious knowledge work, where correctness is critical and answers take multiple reasoning steps. Small mistakes compound. The more “thinking” AI does, the higher the risk of hallucination.

The best way to lower this risk is to lean harder on search and less on derivation. Reasoning was never the problem. That’s the fun part of the job. 

Yet in most AI chatbots, reasoning and search are fused into one black box that answers questions instead of helping users do sensemaking. Wouldn’t it make more sense for search and AI generation to be separate?

The search for reasoning “context” can’t look like a Google search box, where you type in an intent and then groom through results. It should look more like a loop of search, review, synthesize, search again. It is more of a recipe than a search goal. It’s search that lets you specify how to search, not what to search.

Search, taken to an extreme, can look like an ETL loop that mines data for signal. Letting users define the search strategy in detail creates a much better leverage point for human-machine interaction. It keeps the fact foraging deterministic, and lets AI reasoning do what it does best. 

These days innovation is commonly thought of as the job of the small Sillicon Valley startups that have no respect for the status quo. The "Lean Startup" has become the de-facto rule-of-the-land and every enterpreneur has mention "leanness" on their slide decks to be taken seriously. To innovate, you need to be fast, take creative risk and iterate.

Yet real veterans of the craft, like Amazon, prove that innovation has nothing to do with being lean or small or iteration. Amazon has repeatedly entered new markets and out-innovated incumbents, seemingly violating every rule of the "playbook".

The phrase “innovation playbook” sounds like a contradiction to begin with. If innovation were a defined process, wouldn't everyone "innovate"? In practice, it's closer to a decision-making framework, best understood in contrast to alternatives.

Sillicon Valley thought leadership has gotten innovation completely wrong. The “Lean” framework is, at its core, a way to operate under extreme constraints. Amazon, as I will show below based on my personal experience, has a much richer understanding of what it really takes to do it. 

The contrast

Sillicon Valley preaches: “build an MVP, ship fast, measure and validate, iterate, stay efficient.” Amazon aims for a Minimum Lovable Product. Where others “measure and validate,” Amazon “dives deep” and “invents and simplifies.” “Customer obsession" often comes at the expense of efficiency. It’s not a deliberate rebuke to Valley dogma, but it does invert the usual iterative paradigm.

1) MLP vs. MVP

A groundbreaking product can't be beta-tested into existence, it has to start with an uncompromising vision. To illustrate the point,  MVP is a tactic for sharpening focus in a resource constrained world, while MLP is all about focusing on a great user experience. Two very different decision-making frameworks with serious ramifications.

When the first Kindle was built, Jeff Bezos insisted on cellular connectivity even though the default pattern was syncing through a PC. An MVP-focused team might have cut wireless to ship on time. Wireless was the riskiest part, and much of the team saw it as nonessential to basic viability. Bezos kept it because the “magic moment” depended on it.

2) Process vs Outcome

As anyone who’s worked on a complex project knows, ambiguity shows up no matter how crisp the vision. Amazon equips its people with tools that reward analysis and judgment, rather than mindless execution.

Instead of “ship quick and fail fast,” Amazonians “insist on the highest standards.” Instead of “incorporate user feedback,” Amazon “invents and simplifies.” Instead of “iterating” it “dives deep.” 

Intellectual rigor is the point, and it’s enforced through a writing-first process best exemplified by the PRFAQ—a ritual that can feel brutally nitpicky. A good PRFAQ forces clarity of thought. Ideas get shaken around until they land as a cohesive whole. That same writing culture shows up in technical designs, security reviews, and operational readiness. The bar is incredibly high.

3) Speed vs. quality

Quality is non-negotiable, but it doesn’t have to slow execution. The one-way door vs. two-way door framework keeps decisions fast when they’re reversible and careful when they aren’t. “Disagree and commit” turns debate into forward motion.

Teams inside Amazon still run segments, VOC, user studies, alphas/betas, and A/B tests. They’re tools for refinement, not for steering the product away from its vision. A/B tests pick the button that converts better; CSAT confirms the experience worked as intended. Occasionally data surfaces an outlier that deserves a strong response, but the vision doesn’t swing with every experiment. Product-market fit is not "found", it's forged. As Jeff Bezos likes to point out, when the data and the anecdotes disagree, trust the anecdotes.

4) Nimble at scale

A common theme in growing organizations is better communication and code re-use across teams. The Amazon approach is counterintuitive: in the short term, even teams building similar things should often duplicate. Coordination costs and external interfaces drag more than duplication does. It's important to realize that duplication is expensive. Yet, the investment is fully worth it. Costs can be consolidated later, organizational and technical inefficiencies can be fixed, but disappointed customers rarely come back.

What does this all mean? 

One striking conclusion is that this kind of innovation is expensive. Many of the tools above spend money to buy clarity, quality, and speed. The question is: can you innovate like this as a resource-constrained startup? A company chasing the next milestone ahead of a funding round rarely has the slack to apply this level of rigor and dedication to the vision. 

What is absolutely true about startups—and what justifies the “Lean” framework—is that they operate under extreme information asymmetry. Startups tend to proliferate around technology cycles that enable new markets. New markets come with information gaps that you can only close by putting product in front of users and learning from their behavior. In that model, speed and cost efficiency are essential.

But that’s the key point: lean is optimized for discovery under constraints, not for invention under conviction. Lean assumes the primary risk is building the wrong thing, versus knowing what to build and doing it the right way. Use the right framework for the right job.