MVP development: how to scope, build and launch a minimum viable product

Short answer: a minimum viable product is the smallest version of your product that real users can use and that tests your riskiest assumption. Its job is learning, not revenue. To build one well: write down the one assumption that could sink the idea, include only the features needed to test it, launch to a small group of real users, and measure a single number that tells you whether to continue, change course or stop.

What an MVP is — and what it is not

An MVP is not a cheap, broken version of the full product. It is a complete, usable product with a deliberately narrow scope. A booking app MVP might take bookings for one location with card payments only — but it should take them reliably. Users forgive missing features far more readily than bugs.

Step 1: write the hypothesis

Finish this sentence: “We believe [these people] will [do this] because [this problem], and we will know we are right when [this number] happens.” If you cannot finish it, you are not ready to build. Everything in the MVP should serve that sentence.

Step 2: cut the scope

List every feature you imagine, then sort them:

Build only the first column. Be ruthless with admin features: a spreadsheet, an email notification or a person doing it by hand is often enough for the first hundred users.

Step 3: choose how to build it

• No build at all: a landing page with a waiting list, or a manual “concierge” service, can test demand before any code.
• No-code or low-code: fast for internal tools and simple workflows, but plan the exit before you outgrow it.
• Custom build: right when the product itself is the differentiator, or when you need to own the code from day one. For mobile, a cross-platform framework keeps one codebase (see React Native vs Flutter).

Step 4: do not skip the boring parts

An MVP still needs a few things that are cheap at the start and painful later: analytics on the key actions, error and crash reporting, basic security, backups, and a privacy notice that matches what you collect (our privacy compliance guide covers the basics). Without measurement, you have launched something but learned nothing.

Step 5: launch small, on purpose

Launch to a group you can talk to: early customers, a waiting list, one city. Watch real sessions, read every support message, and call people who stopped using it. Twenty honest conversations are worth more than a big launch with no follow-up.

Step 6: decide with the number

Go back to the hypothesis. If the number moved, invest in the “should have” list. If it did not, change one thing and test again, or stop — stopping cheaply is a successful MVP outcome too.

How long and how much?

It depends on scope, which is the point of cutting it. A focused MVP is measured in weeks, not quarters. We start with a fixed-scope first sprint — a defined slice of work at a defined price — so the first release has a ceiling. Our guide to app development cost breaks down what moves the budget.

How we do it with our own products

We build our own software the same way. Dynamic QR and the AI SEO Platform both launched with a narrow first release and a written roadmap behind it, so real use — not guesswork — decides what gets built next.

Have an idea to test? Scoping an MVP is the first step in our software engineering work, with product design alongside. Tell us the assumption you need to test.