How to launch an MVP: scope, timeline and what to cut

To launch an MVP (minimum viable product), pick one user, one problem and one path through your product, build only what that path needs, and put it in front of real people in weeks, not months. Everything else waits until the data tells you it's worth building. That's the whole trick. The hard part is sticking to it when the feature list gets exciting.

This guide walks through scoping, timelines, the tech choice and a cutting list you can use in your next planning meeting.

#What an MVP is (and what it isn't)

An MVP is the smallest version of your product that lets you learn whether people actually want it. It's not a cheap version of the final product, and it's not a demo with fake buttons. It has to work for real users, just for a narrow job.

A useful way to think about it:

• Minimum — only what's needed to deliver the core value once, end to end.
• Viable — good enough that a real person can use it without you standing next to them.
• Product — people can find it, sign up, use it and (ideally) pay for it.

What an MVP is not: a pitch deck, a Figma prototype (that's a great step before the MVP), or "version 1.0 with everything we could think of, minus the polish".

#Step 1: Define the core loop of your MVP

Before writing a single screen, write one sentence:

[User] wants to [do X] so that [outcome]. Today they solve it by [workaround].

Then describe the core loop — the steps a user takes from arriving to getting value. For a booking app in Chișinău that might be: open the site → pick a service → pick a time → confirm → get a reminder. Five steps. Anything that isn't one of those steps is a candidate for cutting.

If you can't describe the loop in five to seven steps, the scope is probably still too wide. Narrow the audience ("salons in one city" instead of "all service businesses") until it fits.

#Step 2: Scope with MoSCoW

Put every feature idea into one of four buckets:

Build only the Must column for launch. Be honest here — founders tend to sneak "Should" items into "Must". A good test: would a user refuse to use the product without this? If not, it moves down.

#Step 3: Cut smart — what usually goes first

These features eat a lot of time and rarely decide whether an MVP succeeds:

• Admin panels. Early on, a spreadsheet, Airtable or the database UI is often enough. You can build a proper admin later.
• Complex roles and permissions. Start with "user" and "admin".
• Multiple languages. Launch in the language of your first audience. For Moldova that's often RO or RU first — the other can follow once you see traction (plan the structure for it, though).
• Social logins everywhere. Email or one provider is plenty.
• Custom analytics dashboards. Use a standard analytics tool.
• Payments automation. If volumes are low, invoices or a simple payment link can work at first.
• Both mobile stores on day one. A PWA or a responsive web app often validates the idea faster — see PWA vs React Native.

What you should not cut: basic security, data backups, a working signup, clear error messages and the ability to contact you. Users forgive missing features; they don't forgive losing their data.

#Step 4: Choose the right build approach

The tech choice should follow the scope, not the other way round.

A "concierge MVP" — where you do the work manually behind a simple landing page — is underrated. If nobody signs up for the manual version, the automated one won't save it.

#Step 5: A realistic MVP timeline

Timelines depend on scope, but the phases are always similar:

1. Discovery (about 1 week). Core loop, MoSCoW list, user flow, a short project brief.
2. Design (1–2 weeks). Wireframes of the core screens, then UI for those screens only.
3. Build (a few weeks). Usually the longest phase. Weekly demos keep everyone honest.
4. Test (about 1 week). Real devices, real data, a handful of real users.
5. Launch and learn (ongoing). Release, watch what people actually do, talk to them.

A tightly scoped MVP typically lands somewhere between a few weeks and a few months. If an estimate grows past that, it's usually a scope problem, not a speed problem.

#Step 6: Decide what "success" means before launch

Pick two or three signals you'll check after launch — otherwise every result looks like "kinda promising". Examples:

• How many visitors complete the core loop at least once.
• How many come back and do it again within a week or two.
• How many say yes when you ask them to pay (or pre-order).

Set the thresholds before you see the numbers. Then talk to users — five honest conversations often teach more than a dashboard.

#MVP launch checklist

• One-sentence problem statement written down
• Core loop of 5–7 steps
• Only "Must" features in the launch scope
• Build approach chosen (no-code, web/PWA or app)
• Analytics and error tracking set up
• Privacy policy and basic terms published
• Backups and basic security in place
• Feedback channel (form, chat or email) visible
• Success signals and thresholds agreed
• List of "next" features parked — not deleted

#FAQ

#How long does it take to build an MVP?

For a focused scope, usually from a few weeks to a few months. No-code and PWA MVPs tend to be on the faster end; apps for both stores take longer because of testing and store review.

#Should my MVP be a website or a mobile app?

Start with where your users already are and what the core loop needs. If it doesn't require push, background tasks or device hardware, a web app or PWA is often the faster and cheaper way to validate.

#What's the difference between a prototype and an MVP?

A prototype shows how the product might work — it's for testing ideas and usability. An MVP actually works for real users, with real data, so you can test demand and behavior.

#Can the MVP code be reused later?

Often, yes — especially if it's built with a clean API and a mainstream stack. Some parts will be rewritten as you grow, and that's normal. The goal of an MVP is learning, not perfect code.

#Ready to scope yours?

The fastest way to get an honest scope is to write it down. Open the project builder, pick the type (website, PWA or mobile app) and the must-have features — you'll get an estimate and a clear starting point. Want to talk it through first? See how I build apps and websites.