How to Build an MVP: The Exact Framework We Use to Ship in Weeks

Most founders think building an MVP takes 6 months. The ones who ship in weeks aren't cutting corners — they're cutting scope.

Here's the exact framework we use to go from a rough idea to a live product with paying users — without overbuilding, without wasting runway, and without hiring a full team before you've proven anything.

What an MVP Actually Is (And What It Isn't)

An MVP — Minimum Viable Product — is the simplest version of your product that lets you test your core hypothesis with real users.

It is NOT:

• A demo or Figma prototype
• A "Phase 1" of a larger roadmap
• A product with every feature on your list

It IS:

• One core user journey, working end-to-end
• Something real users can sign up for, use, and ideally pay for
• A tool for learning, not for shipping "the vision"

The founders who spend six months on their MVP are almost always building the wrong thing — not because the idea is bad, but because they haven't stripped it down to its single most important hypothesis.

The Framework: Scope Determines Timeline

Before anything else, understand this: your timeline is not determined by your tech stack or your team. It's determined by your scope.

Every week added to your MVP is a week of runway burned. Every feature added in the first build is a feature you have to maintain before you know if anyone wants it.

The framework below works when you commit to ruthless scope discipline.

Phase 1: Scope (Week 1)

The single most valuable thing you can do in week 1 is decide what you are NOT building.

We use a one-page product brief with four sections:

1. The core hypothesis

"We believe [user type] has [problem]. We'll solve it with [solution]. We'll know we're right if [specific metric] happens within [timeframe]."

This sounds simple. It's not. Most founders can't write this in one sentence without adding qualifiers. That's the problem.

2. The happy path

Map every step a user takes from sign-up to first value. Write it as a numbered list. Steps with sub-steps are a scope problem — simplify them.

3. The cut list

Every feature not on the happy path goes here. No admin dashboards. No notification systems. No settings pages. No onboarding wizards. No analytics dashboards. Cut it all.

4. Success criteria

How will you know this MVP worked? Pick one metric. Not five. One.

Deliverable: A one-page brief anyone can read in three minutes.

Phase 2: Design the Core Flow (Week 2)

We don't design the full app. We design the 3–5 screens that make up the core user flow.

High fidelity. Interactive. Real-looking — because you need to put this in front of actual users and get real feedback, not "yeah, interesting idea" feedback.

Show this prototype to 10 potential users before writing a line of code. Ask: "What would stop you from using this today?" The answers to that question should rewrite your scope, not your code.

The Figma prototype from week 2 typically surfaces more useful product insights than three months of post-launch iteration. Founders who skip this step pay for it.

Deliverable: Clickable Figma prototype of the core user flow.

Phase 3: Backend Foundation (Week 3)

This is the most boring phase. It's also the most important.

Getting the backend architecture wrong at this stage means refactoring at the worst possible time — when you have users, pressure, and technical debt accumulating simultaneously.

What we set up:

• Database schema: Model the data correctly now. Schema changes later cost 3x more in time and bugs.
• Authentication: User auth, sessions, roles. Not custom — use a battle-tested library.
• API structure: RESTful endpoints or GraphQL schema for the happy path only.
• Dev/staging environments: Two environments from day one. Non-negotiable.
• Basic monitoring: Error tracking before you have users is not optional — it's how you know things are breaking.

Deliverable: Working backend — auth, database, API scaffolded. Nothing glamorous. Everything necessary.

Phase 4: Core Feature Build (Week 4–5)

This is the sprint. You build the feature that makes the product work.

Not all features. Not nice-to-haves. Not edge cases.

The happy path.

A user can sign up, do the core action, and receive value. That's it. If that works end-to-end, the MVP works.

Common mistakes at this stage:

• "Just adding one more feature" — every addition pushes your launch date
• Building for scale you don't have — microservices and Kubernetes are not MVP infrastructure
• Optimising for performance before you know what users actually do

Deliverable: End-to-end core flow working in staging.

Phase 5: Polish & Stabilise (Week 5–6)

Real polish means the product doesn't look broken:

• Error states: What happens when something fails? The user needs an answer.
• Loading states: What do users see while waiting? A blank screen loses them.
• Empty states: What does a new user see before they've done anything? This is your first impression.
• Mobile responsiveness: If your product doesn't work on a phone, you've lost half your users before they've started.
• Basic analytics: Mixpanel or PostHog set up from day one. You need data from the first user.

Deliverable: A product you can demo without apologising for it.

Phase 6: Launch & Handoff

• Deploy to production with proper CI/CD
• Set up domain and SSL
• Add error monitoring (Sentry)
• Full handoff: every account, every key, every repo — you own everything
• First cohort: 10–20 early users invited personally, not through a Product Hunt launch

Deliverable: Live product with real users. Full code and account ownership.

Why MVPs Stall (And How to Avoid It)

Scope expansion mid-build: A feature that "would only take a day" always takes a week. Lock the scope in phase 1. Do not unlock it.

Waiting for design perfection: Perfect design for zero users is a waste. Imperfect design that ships is not.

Building for the company you want to be, not the company you are: Multi-region infrastructure, microservices, enterprise SSO — none of this for your first 1,000 users.

Not talking to users until the product is "ready": Talk to users in week 2 with a prototype. Their feedback will save you weeks of building the wrong thing.

What Happens After Launch

You have a live product with real users. Now the real work begins.

For the first 30 days:

• Talk to every user who signs up. Learn why they chose you and what's missing.
• Watch session recordings. You will be surprised by how real people use your product — it won't match what you expected.
• Measure one metric: are people completing the core action? If yes, double down. If no, diagnose and change one thing at a time.

The MVP is not the end product. It's the start of learning.

If you're a founder scoping your first build, talk to us. We'll tell you honestly what can ship in your timeline — and what should wait.