Free tool
What belongs in your MVP?
For founders with an idea and nothing built yet. Answer twelve questions and walk away with a version one you can defend, a cut list with the reasoning attached, and the decisions still open before anyone can quote you honestly. No signup, and it runs in your browser.
- 1The idea
- 2The features
- 3The decision
- 4Your brief
Start with the problem, not the product.
Four questions. Answer them the way you would explain it to a friend who does not work in your industry.
One sentence, and try to get through it without naming any technology.
Not a market. A person or a role you could go and speak to this week.
Whatever this is, it is your real competition. It is usually a spreadsheet or a phone.
An outcome, not a feature. Something you could check.
Why most first builds are too big
Almost every failed product we have seen was built competently. It solved a problem nobody was paying to have solved, or it solved six problems badly instead of one properly. The engineering was rarely the thing that went wrong.
What goes wrong earlier is the list. A founder writes down everything the product should eventually do, a developer quotes the whole list, and nine months later there is a large piece of software and no evidence anyone wants it. The money that would have funded the second attempt went into features that were never load bearing.
Cutting that list is uncomfortable and it is the highest return work available to you. This tool does the mechanical part of it in five minutes. The judgement it cannot do for you is deciding what you are willing to be wrong about.
Questions
- What counts as an MVP?
- The smallest version that proves the business, not the smallest version you can ship. Those are different things, and the gap between them is where most first builds are lost. A demo that impresses people proves nothing. A small thing that a real customer uses and pays for proves the whole idea.
- Why only two questions per feature?
- Because they are the only two you can answer honestly before anything exists. Ask whether a feature is important and everything is important. Ask whether the product still works without it, and whether anyone pays because of it, and the list sorts itself. Between them those two questions separate the build from the wishlist.
- Why do you ask about budget?
- Because a proposal is only honest if it is priced against something. We do not publish prices, since two projects that sound identical in a sentence can differ tenfold in architecture and risk, so a public number would be a guess. A range from you is what makes a real number from us possible. Not sure yet is a genuine answer and it is the first option.
- What happens to what I type?
- Everything is worked out in your browser as you go. Nothing reaches us unless you clear the readiness questions and choose to send your brief. If you do send it, we keep it for ninety days and then it deletes itself, and you get your own copy by email. If you do not, nothing is stored at all.
- Will you tell me what it costs?
- Not from this tool and not from one conversation. What you will get is the list of things still unresolved, because those are what move a price, and an honest answer about whether we are the right team at all. A number comes in a written proposal after we understand what is actually being asked for.