The 4-Week MVP Playbook: What We Actually Do From Day 1 to Launch

"We need an MVP" is the most common thing we hear from founders. It's also the most misunderstood. An MVP isn't a bad version of your product. It's the smallest version that proves whether your idea works.

We've shipped dozens of MVPs. Some turned into funded startups. Some got killed after two weeks of user testing. Both outcomes are a success — because the founders learned fast and cheaply.

Here's exactly what we do, week by week.

Week 0: The Call Before the Clock Starts

Before any engagement begins, we have a single call. One hour, max. The goal isn't to understand every feature — it's to answer three questions:

1. What problem are you solving? Not "what do you want to build" — what's the actual pain point?
2. Who has this problem? Can you name five real people who would pay for a solution?
3. What's the one thing the MVP must do? Not ten things. One.

If a founder can't answer these clearly, we don't start building. We help them find the answers first.

Week 1: Discovery & Architecture

Days 1–2: Requirements Distillation

We take the founder's vision and reduce it to a concrete scope document. This includes:

• Core user journey — the one path that matters (e.g., "user signs up → creates a listing → receives a booking")
• Data model — Prisma schema draft with the essential entities
• Integration map — which third-party services are needed (payments, email, auth)
• Explicit non-goals — features we're deliberately not building yet

The non-goals list is the most important document. It prevents scope creep before it starts.

Days 3–5: Tech Setup & Architecture

We don't debate technology choices. Our stack is standardized:

Framework:    Next.js (App Router)
Language:     TypeScript (strict mode)
Database:     PostgreSQL
ORM:          Prisma
Auth:         better-auth
Styling:      Tailwind CSS
Deployment:   Vercel or Hetzner (depends on budget)

Standardizing the stack means we spend zero time on setup decisions and all our time on the product.

By Friday of week 1, we have:

• A deployed skeleton app (CI/CD working, staging environment live)
• Database schema migrated
• Authentication working
• A clickable wireframe of the core journey

Week 2: Core Feature Build

This is the sprint. We build the one user journey that defines the MVP.

What "Core" Means

For a marketplace: listing creation + discovery + booking. For a SaaS tool: onboarding + the primary workflow + output. For a platform: sign-up + the main interaction loop.

Everything else — settings pages, admin dashboards, notification preferences, profile editing — waits.

// Week 2 code is functional, not pretty.
// This is deliberate. Polish comes after validation.

// ✅ Week 2: works, proves the concept
export async function createListing(data: ListingInput) {
  return prisma.listing.create({
    data: {
      ...data,
      status: "ACTIVE",
      ownerId: getCurrentUserId(),
    },
  });
}

// ❌ Not week 2: optimized, abstracted, extensible
// That's week 8 — if we get there.

Daily Check-ins

We do a 15-minute async update every day. No standups, no ceremonies. A Loom video or a short message: what's done, what's blocked, what's next.

Week 3: Polish & Edge Cases

The core journey works. Now we make it not embarrassing.

What We Polish

• Error states — what happens when things go wrong (empty states, failed payments, network errors)
• Loading states — skeleton screens, not spinners
• Mobile responsiveness — most users will find your MVP on their phone
• Transactional emails — confirmation, welcome, receipt (plain text is fine)
• Basic analytics — PostHog or Plausible, just enough to know if people are using it

What We Don't Polish

• Animations and micro-interactions
• Dark mode
• Internationalization
• Performance optimization beyond the obvious
• Comprehensive test coverage (we write tests for critical paths only)

Week 4: Launch Prep & Deploy

Days 1–3: Testing & Bug Fixing

We do a structured walkthrough of every user path. Not automated tests — manual, deliberate testing as if we're a real user. We fix everything that blocks the core journey. We log everything else for later.

Days 4–5: Production Deploy

• DNS and domain setup
• SSL certificates
• Environment variables audited
• Error monitoring (Sentry) configured
• Database backups verified
• One final end-to-end test on production

By Friday, the MVP is live. Real users can use it. The founder can share a link, not a pitch deck.

What Happens After Week 4

This is where it gets interesting. The MVP is a hypothesis. Now you test it.

We typically recommend:

1. Get 10 real users in the first week. Not friends — people who have the problem you're solving.
2. Watch them use it. Session recordings (with consent) reveal more than any analytics dashboard.
3. Measure one metric. Conversion rate, retention, or activation — pick one.
4. Decide in 2 weeks. Either double down (fund a v1.1 sprint) or pivot/kill.

Why This Works

Speed isn't about writing code fast. It's about making decisions fast. Our process works because:

• No stack debates — the tech is decided before we start
• No scope creep — the non-goals list protects us
• No big reveals — the founder sees progress every day
• No perfection — good enough to validate, not good enough to admire

Four weeks. One journey. One answer: does this idea have legs?

That's what an MVP is for.

Want to build your MVP with us? Learn more about our MVP Development process, or book a free consultation.