The New Physics of Startups

The conventional wisdom around building and running software startups emerged from a single constraint: building software was expensive.

When engineering is your scarcest resource, every line of code carries risk. You validate before you build because building the wrong thing costs you six months and half your runway. The MVP exists to answer one question as cheaply as possible: should we build this at all?

That constraint is dissolving. And when the constraint changes, the strategy derived from it has to change too.

Where the old playbook came from

I ran a VC-backed startup for three years. Three pivots, $5M raised, a team of engineers building as fast as we could. Every wrong bet was measured in months and hundreds of thousands of dollars. The MVP wasn't a philosophy to us – it was survival. We couldn't afford to build something nobody wanted, so we did everything we could to validate first and build second.

That math made sense. When your feedback loop is "hire engineers → build for weeks/months → ship → learn," you need to front-load as much learning as possible before the expensive part.

The entire lean startup canon follows from this: customer development before engineering, landing page tests before prototypes, concierge MVPs before real products. Reduce the cost of learning by separating it from the cost of building.

What actually changed

AI didn't change everything. The underlying principles – reduce waste, learn fast, don't build things nobody wants – are as sound as ever. What changed is the cost structure.

What used to take a team of three engineers a quarter can now be built by one person in a weekend. Not a mockup. Not a prototype. A working product. The gap between "validate the idea" and "just build the thing" has collapsed.

The experience of shipping software now is qualitatively different from five years ago, and not just incrementally faster. The whole structure of the work has changed.

When building is cheap, the entire risk profile shifts. The expensive part is no longer "can we build this?" It's "can we get anyone to care?"

The old risks vs. the new risks

The lean playbook optimized for build risk – the danger that you'd spend your limited engineering capacity on the wrong thing. That risk still exists, but it's been massively deflated.

What's inflated instead:

Distribution risk. When everyone can build, the market floods with products. Getting attention, earning trust, reaching the right people – that's the hard part now. The bottleneck moved from the supply side to the demand side.

Taste risk. When building is cheap, the differentiator isn't whether you can ship – it's whether you can ship something that's good. Product sense, design instinct, knowing what to leave out. These are harder to systematize and harder to shortcut with AI.

Problem selection risk. If you can build anything quickly, the highest-leverage decision is what to build. Picking the right problem matters more than ever because the cost of picking wrong is no longer months of engineering – it's the opportunity cost of not building the right thing instead.

A new mental model

If the old model was "build → measure → learn," the new model might be closer to:

Understand → build → distribute → learn.

There's a tempting version of this moment that says: building is cheap now, so just build everything and see what sticks. Ship fast, ship often, let the market decide.

But that's a trap. Building may be cheap, but distribution isn't. Getting a product in front of the right people, earning their attention, building enough trust for them to actually try it – that's as expensive as ever. Maybe more so, because the market is noisier than it's ever been. You can't validate a hundred bets if nobody sees ninety-five of them. Product fatigue is real. People are tired of trying new things that don't solve a real problem.

So if you can build anything quickly, the highest-leverage work isn't the building. It's the understanding that happens before you build. Researching workflows. Developing empathy for how people actually work. Identifying problems that are genuinely worth solving – not just problems that are easy to build solutions for.

That's the part AI can't do for you. The research, the human judgment, the taste for which problems matter – that's the new bottleneck, and it's the work worth investing in. Every pass through the loop costs real distribution effort, so you want each one to count.

The old playbook said: validate before you build, because building is expensive. The new version isn't "skip the thinking because building is cheap." It's the opposite. Building is cheap, so you can afford to spend more time thinking. Get the problem right, then build with confidence, then distribute deliberately, then learn from what you shipped.

What hasn't changed

The first principle underneath all of this is the same: don't waste time on things that don't matter. Lean methodology was one instantiation of that principle, optimized for a world where engineering time was the thing you couldn't waste. The principle holds, but the instantiation needs updating.

I wrote about startup first principles separately, and the core of it applies here. When the environment changes, you don't abandon principles. You re-derive the practices from the same principles under new constraints.

Thriving in this environment means neither clinging to the old playbook nor declaring that nothing from the past applies. It means understanding why the playbook existed and rebuilding it for a world where building is the easy part.