Noah Labhart logoNoah Labhart

Guide

MVP development: how to build the right first version

An MVP is the smallest thing that lets a real user complete a real job and lets you learn something you cannot learn by asking. Scope it to one workflow, one user type and one measurable outcome, and aim to have it in front of customers in eight to twelve weeks.

7 min read · Updated 2026-08-06

What should an MVP include?

One complete workflow for one type of user, end to end, with nothing decorative around it. If a feature does not sit on the path between the user's problem and their outcome, it is version two.

  • The single job the customer is hiring your product to do.
  • Enough authentication and data protection to be honest with a real customer.
  • A way to observe what users actually did — analytics and error reporting.
  • A manual back door: humans can do the hard part behind the scenes at first.

What can you safely leave out of an MVP?

Most of the admin surface, most configuration, and nearly all generality. Manual work performed by your team is a legitimate substitute for software until the volume proves the feature is worth building.

Commonly built too earlyDo this instead
Admin dashboardQuery the database directly for the first weeks
Self-serve billingInvoice manually until you have ten paying customers
Roles and permissionsOne role, until a customer needs a second
Native mobile appsResponsive web, unless mobile is the product
Integrations marketplaceTwo integrations that specific customers named
Multi-tenancy at scaleCorrect data isolation, simple implementation

How long should an MVP take to build?

Eight to twelve weeks with two to four engineers is a realistic target for most software products. If the plan is longer than a quarter, the scope is a version one, not a minimum viable product.

Timebox first, scope second. Fix the date and negotiate what fits inside it; the reverse — fixing the scope and negotiating the date — is how MVPs turn into eighteen-month projects.

Which MVP shortcuts create real technical debt?

Shortcuts in the interface, in generality and in automation are cheap. Shortcuts in the data model, in access control and in anything touching money or personal data are expensive and sometimes unrecoverable.

  1. Safe: hardcode configuration, skip admin tooling, defer performance work, use managed services generously.
  2. Risky: an incoherent data model, no migration path, no tests around money.
  3. Never: storing credentials or personal data carelessly, or skipping backups.

How do you know the MVP is done?

It is done when a user outside your company completes the core workflow without you in the room, and you can see whether it worked. Not when the backlog is empty — the backlog is never empty.

Frequently asked questions

How much does it cost to build an MVP?
With a small in-house team, a twelve-week MVP typically costs the equivalent of two to four engineer-quarters. Agency pricing for comparable scope commonly lands between $60k and $200k depending on domain complexity.
Should a founder outsource MVP development?
It can work when the scope is well understood and someone technical on your side owns the architecture decisions. Without that, you inherit a codebase nobody can extend.
What is the difference between an MVP and a prototype?
A prototype answers a design or feasibility question and can be thrown away. An MVP is used by real customers to do real work, so it needs real data handling and real reliability.

From the podcast

Founders who lived this

Code Story episodes where founders work through the same problem in their own words.

More on founder lessonsMore on marketplaces

Keep reading

Related guides

How to choose a tech stack for a startup

A decision framework for choosing a startup tech stack: what actually matters, which choices are reversible, and how to avoid the rewrite that eats your Series A.

Build vs buy: a decision framework for technical leaders

When to build software in-house and when to buy it: a build vs buy framework covering total cost of ownership, differentiation, switching costs and vendor risk.

Managing technical debt without stopping the roadmap

How to identify, quantify and pay down technical debt at a startup without freezing the roadmap — including how to explain the trade-off to non-technical stakeholders.

All guides