Why most MVPs fail before the first line of code
Most MVPs do not fail because of bad code. They fail because nobody wrote down the decisions before the build started: what the product does, what it does not do, and who has to say yes before it ships. By the time the gap shows up, the build is already three months in and the fix costs a rewrite instead of a conversation.
Validating the idea answers whether anyone wants the thing. This checklist answers what to decide once you know they do.
Across 17 years and 250+ projects, the builds that hit their launch date share one trait: every decision below got made before the build started, not during it. The ones that slip almost always stall on a scope argument, a stack debate, or a payment integration nobody planned for, all things this checklist forces into the open early.
Work through the checklist in four parts, in order: problem and customer, scope and cut list, build decisions, and launch and investor readiness. Skip a part and the gap does not disappear. It resurfaces later, usually the week before a demo, when fixing it costs the most.
None of this replaces a spec, a design file, or a technical plan. It sits in front of all three. Answer these 17 questions first, and the spec that follows is grounded in decisions instead of guesses.
Part 1: Problem and customer
Decide these before you open an editor. A product built for an assumed customer, without proof, gets rebuilt at least once. Deciding this first is cheaper than deciding it after the build.
1. Write the problem in one sentence
Write the problem in one sentence, in the customer's own words, not yours. If it takes a paragraph to explain, the problem is not clear enough to build against yet. A validation pass is the fastest way to get to that sentence if you do not have it.
2. Name the first real customer
Name a real person or a real company who has the problem today, not a persona. "Small business owners" is not a customer. "The owner of the plumbing company down the street who still tracks jobs on paper" is a customer. Build for that person first, not for a market.
3. Confirm someone will pay
Confirm that the customer will pay before the product exists, through a pre-order, a deposit, or a signed letter of intent. "Yes, I would use that" is not proof. Money changing hands, even a small amount, is proof. Interest is cheap. Commitment is not.
4. Decide what "done" means for version one
Write down the one outcome that makes version one a success: a signed customer, a working demo, a completed transaction. Decide this now, on paper. Arguing about what "done" means during the build costs far more than deciding it before you start.
Part 2: Scope and the cut list
This is where most MVPs go over budget and past the deadline. The fix is a hard cut list, decided before the build, not renegotiated in the middle of it.
5. List everything you want, then set it aside
Write the full list of every feature you want in the product. Every one of them, no matter how small. Then set that list aside. It is the roadmap for later. It is not the plan for version one.
6. Cut to the one job the product must do
Pick the single job the product must do to prove the idea works: one login flow, one core action, one output. Everything else is version two. A product that does one thing well beats one that does five things poorly, every time.
7. Write the cut list and share it
Write down, in one place, everything you decided not to build for version one: no admin dashboard, no third-party integrations, no custom branding, no mobile app. Share that list with everyone involved before the build starts. A written cut list stops a feature from sneaking back in through a side conversation.
8. Decide the metric that proves it works
Decide, before launch, the one number that tells you version one worked: a completed signup, a paid transaction, a returning user in week two. Pick it now. A metric picked after launch gets bent to match whatever happened.
Part 3: Build decisions
These decisions belong to whoever builds the product, but they still need an owner and a decision, not a default. An undecided stack turns into a week of debate. A decided one turns into a Tuesday.
9. Pick the stack for the deadline, not the résumé
Pick a stack the person or people building it already know well. A framework learned mid-build adds weeks nobody budgeted for. Custom code against a no-code or SaaS foundation is a separate decision worth making first, before the stack question even comes up.
10. Decide hosting before launch week
Pick the hosting and the infrastructure before launch week, not during it. A database, a queue, and a deploy pipeline are cheap to set up on day one and expensive to bolt on the week of a demo.
11. Design the data model around the one job
Design the data model around the one job from step 6, not around every feature on the list from step 5. A data model built for the full roadmap on day one carries migrations you do not need for months.
12. Add authentication only if the product needs accounts
Add authentication only if the product genuinely needs individual accounts on day one. A concierge test or a single shared login can carry version one further than a full authentication system, and the real thing can wait until real users show up.
13. Add payments only if money moves on day one
Add a payment integration only if money needs to move through the product before launch. A manual invoice or a pre-order form can substitute for a full billing system in version one. Wire in real payments once the product has paying users to justify the work.
Part 4: Launch and investor readiness
A working product and an investor-ready product are not the same thing. A working product runs. An investor-ready product answers the next question before it gets asked. This part decides what separates them, before the build reaches its last week.
14. Decide the demo path before you build
Decide, before the build starts, exactly what a viewer will click through in the demo: the screens, the data, the order they appear in. Building the demo path first keeps the build honest about what version one actually needs to do, and cuts anything it does not.
15. Prepare the answers before anyone asks
Investors and customers ask the same handful of questions: who is the customer, what does it cost to reach them, what happens once this money runs out. Write the answers before the meeting, not during it. A confident answer read off a note is still confident.
16. Set the launch date and hold it
Set a real date and hold it. A date that moves once tends to move again. The GigEasy build went from kickoff to an investor demo in 3 weeks, against a typical 10 week cycle, because every decision in this checklist was made before the build started, not during it.
17. Decide who owns the product after version one ships
Decide who keeps the product running after version one ships: someone on payroll, a fractional CTO, or a subscription that already includes the build going forward. A version one with nobody assigned to it after launch stalls the same week the investor meeting ends.
The checklist, ready to copy
Copy this into a document and check off each line before the first ticket gets written.
- [ ] Problem written in one sentence, in the customer's own words
- [ ] First real customer named, not a persona
- [ ] Payment or written commitment confirmed before the product exists
- [ ] "Done" defined for version one
- [ ] Full feature list written, then set aside
- [ ] The one job for version one chosen
- [ ] Cut list written and shared with everyone involved
- [ ] Success metric decided before launch
- [ ] Stack picked for the deadline, not the résumé
- [ ] Hosting and infrastructure decided before launch week
- [ ] Data model scoped to the one job, not the full roadmap
- [ ] Authentication added only if accounts are needed on day one
- [ ] Payments added only if money moves on day one
- [ ] Demo path decided before the build starts
- [ ] Investor and customer questions answered in writing
- [ ] Launch date set and held
- [ ] Owner assigned for after version one ships
How to use this checklist
Work through the four parts once, at the start, before any code gets written. Revisit the cut list every week. Any feature request that shows up mid-build gets checked against it: if it is not on the list, it waits for version two.
Do not treat this as a form filled out once and filed away. A checklist decided once and then ignored during the build is worse than no checklist at all, because it creates the appearance of a plan without the discipline of keeping one.
The order matters more than the speed. A team that answers all 17 items in a single afternoon is in better shape than one that has been "building" for six weeks with four of them still undecided.
What comes next
Once the four parts are decided, the build itself is the easier half. Applications is a monthly subscription: $7,999 a month, with a first version delivered inside the first month, roughly 3 weeks, and you can stop any month after that. Everything built belongs to you, and a 14-day money-back guarantee covers the first two weeks.
The decisions in this checklist are free. The build is not, and a build against a decided scope costs less than a build against a scope still being argued about.
Write to me. I answer within 24 hours, every working day, in writing.
Send a message ›