Process
The 6-Week MVP Playbook: A Day-by-Day Breakdown
Short answer
A 6-week MVP isn't magic - it's a process. Week 1: discovery, scope, contracts, repo setup. Weeks 2-4: core workflow shipped to staging incrementally. Week 5: polish, performance, edge cases. Week 6: production deploy, documentation, handoff. The founder's job is small but critical - make decisions fast, test often, never delay sign-off.
Published April 25, 2026 · Last updated April 25, 2026
Week 1: Discovery, scope, and setup
Day 1 - Discovery call (30 min). Founder explains the product, target user, and timeline. Developer asks questions, identifies risks, and proposes scope cuts. By end of call: a rough scope and a follow-up commitment.
Day 2-3 - Written quote. Developer sends a 1-page document: deliverables, timeline, fixed price, payment terms. Founder reviews, asks questions over async chat, signs.
Day 4 - Repo and infra setup. Developer creates the GitHub repo in the founder's organization, sets up Vercel/AWS deployment, configures the database, scaffolds the frontend. Founder sets up Stripe, domain, and other accounts in their own name.
Day 5 - Staging URL live. The founder has a clickable staging link by end of week 1. It shows scaffolding (auth screens, empty dashboard), not features. The point is to verify the deployment pipeline works before any features are written.
Week 2: Core workflow, part 1
The first half of the core user workflow gets built. Auth flow, primary data model, the first 1-2 user actions.
Founder's job: Test the staging URL daily. Click everything. Send a screenshot of anything that breaks or feels wrong. Don't wait for the weekly demo.
Common pitfall: Founder reviews staging once at end of week 2 and finds 5 things to change. Better: review daily, fix in 15 minutes when issues are fresh, not in 5 hours when they've compounded.
Communication norm: Daily async update from the developer with screenshots and links. Founder responds within hours, not days.
Week 3: Core workflow, part 2
The second half of the workflow ships. Remaining user actions, primary integrations (Stripe, email), the dashboard or main screen.
By end of week 3: A user could theoretically sign up, pay, and complete the core workflow on staging. Rough edges everywhere. Some buttons don't have hover states. Some error messages are placeholder text. That's fine.
Founder's job: Walk a real prospective user through the staging URL. Watch them stumble. Note where they got confused. These notes feed week 4-5.
Don't: Add features in week 3. Even if a user says "I really wish it had X." Save it for v2.
Week 4: Edge cases and integrations
The unsexy week. Edge cases that the happy path didn't surface. Email deliverability. Mobile responsiveness. Form validation. Empty states. Loading states. Error handling.
Founder's job: Stress-test on a real device. Try to break the product. Submit forms with bad data. Use it on a slow 3G connection. Use it on an iPhone SE screen. Find the rough edges before users do.
Communication norm: Decisions speed up. Every "should this error message say X or Y" question that takes 24 hours costs the team a feature later. Aim for same-hour decisions on this kind of thing.
Week 5: Polish, performance, and content
Polish: Animations, transitions, the design tweaks that turn "functional" into "feels good."
Performance: Lighthouse scores, lazy loading, image optimization. The real measure: time to first interaction on a 4G phone.
Content: Real copy in every screen. No more "Lorem ipsum." Every empty state, every error message, every onboarding tooltip gets real words. This is often the founder's biggest deliverable in week 5.
Founder's job: Write the copy. Even if you'll iterate later, real words now. Also: prepare launch assets (Twitter screenshots, Product Hunt copy, email to your list).
Week 6: Launch, docs, handoff
Day 1-2: Production deploy. The DNS gets pointed. Real users can sign up. Founder runs through the full workflow on prod once before announcing.
Day 3: Documentation - what's in the codebase, how to deploy, how to extend, where each major feature lives. Written so any competent developer could pick it up.
Day 4: Launch. Announcement on X/Twitter, Product Hunt, founder's network. Developer monitors error logs and support inbox.
Day 5-7: Hot fixes and small tweaks based on real user feedback. The 2-week post-launch support window has begun.
What can stretch a 6-week build to 8-10 weeks
Slow founder decisions. Every "let me think about it" delays 1-3 features. The biggest variance in MVP timelines isn't the developer's speed - it's the founder's response time.
Scope creep. Adding features mid-build. Always feels small ("just one more screen") but pushes the launch by 1-2 weeks per addition.
Unprepared accounts. If the founder hasn't set up Stripe, GitHub, or the domain by week 1, the developer can't ship to those accounts. Set everything up in week 1.
Design ambiguity. No designs, no inspiration screenshots, no clear preferences. The developer makes design decisions that the founder later wants to change. Either provide designs or commit to the developer's choices.
What founders should do BEFORE week 1
Talk to 5 users. Real conversations. Use their words in the spec.
Write the spec. One page. Six questions. (See: MVP spec template.)
Get designs. Even rough wireframes or screenshots from inspiration products.
Set up your accounts. Domain, Stripe, GitHub organization, email provider. The developer needs admin access on day 1.
Pick a launch date. 6 weeks from kickoff, in writing, immutable. This is the most powerful constraint you'll set.