MVP Development: How to Scope, Build and Ship an MVP

An MVP is the smallest product that lets one specific user complete one valuable job end to end, built so you can measure whether they come back. Scope it to one persona, one workflow and one success metric, build it in weeks on boring managed infrastructure, and keep the few things that are expensive to retrofit (authorization, the data model, migrations, backups and error tracking) production-grade from the first day. Everything else is allowed to be rough.

Key takeaways

• An MVP exists to test your riskiest assumption. Name the assumption before you name a single feature.
• One persona, one workflow, one metric. If the product brief does not fit on one page, the scope is too big.
• Some things are cheap now and expensive later: authorization, tenancy, migrations, backups, payment webhooks and email deliverability. Get those right and let the rest be rough.
• Ship in vertical slices, so there is always something a real user can try.
• Write down, before launch, which result means continue, narrow or change direction.
• AI coding tools produce demos quickly and skip the boring safety work. Audit authorization, secrets and data access before real users arrive.

MVP, prototype or proof of concept?

These words get used interchangeably, and the confusion causes real waste: teams build a throwaway prototype with production effort, or put a proof of concept in front of paying customers.

A concierge MVP deserves more use than it gets. If the risky question is whether people want the outcome, deliver the outcome by hand to a few customers before writing the software that automates it.

Step 1: name the riskiest assumption

Every new product rests on assumptions of four kinds:

• Desirability: the user has this problem and wants it solved.
• Viability: they, or their company, will pay enough for the solution.
• Usability: they can figure out how to get the value.
• Feasibility: you can actually build it, for example an AI feature that needs a certain accuracy on messy real data.

Pick the one that would kill the business if it were wrong, and design the MVP to test it. If feasibility is the risk, build a proof of concept against real data first; there is no point polishing a workflow around a model that does not work.

Talk to users before building, and keep talking. Ask about what they did last time the problem came up, not what they would do with a hypothetical product. Rob Fitzpatrick's The Mom Test is the best short guide to asking questions that people cannot answer politely. Stop scheduling discovery interviews when you stop hearing new problems, not at a magic number.

Then write the brief. One page, no exceptions:

## Product brief: Stockroom
 
User: Owners of independent cafes with one to three locations who track
inventory on paper or in a spreadsheet.
 
Problem (their words): "I find out we're out of oat milk when a customer orders it."
 
Current workaround: Weekly paper count, a group chat with suppliers.
 
Riskiest assumption: Owners will do a stock count on a phone every week if it
takes under ten minutes.
 
The one workflow: Count stock on a phone, see what is running low, send an
order to the supplier.
 
Success metric: Share of activated cafes that complete a count in at least
three separate weeks of their first five.
 
Decision date: Six weeks after the first cafe is onboarded.
 
Out of scope: Multi-location reporting, POS integration, recipes, accounting export.

The example is illustrative. The structure is the point: a named user, their words, one assumption, one workflow, one metric with a date attached.

Step 2: scope with a cut list

Map the one workflow from signup to the moment of value, then decide for each area what ships, what you fake and what waits.

If the build plan for what remains needs more than about ten weeks for a small team, cut again. Scope that does not hurt to cut was not scope.

Step 3: the things that are expensive to retrofit

This is where MVP advice usually goes wrong. "Move fast" is right for features and wrong for a short list of foundations, because these are expensive or impossible to fix once real users and real data exist.

And the list of things you can safely leave rough: visual polish beyond clean and usable, the admin UI, performance beyond "fast enough for the first hundred users", infrastructure as code on a PaaS, and any architecture more elaborate than a monolith.

Authorization deserves one concrete example, because it is the most common serious bug in early products. Route every tenant-data query through something that cannot forget the tenant:

// Every query for tenant data goes through a repository scoped to the session.
export function projectsFor(session: Session) {
  return {
    list: () =>
      db.query("select * from projects where org_id = $1 order by created_at desc", [session.orgId]),
    get: (id: string) =>
      db.query("select * from projects where org_id = $1 and id = $2", [session.orgId, id]),
  };
}

Then prove it with a test that tries to cross the boundary:

test("a user cannot read another organization's project", async () => {
  const other = await createProject({ orgId: "org_b" });
  const res = await api.as(userInOrgA).get(`/api/projects/${other.id}`);
  expect(res.status).toBe(404);
});

If your stack lets the browser query the database directly, as some backend-as-a-service platforms do, row-level security must be enabled with correct policies on every exposed table. Without it, anyone with the public key can read everything.

Step 4: pick a boring foundation

Use technology the team already ships in: a mainstream framework, managed PostgreSQL, a managed authentication provider, a PaaS that deploys on merge, an error tracker and a product analytics tool. Our guide to choosing a startup tech stack covers the decision in detail, and the startup infrastructure checklist lists the setup steps in order.

Three things not to do in an MVP: write your own authentication, split into microservices, or run Kubernetes. Each costs weeks you should be spending with users.

Step 5: a week-by-week build plan

An illustrative plan for a small team and a well-cut scope:

Work in vertical slices: one thin path through UI, API and database, deployed, then the next. Building all the backend before any frontend means nobody can try anything until the end, which is exactly when you can least afford surprises.

Step 6: instrument the success metric

Track only the events your decision depends on, with consistent names and the user and organization on every event. Our growth engineering guide covers event taxonomy and identity stitching in more depth.

Weekly cohort retention is the single most useful chart for an MVP. This query counts, for each signup week, how many users completed the core action in each following week:

