How we scope an MVP that can actually take a paying customer
Most first products fail on scope, not technology. The narrowing questions we ask in week one, and the three things we never cut.
Founder·14 January 2026·8 min read
The most expensive decision in a first product is made before any code exists: what goes in it. Founders consistently build what they imagined rather than the narrowest thing a customer would pay for, and the runway runs out before the learning arrives.
Discovery exists to prevent that. Here is what it actually asks.
Which single workflow, done well, would justify an invoice?
Not the vision. The one job a customer would hand over today if it worked. Everything else is a roadmap item, and naming it as such early removes most of the argument later.
Who is the first customer, by name?
A segment is not a customer. If you cannot name three organisations that would trial the product in its first month, the scope is still too abstract to build against.
What would make them stop using it in week two?
This question surfaces the real requirements faster than a feature list. It is usually data import, a permission model, or an integration with the system they cannot abandon.
Three things we never cut
Whatever else gets deferred, these stay in the first release:
- Authentication and a permission model that will not need replacing at the first enterprise conversation.
- Billing, even if the first customers are invoiced manually, because retrofitting metering is far more expensive than building it.
- Instrumentation, because a launched product with no activation data teaches you nothing.
A narrow MVP built to production standards beats a broad one built to demo standards, because only the first can take a paying customer, and paying customers are the only source of information worth building the second version on.