Free tool
What belongs in your MVP?
For founders with an idea and nothing built yet. Twelve questions, then a version one you can defend and a cut list with reasons. No signup.
- 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
- 01
Almost every failure 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 what went wrong.
- 02
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 for a second attempt went into features that were never load bearing.
- 03
Cutting that list 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
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.
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.
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.
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.
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.