MVP Development: What to Build, What to Skip, and When to Scale

The MVP Paradox

Two types of MVPs fail:

1. The "M" without the "V" — a prototype so stripped down that nobody can tell if the product solves their problem. Users bounce because it feels broken, and you learn nothing useful.

2. The "V" without the "M" — a feature-complete product that took 9 months to build, launched to crickets, and now needs fundamental changes that require rewriting half the codebase.

The sweet spot is a product that is genuinely useful for one specific use case, built with architecture that can grow, and launched fast enough that you still have runway to iterate.

Step 1: Define the One Thing

Before any technical discussion, answer this question: What is the one thing this product does that no existing tool does well enough?

Not three things. Not "it's like X but with Y." One thing.

Examples from real MVPs we've built:

• "Match blood product availability across distribution centers in real time" — not "manage the entire blood supply chain"
• "Let patients check drug interactions before filling a prescription" — not "replace the pharmacy workflow"
• "Show construction teams real-time sensor data from tunnel infrastructure" — not "manage the entire construction project"

If you can't articulate the one thing in a single sentence, you don't have an MVP — you have a vision deck. Vision decks don't ship.

Step 2: Map the User Journey

Once you know the one thing, map the minimum user journey to deliver it. This is not a feature list — it's the sequence of steps a user takes from "I have a problem" to "this product solved it."

User Journey: Drug Interaction Checker

1. User enters/scans medication names        (Input)
2. System checks against interaction DB       (Core logic)
3. Results displayed with severity levels     (Output)
4. User saves check to their medication list  (Retention hook)

Everything that supports this journey goes in v1. Everything that doesn't, waits.

The "Must / Should / Could / Won't" Framework

For each potential feature, classify:

• Must have — the product literally doesn't work without this
• Should have — significantly improves the experience, add if time allows
• Could have — nice to have, but users won't notice it's missing
• Won't have (in v1) — explicitly deferred to v2+

| Feature | Classification | Reason | |---|---|---| | Drug interaction search | Must | Core value proposition | | User authentication | Must | Required for saving data | | Interaction severity levels | Must | Critical for usability | | Medication list | Should | Retention, but users can check individually | | Doctor sharing/export | Could | Useful but not for v1 validation | | Insurance integration | Won't | Complex, not needed to validate core hypothesis |

Step 3: Choose the Right Technical Stack

Your MVP stack should optimize for three things: speed of development, ease of iteration, and a clear upgrade path.

What We Recommend for Most MVPs

Frontend:  Next.js + TypeScript + Tailwind CSS
Backend:   Next.js API Routes (or separate Node.js/Express for complex APIs)
Database:  PostgreSQL + Prisma ORM
Auth:      NextAuth.js or Clerk
Hosting:   Vercel (frontend) + Railway or Render (backend/DB)
Payments:  Stripe

Why this stack:

• TypeScript end-to-end — fewer bugs, better DX, no context switching
• Next.js — handles SSR, API routes, and static pages in one framework
• PostgreSQL — scales from MVP to enterprise without switching databases
• Prisma — schema-as-code, easy migrations, type-safe queries
• Vercel — zero-config deployment, preview environments for every PR

Stack Anti-Patterns

Avoid these in MVPs:

• Microservices — you don't need them yet. A monolith is faster to build, deploy, and debug. Extract services when you hit a real scaling bottleneck, not before.
• Kubernetes — unless your team already runs K8s daily, the operational overhead will slow you down. Use managed platforms.
• Custom auth — building authentication from scratch takes 2–4 weeks and introduces security risks. Use a managed service.
• GraphQL — adds complexity without proportional value at the MVP stage. REST is simpler, faster to implement, and well understood by every developer.

Step 4: Architecture Decisions That Matter Early

Some decisions are easy to change later. Others are not. Spend your architecture time on the hard-to-change decisions:

Hard to Change Later

• Database schema design — schema migrations on production data are painful. Get the core entities and relationships right.
• Authentication model — switching auth providers mid-flight means migrating user sessions and credentials. Choose once.
• Multi-tenancy approach — single database with tenant IDs vs. separate databases per tenant. This affects every query and is expensive to change.
• API design conventions — REST endpoint patterns, pagination approach, error format. Inconsistency here compounds over time.

Easy to Change Later

