The plan
One page. Four phases.
Eight weeks.
An MVP project plan should fit on a single page. If it is longer, your scope is too big. The plan has four sections — each maps to a phase of the build. At Wall & Fifth, the plan is created during weeks 1–2 and executed in weeks 3–8.
Hypothesis and success metrics
What are you testing? Who is the user? What does success look like? Define this in one sentence each. "Freelance designers earning £40k–£80k will pay £20/month for a tool that combines invoicing and project tracking." If you cannot write this sentence, you are not ready to build.
Scope boundary
A list of what is in scope and — critically — what is deliberately out of scope. The out-of-scope list is more important than the in-scope list. It is where you prevent the MVP from becoming a full product before launch.
Phase timeline with deliverables
Week-by-week breakdown: what gets built, what gets reviewed, what gets decided. Each phase ends with a tangible deliverable — not a status update. Scoping deliverable: user flows and feature spec. Build deliverable: staging access. Launch deliverable: live product.
Technology and architecture decisions
Tech stack, hosting, database, payment provider, third-party services. All decided upfront, not mid-build. These decisions affect timeline, cost, and scalability — make them deliberately rather than by default.
Phase by phase
The 8-week MVP
project plan.
Here is the exact phase structure we use at Wall & Fifth. Every MVP follows this plan — adjusted for scope but consistent in structure.
01
Phase 1 — Discovery and scoping (weeks 1–2)
Define the hypothesis. Map user flows. Design the data model. Set the feature boundary. Choose the tech stack. Define success metrics. Output: a scoping document, user flow diagrams, and a confirmed feature spec. This is the project plan.
02
Phase 2 — Core build (weeks 3–4)
Set up infrastructure. Build authentication, database schema, API layer. Implement the core workflow — the critical path from signup to value. Output: staging environment with working core functionality.
03
Phase 3 — Feature completion (weeks 5–6)
Build remaining features. Payment integration. Responsive design. Edge cases and error handling. Polish the core flows. Output: feature-complete application on staging.
04
Phase 4 — Testing and launch (weeks 7–8)
QA across devices and browsers. Performance optimisation. Production deployment. Domain configuration. App Store submission for mobile. Output: live product ready for users.
In detail
The components of a good MVP project plan.
Each component of the project plan serves a specific purpose. Skip any of them and the build suffers.
- Hypothesis statement — one sentence. What you believe, who the user is, what success looks like. This is the north star for every decision.
- User definition — one specific persona, described in enough detail to design for. Not "small businesses" — a named archetype with clear needs.
- Feature scope — the critical path only. Every feature justified by its role in the validation. If it is not on the critical path, it is not in the MVP.
- Out-of-scope list — explicitly named features and capabilities that are deferred. This prevents scope creep by making the boundary visible.
- Phase timeline — week-by-week with deliverables. Each phase has a clear output, not just a status update. Tangible things you can review and test.
- Tech decisions — stack, hosting, database, payment provider, auth method. All decided before development begins. Mid-build tech changes are expensive.
- Success metrics — the numbers that tell you whether the MVP worked. Defined before launch, measured after. Without these, the MVP is a product with no strategy.
Pitfalls
MVP project planning mistakes.
- Over-planning — spending 3 months on a plan for an 8-week build. The plan should take days, not months. If you are still planning after 2 weeks, the scope is too big.
- No out-of-scope list — every feature sounds reasonable in isolation. Without an explicit boundary, the scope grows until the MVP is no longer minimum.
- Vague success metrics — "we will see how it goes" is not a metric. Define numbers: 100 signups, 30% activation, 10% conversion. Specific, measurable, time-bound.
- Planning for the full product — the MVP plan covers 8 weeks and one validation. Do not include post-MVP features, year-two roadmap, or scaling infrastructure. That comes later.
- No decision points — the plan should include moments where you review progress and make a go/no-go decision. These prevent building something for 8 weeks that should have been adjusted in week 3.
Template
The one-page MVP project plan.
Here is the structure we use at Wall & Fifth. Every MVP project plan follows this format:
- Line 1: Hypothesis — "We believe [user] will [action] because [reason]"
- Line 2: Success metric — "Validated if [number] users [action] within [timeframe] of launch"
- Line 3: Core user — one persona, one sentence
- Lines 4–8: In-scope features — the critical path, listed as user actions
- Lines 9–12: Out of scope — explicitly deferred features
- Lines 13–16: Phase timeline — four phases, two weeks each, with deliverables
- Line 17: Tech stack — frameworks, hosting, database, payments
- Line 18: Launch date — fixed, non-negotiable
That is the entire plan. Everything you need to build an MVP. Nothing you do not. We create this during the scoping phase in weeks 1–2 of every engagement.
FAQ
Questions people usually have before the next step feels obvious.
What should an MVP project plan include?
Hypothesis, user type, feature scope, out-of-scope list, phase timeline with deliverables, tech decisions, and success metrics. It should fit on one page.
How long should planning take?
1–2 weeks. At Wall & Fifth, the scoping phase is weeks 1–2 of the 8-week build. The plan is the output of that phase.
Do I need a project plan before starting?
Yes. Building without a plan leads to scope creep and wasted time. The plan does not need to be complex — but it needs to exist.
What is the difference between a project plan and a roadmap?
The project plan covers the first 8 weeks. The roadmap covers the next 6–18 months. The MVP plan is deliberately narrow — one product, one launch, one validation.
Related pages
Start planning
Your MVP project plan
starts with a call.
Tell us what you are building. We will create the project plan during the scoping phase — hypothesis, scope, timeline, and success metrics. All included in the fixed price.