The MVP Development Playbook

A complete playbook for building and launching an MVP quickly without sacrificing the foundation for future growth.

This is the playbook I run when a founder needs to go from a pitch deck to a paying customer in eight weeks. It is not the only way, but it is repeatable and it has survived contact with reality across many projects. Use it as a checklist, not a script.

Phase 1: Frame the bet (Week 0)

Before any code, get the bet on paper.

1. Write the one page brief. Problem, target user, the smallest version of the solution, the one metric that proves it works.
2. Identify the riskiest assumption. Usually it is "people will pay for this" or "we can build this for less than X." The MVP exists to test that one assumption.
3. Define the launch cohort. Ten to fifty people you can name who will use this on day one. If you cannot name them, the MVP is not the bottleneck. Distribution is.
4. Set the budget. Time and money. Eight weeks and a fixed dollar number. Anything that does not fit gets cut.

If you skip this phase, you will build the wrong product beautifully.

Phase 2: Scope ruthlessly (Week 1)

The first week is about saying no.

1. List every feature you can imagine. Brain dump.
2. Group features into "must," "later," and "never." Most of the list goes into "later" or "never." Your "must" should fit on a sticky note.
3. Write the user journey for the must list. Five to ten steps from first touch to value delivered.
4. Choose what is bought versus built. Auth, payments, email, analytics: bought. Domain logic: built. Nothing else.
5. Pick the stack you already know. This is not the project for new technology. See my indie hacker stack for the kind of choices I default to.

By end of Week 1 you should have a one page scope and a list of components you will use off the shelf.

Phase 3: Spike the riskiest path (Week 2)

Engineers want to start with auth and routing. That is wrong. Start with the riskiest unknown.

1. Identify the technical risk. Is it the AI integration? The payment flow? The data import? Build a throwaway prototype of that path first.
2. Use real data. Mocked data hides the actual problem.
3. Decide whether to proceed. If the risk does not resolve in a week, the project may need a different shape.
4. Throw the prototype away. Or keep it as a reference, but do not build production on top of it.

The point of this phase is to retire risk early, when changing direction is still cheap.

Phase 4: Build the spine (Weeks 3 to 5)

Now you build the actual product, end to end.

1. Day 1 of Week 3: ship a deployed app. Even if it is just a landing page. Production from the start, not at the end.
2. Build vertical slices. One full feature at a time, from UI to database. Resist horizontal layering.
3. Wire up auth, payments, and email by Week 4. Boring infrastructure should be done before the polish phase.
4. Use feature flags even for a small product. They make the launch and post launch much calmer.
5. Keep a running list of cuts. Every "wouldn't it be nice" goes on the list, not into the build.

By the end of Week 5, the product should be usable end to end, even if rough.

Phase 5: Real users in the loop (Week 6)

You do not wait until launch to get feedback. You start now.

1. Bring in three to five users from the launch cohort. Watch them use it. Do not explain.
2. Triage feedback into "blocks launch" and "post launch." Be honest. Most things are post launch.
3. Fix the launch blockers only. Resist the urge to delight.
4. Set up basic analytics and error tracking. PostHog and Sentry, or equivalents. You need to see what users actually do once you launch.

Phase 6: Polish the seams (Week 7)

The week before launch is for the boring, important stuff.

1. Empty states, error states, loading states. Every screen.
2. Onboarding flow. Even a single welcome screen and a checklist beats nothing.
3. Pricing and billing. Test the full purchase flow with a real card.
4. Legal pages. Terms, privacy, contact. Use a generator if you must, but do not skip.
5. Accessibility pass. Keyboard navigation, alt text, color contrast.
6. Performance pass. The home and main task pages should load fast on mobile.

Phase 7: Launch and listen (Week 8)

Launch is not the finish line. It is the start of learning.

1. Soft launch to the cohort. Invite the named users first. Watch them use it. Fix what breaks.
2. Public launch when the cohort is happy. Not before.
3. Be present. Reply to every email and message in the first two weeks.
4. Track the one metric. The metric you defined in Phase 1. Everything else is noise for now.
5. Decide in writing: did the riskiest assumption hold? What is the next bet?

What this playbook does not do

This is not a playbook for funded scale ups, regulated industries, or products that need a deep technical moat from day one. Earlier in my career working on regulated systems, the timelines were three times longer for legitimate reasons. Use judgment.

If you want help running this playbook on a real project, that is exactly the kind of work I do under MVP development and fractional CTO engagements. Start a conversation when you are ready.

References

• The Lean Startup by Eric Ries
• Y Combinator Startup Library
• Shape Up by Basecamp