The MVP scope conversation every founder should have before writing code

The most expensive sentence in software is "while we're at it." MVPs rarely fail because the code was bad; they fail because eighteen months of runway went into features nobody had validated.

One assumption, one product

A real MVP tests one assumption: that a specific kind of customer will pay for a specific outcome. Write that sentence down. Every feature that does not directly test it goes on the someday list. Billing tiers, admin consoles, integrations, native apps — almost all of it can wait.

The concierge test

Before building a feature, ask: could we deliver this manually behind the scenes for the first twenty customers? If yes, do that instead. Manual delivery teaches you what the automation should actually do — and sometimes reveals nobody wanted the feature at all.

What should never be cut

Scope-cutting has limits. Three things belong in every MVP no matter how small: instrumentation (you cannot learn from users you cannot see), authentication done properly (retrofitting security is misery), and a deployment pipeline (shipping should be boring from day one). These cost little upfront and are brutally expensive to add later.

Weeks, not quarters

Our rule of thumb: if the build plan exceeds fourteen weeks, the scope is wrong. Cut until it fits. You can afford to be wrong about a fourteen-week bet; a fourteen-month one can kill the company. The founders who win are rarely the ones who guessed right the first time — they are the ones who could afford the most guesses.