• UI framework/component library — swapping from Material UI to shadcn/ui is a weekend project
• CSS approach — Tailwind to CSS Modules is mechanical refactoring
• Third-party integrations — behind an abstraction layer, swapping Stripe for Paddle is contained
• Hosting provider — with Docker, moving from Render to AWS is straightforward

Step 5: Build in Phases

Phase 1: Core Loop (Weeks 1–3)

Build the minimum path from input to output. No polish, no edge cases, no settings pages.

Week 1: Data model + API endpoints for core entity
Week 2: Frontend for the primary user flow
Week 3: Auth, basic error handling, deploy to staging

At the end of Phase 1, you should be able to demo the core value proposition in under 60 seconds.

Phase 2: Usable Product (Weeks 4–6)

Add the features that make Phase 1 usable by real humans:

Week 4: Error states, loading states, form validation
Week 5: "Should have" features from the MoSCoW framework
Week 6: Email notifications, basic settings, onboarding flow

Phase 3: Launch-Ready (Weeks 7–8)

Polish for launch:

Week 7: Landing page, payment integration, analytics
Week 8: Performance optimization, security review, load testing

Total: 8 weeks from kickoff to launch. This is realistic for a focused team of 2–3 engineers.

What to Skip in v1 (Really)

The following features are almost never needed in an MVP, despite feeling essential:

Admin Dashboard

Build a basic read-only admin view if you need it. Skip CRUD admin panels — use direct database tools (Prisma Studio, pgAdmin) until you have enough admin users to justify the investment.

Internationalization

Unless your target market is explicitly non-English, don't add i18n infrastructure in v1. It adds 20–30% to frontend development time.

Mobile App

Build a responsive web app. If your MVP validates the idea, build a native app for v2. React Native or Flutter lets you share logic from your web codebase.

Advanced Analytics

Google Analytics + a few custom events is enough for v1. You don't need Mixpanel funnels, cohort analysis, or A/B testing infrastructure until you have enough users to make the data meaningful.

Automated Testing (Mostly)

Controversial take: write tests for your core business logic (the drug interaction checker, the matching algorithm, the financial calculation). Skip E2E tests and UI tests in v1. You'll be changing the UI too fast for E2E tests to stay current.

When to Scale: The Decision Framework

You built the MVP. Users are signing up. Now what?

Signs You Need to Scale Architecture

• Response times exceeding 2 seconds at current load
• Database queries taking > 500ms for common operations
• Deployment takes > 30 minutes because the codebase has grown
• Two features can't be developed in parallel because they touch the same code

Signs You Need to Scale the Team

• Feature requests outnumber engineering capacity by 3x or more
• Bug backlog is growing faster than you're fixing bugs
• On-call incidents are happening weekly instead of monthly
• Technical debt is slowing feature development measurably

Scaling Doesn't Mean Microservices

The first scaling step is almost always:

1. Add a caching layer (Redis) for frequently read data
2. Move background jobs out of the request path (queue + workers)
3. Add a CDN for static assets and API caching
4. Optimize database queries (indexes, query rewriting, connection pooling)

These four changes handle 10–50x growth over your MVP traffic. You don't need Kubernetes until you're well past this point.

Cost Expectations

Based on our recent MVP projects:

| Component | Cost Range | Notes | |---|---|---| | Discovery & design | $10,000 – $20,000 | 1–2 weeks with UX designer | | Core development | $25,000 – $60,000 | 4–6 weeks, 1–2 engineers | | Launch prep | $5,000 – $15,000 | Landing page, analytics, polish | | Total MVP | $40,000 – $95,000 | 6–8 weeks | | Monthly maintenance | $2,000 – $5,000 | Hosting, monitoring, bug fixes |

The variance depends on complexity. A SaaS dashboard is on the lower end. A healthcare app with compliance requirements is on the higher end.

The Biggest Mistake

The biggest MVP mistake isn't technical. It's building for 6 months without talking to users.

Ship in 8 weeks. Get it in front of 10 real users. Watch them use it. Listen to what they say — and more importantly, watch what they do. Then decide what v2 looks like.

Every week you delay launch is a week of building on assumptions instead of evidence.

We help funded startups go from idea to launched MVP in 6–8 weeks. If you're planning your v1 and want an engineering partner who's done this 50+ times, let's talk.