From Idea to MVP in Two Weeks

Speed is a feature

The longer your idea lives only in your head, the more assumptions you're making. Every day without user feedback is a day you might be building the wrong thing.

Two weeks is enough time to validate an idea. Not to build a perfect product. To build enough of a product to learn whether you're on the right track.

What to build (and what to skip)

The hardest part of an MVP isn't the building. It's the scoping. Here's how I think about it:

Build these

• The core value proposition. The one thing that makes your product worth trying.
• Authentication. Users need accounts (keep it simple: email + password or OAuth).
• The critical path. The shortest route from sign-up to delivering value.

Skip these (for now)

• Admin dashboards
• Email notifications
• Settings pages
• Multiple user roles
• Analytics beyond the basics

The two-week timeline

Here's how I structure a two-week MVP sprint:

Week 1: Foundation

• Days 1-2: Set up the project, database schema, and authentication
• Days 3-4: Build the core feature (the thing that delivers value)
• Day 5: Connect everything end-to-end

Week 2: Polish & Ship

• Days 6-7: Handle edge cases and error states
• Days 8-9: Make it look good enough (not perfect, good enough)
• Day 10: Deploy, test on real devices, fix critical bugs

The tech stack that makes this possible

I reach for the same stack on every MVP:

• Next.js. Full-stack in one framework.
• Supabase. Database, auth, and storage without the DevOps overhead.
• Tailwind CSS. Ship good-looking UIs fast.
• Vercel. Deploy in seconds.

This isn't about being trendy. It's about minimising the time between "I have an idea" and "people are using it."

The one rule that matters

If it doesn't help a user accomplish the core task, it doesn't go in the MVP.

Every feature you add extends the timeline and delays learning. Be ruthless about scope. You can always add more later, but you can't get back the weeks you spent building features nobody wanted.