How to Build an MVP in 2 Weeks as a Solo Developer

Two weeks is a real constraint. It forces decisions that most developers avoid: what to cut, what to copy, and what to ship before it is perfect. Building fast is not about cutting corners — it is about cutting scope aggressively and moving without second-guessing every decision.

Here is how to actually do it.

Day 1: Define the One Thing

Before writing any code, answer this question in one sentence: "My MVP lets [specific user] do [specific action] so they can [specific outcome]."

This is your scope boundary. Every feature that does not directly enable this sentence gets cut. Not deferred — cut. If it is not in the sentence, it is not in the MVP.

Common scope failures that kill two-week MVPs:

• User roles. If the first version has one user type, do not build permissions and admin panels.
• Settings panels. Configuration UIs take twice as long to build as the feature itself. Hardcode defaults and add settings in v2.
• Complex onboarding. One page with a single input that gets users to the core value. Not a multi-step wizard.
• Dashboard analytics. Not in the MVP. Ship the product.

Cut until it hurts, then cut more. The goal is a product one person can use to accomplish one thing.

Day 1-2: Boilerplate Decision

Do not build from scratch. Starting from a boilerplate or template saves 2-3 days of setup.

Good starting points:

• Next.js SaaS starters: several open-source templates include auth, billing, and a database schema (Shipfast, Next.js Subscription Payments by Vercel, or build your own from a clean Next.js + Supabase starter)
• T3 Stack: Next.js + TypeScript + Prisma + tRPC — well-maintained and opinionated
• shadcn/ui: for UI components — copy-paste components directly into your project. Do not build UI from scratch

The rule: use any boilerplate that handles auth and basic routing. Everything else you will write.

Day 2-3: Database Schema

Design the minimal schema. For a two-week MVP:

• One table per core entity (usually 3-5 tables)
• No premature normalisation
• No polymorphic relationships
• Timestamps on every table (created_at, updated_at)

Write it down as a schema before creating tables. Review it once. Then create the tables and move on.

Day 3-8: The Core Feature

This is where you spend most of your time. Build the thing in the sentence you wrote on Day 1.

Use AI coding tools aggressively. Cursor, GitHub Copilot, or Claude for code generation. The correct workflow:

1. Write a clear comment describing what you want
2. Generate the first draft with AI
3. Review and fix what is wrong
4. Move on

Do not perfect the generated code. Make it work, then make it not embarrassing, then ship. Refactor in v2 when you have users.

Areas where AI tools save the most time:

• Boilerplate route handlers and API endpoints
• Form validation logic
• TypeScript types from an existing schema
• SQL queries from plain English descriptions

Day 8-10: UI Polish (The Minimum)

Functional but not ugly. The bar is:

• Consistent font and colour throughout
• No obvious alignment issues on desktop
• The primary CTA is visually obvious on every page
• Error states are handled (empty states, loading states, form errors)

Use shadcn/ui for all components. Do not custom-build buttons, modals, or form inputs. The time saved here funds the next feature.

Mobile responsiveness: test it, but do not obsess over pixel-perfect mobile if your target user is on desktop. Mark mobile polish as a v1.1 task.

Day 10-12: Auth and Payments

If your MVP needs auth (most do), use Supabase Auth or Clerk. Do not build custom authentication. This is the most common time sink in early-stage development.

For payments: if your MVP needs payments, integrate Polar.sh or Stripe with a pre-built integration. Do not build custom billing logic. Webhooks, status updates, and retry logic take days to get right.

If your MVP does not need payments in the first version, skip it and add it in v2 when a user asks.

Day 12-13: Error Handling and Monitoring

Add Sentry in one line. Configure it to capture uncaught exceptions.

Write meaningful error messages for user-facing errors. "Something went wrong" is not acceptable — tell the user what to do next.

Test the critical path manually from a fresh browser session with no session data, cookies, or existing accounts.

Day 14: Ship and Get One User

Deploy. Do not wait until it is perfect.

Then do one thing: get one real person to use the product while you watch. Not a co-founder, not a family member — someone in your target audience.

Watch them use it without helping. Note every point where they hesitate, get confused, or take an unexpected action. That list is your v1.1 backlog.

If you cannot get one real user in week two, your distribution strategy is the problem — not the product. Getting the first user is as important as building the product.

The Mindset Shift

"Done" in two weeks does not mean polished. It means:

• The core flow works end-to-end
• Real users can use it without your help
• Errors do not leave users stranded

Everything else is v2.

---

Submit your product to LaunchBuff → — free listing + fortnightly tournament.