with cohorts as (
  select user_id, date_trunc('week', min(occurred_at)) as cohort_week
  from events
  where name = 'account_created'
  group by user_id
),
activity as (
  select distinct user_id, date_trunc('week', occurred_at) as active_week
  from events
  where name = 'core_action_completed'
)
select c.cohort_week,
       extract(day from a.active_week - c.cohort_week)::int / 7 as week_number,
       count(distinct a.user_id) as active_users
from cohorts c
join activity a on a.user_id = c.user_id and a.active_week >= c.cohort_week
group by 1, 2
order by 1, 2;

What you are looking for is a curve that flattens. If usage keeps falling toward zero week after week, users tried the product and left. If it levels off, some group of users found lasting value, and your next job is to find out who they are.

Step 7: the launch checklist

• Authorization tests for cross-tenant access pass in CI
• Point-in-time recovery is on, and one restore has been performed
• Error tracking receives errors from both frontend and backend
• An uptime check on the login page and the core API alerts someone's phone
• Sign-up, login, password reset and any endpoint that calls a paid API (LLM, SMS) are rate limited
• Budget alerts and hard spending caps are set on cloud and LLM provider accounts
• No secret keys in the client bundle
• Password reset emails arrive in the inbox, not spam
• A privacy policy, terms, and a working way to delete an account and its data
• Production data access is limited to named people and logged
• A rollback has been performed on a real deploy
• Users have a way to reach the team that someone actually reads

A quick check for leaked keys in the built frontend (adjust the paths for your framework):

grep -rEn "sk_live_|sk-[A-Za-z0-9_-]{20,}|AKIA[0-9A-Z]{16}" .next/static dist build 2>/dev/null

Step 8: decide with thresholds you set in advance

Before launch, write down what result means what. "If at least a set share of activated cafes count stock in three of their first five weeks, we continue" is a decision rule. "We'll see how it goes" is how teams spend a year on a product nobody returns to.

Sean Ellis's product-market fit survey is a useful complement once you have enough active users: ask how they would feel if they could no longer use the product, and watch the share who answer "very disappointed". His often-quoted threshold is 40%. Treat it as a heuristic, and only with enough respondents to mean something.

At the decision date, there are three honest outcomes:

1. Continue. Users return without prompting and ask for more. Plan v1 around what your retained users do most.
2. Narrow. One segment retains and the rest churn. Rewrite the brief for that segment and cut everything else.
3. Change direction. Weak retention across the board. Decide whether to keep the problem and change the solution, or keep the users and change the problem.

AI-built MVPs: check these before real users arrive

AI coding tools can produce a convincing MVP in days. The demo works. What tends to be missing is everything a demo does not exercise, and the gaps are consistent:

• Authorization in the UI only. The page hides other users' records, but the API returns any record by ID.
• A database open to the browser. Row-level security disabled, or policies that allow everything.
• Secrets in the client or the repository. Service keys in frontend code or a committed .env.
• No migrations. The schema was edited in a dashboard and exists nowhere in code.
• Unverified webhooks. Payment handlers that trust any request that reaches them.
• Unbounded paid API calls. No rate limits or budget caps, so one user, or one bot, can run up the LLM bill.
• Swallowed errors. Exceptions caught and ignored, so failures are invisible until users complain.

None of these are hard to fix before launch. All of them are painful after an incident.

Common MVP mistakes

Overbuilding the platform. Microservices, Kubernetes and multi-region before the first user. Every hour there is an hour not spent with customers.

Underbuilding the foundations. The opposite mistake, and the more dangerous one: skipping authorization tests, backups or migrations because "it's just an MVP". Real users bring real data, and that data does not care what you called the release.

Building for everyone. Adding features for a second and third persona before the first one retains. Each addition dilutes the test.

Treating launch as the finish line. Nobody is assigned to watch the metric or talk to users in the weeks after launch, which is the only period the MVP was built for.

Never paying down the shortcuts. The MVP succeeds and quietly becomes v1 with every shortcut intact. Write the shortcuts down as you take them; our guide to technical debt management covers deciding which to pay first.

Frequently Asked Questions

How long does it take to build an MVP?

A well-scoped software MVP that covers one workflow for one type of user usually takes a small team a matter of weeks, not months. If your plan needs much more than about ten weeks, the scope is probably too broad and should be cut. Time spent with users after launch matters more than a few extra weeks of building.

What should an MVP include?

An MVP should include one complete workflow that delivers real value to one specific type of user, plus the instrumentation to measure whether they come back. It also needs the foundations that are expensive to add later: server-side authorization, a sound data model, migrations, backups, error tracking and secure handling of secrets. Admin tools, polish and secondary features can wait.

What is the difference between an MVP and a prototype?

A prototype tests whether users understand and want a flow, usually with sample data, and is thrown away afterwards. An MVP is used by real customers with real data to test whether they adopt the product and return, and it typically evolves into the first version. Because an MVP holds real data, it needs real security and backups.

Can you build an MVP with AI coding tools?

Yes, and they make the first version much faster to produce. The risk is that generated code covers what a demo exercises and skips what it does not, such as server-side authorization, row-level security, secret handling, migrations and rate limits on paid APIs. Review those areas deliberately before real users and their data arrive.

How do you know if an MVP is successful?

Decide before launch which metric and threshold mean success, usually a retention measure such as the share of activated users who complete the core action in several separate weeks. A retention curve that flattens instead of falling to zero is the strongest early signal. Qualitative evidence matters too: users who ask for more, pay or bring colleagues.

Need help building or hardening an MVP?

We are senior engineers who build products and then run them: if we built it, we are on the pager. We can scope and build an MVP with production-grade foundations, or take an AI-built prototype and close the gaps in authorization, data safety and operations before your first customers find them.

• POC-to-production engineering
• Startup tech consulting
• Talk to an engineer