Build Three, Keep One

Exploration got fast. Deliberation didn't.

The worst outcome in software is finishing the wrong thing. You spend three months on a feature, ship it, and watch users ignore it. The code works. It solves the wrong problem.

Teams built entire disciplines around that fear. PRDs, design reviews, estimation, planning poker — every ceremony existed to prevent expensive work from producing something nobody wanted. The instinct was rational. But the economics that justified it have changed. An agent builds in an afternoon what once took a week. Specification and decision-making now take longer than the code they describe.

Once building gets fast, the old instincts misfire. You debate an approach for two days that a prototype would answer in two hours. You write a PRD for a feature that a working demo would describe more precisely.

Try it

The fastest way to be right about something is to try it.

That sentence used to be an aspiration. Building an MVP still took a team, a quarter, a roadmap. The unit of experimentation was a whole product.

Now the unit of experimentation is an afternoon. You build two versions of a UI and look at them side by side. You spike an architecture, see that it breaks, and spike a different one — all in the time a meeting would take to schedule.

The discipline

When the direction is unclear, build more than one answer.

Not as a thought experiment. Not as a whiteboard diagram. Working code, end to end, that you can run and touch. Two or three versions. Then pick.

This sounds wasteful. The old instinct treats all code as expensive: three implementations means three times the cost. That was true. Two of the three will be thrown away — that is the point. They were fast to make, and their job was never to ship. Their job was to teach you which one should.

The real cost is not building three things. It is evaluating them. You have to understand each version well enough to compare. That takes attention. But attention spent comparing working code is more productive than attention spent debating abstractions. One produces evidence; the other produces consensus.

Most teams spec one approach, commit to it, and rationalize afterward. The waste is invisible because nothing was thrown away. The team built the wrong thing once instead of the right thing after two quick tries. The first outcome feels cheaper. It almost never is.

Wear the experimentation hat

Exploration is a posture, not a phase.

The team that gets this right does not run a “discovery sprint” followed by a “build sprint.” They wear the experimentation hat by default. Every ambiguous decision becomes a prototype instead of a debate. Every strong opinion gets verified fast, so opinions carry less weight than evidence.

That posture changes what seniority looks like. The old senior engineer predicted which approach would work. Their value was taste built over years of expensive mistakes. That taste still matters — a prototype answers whether something works mechanically, not whether it belongs architecturally.

But the leverage has shifted. The senior engineer who leans in builds three, tests three, and keeps the one that works. The one who resists still gets the right answer sometimes. The difference is that the prototyping team learns something new every afternoon, while the tasteful team mostly confirms what it already believed.

Keep the lesson, not the code

The hardest part is throwing work away.

When code was expensive, working code was too valuable to discard. You shipped what you built because building it had cost too much to abandon. That sunk-cost reflex persists. Teams protect prototypes — extend them, ship them, pretend they were meant to be real all along. The prototype becomes the product. Exploration collapses back into commitment.

Resist that. A prototype is a question you ask the codebase. Once you have the answer, the prototype has done its job. Keep the lesson, not the code. The real implementation should be written cleanly, with the benefit of everything the prototypes taught you. Sometimes the best prototype is already clean enough to ship. Often it is not. Either way, the decision is easier when you have seen the alternatives.

The scarce resource is no longer code. It is clarity about what to build. Prototypes buy clarity. The clarity is what you keep.

The new default

For years, the best advice was plan carefully before you build. The cost of the wrong answer was too high to skip the planning.

That advice no longer holds.

Plan less. Build more. When two approaches seem plausible, try both. When a feature feels uncertain, prove it with a working thing you can touch.

Build three. Keep one. Throw the rest away.