Build the small thing

If you can build, your validation problem isn't shipping — it's stopping.

The trap you're in

Technical founders don't build MVPs; they build MVOs — Minimum Viable Orchestrations, with auth, queues, admin panels, and a settings page for a product with zero users. Every feature feels like progress. None of it is evidence. The most expensive product you'll ever build is the one that works perfectly and nobody wanted.

Define the line before you start

Before the first commit, write three sentences into your build scope:

1. The one workflow that must work end-to-end for the product to be real.
2. The must-have list — features without which that workflow fails.
3. The explicit out-list — the things you are not building in v1, written down while you're still disciplined.

If a new idea arrives mid-build (it will), it goes on the out-list, not into the sprint. You're not rejecting it; you're sequencing it behind evidence.

Build to the experiment, not to the vision

The v1 exists to answer the question your validation left open. If the open question is "will people pay?", v1 is the smallest thing a stranger can pay for — maybe a workflow with hand-done steps behind the scenes. Config, onboarding polish, and scale concerns are all "after evidence" work.

Keep the practical layer sane

The build itself needs boring support — tasks, notes, the registry of services and where credentials live. Keep it lightweight and separate from strategy; in the app this is the Build Workspace, deliberately walled off from the scorecard and gates so shipping work never masquerades as progress.

And when the build stalls — because the scope crept, not because you're lazy — that's a decision to make, not a feeling to endure. Write it in the decision history: what got cut, and why.

Next: Launch.