Guide

Planning a first release: build the smallest thing that proves the idea.

The most expensive mistake in software is building a lot of the wrong thing. A well-planned first release — often called an MVP, or minimum viable product — is how you avoid it. It is not a cheap, rough version. It is a small, solid one that answers your biggest question.

Key takeaways

Start with one job for one kind of user, and do it well.
A first release should answer a specific question, such as "will customers book this way?"
Cut features, not quality. Small and reliable beats large and shaky.
Decide in advance what success looks like and when you will review it.
Keep a visible list of what waits, so nothing is forgotten and nothing sneaks in.

Step 1: find the core job

Finish this sentence: "Our product helps [who] do [what], so that [benefit]." If you need "and" more than once, you probably have several products. Choose the one that matters most. Everything in version one should serve that sentence.

Step 2: list everything, then sort it

Write down every feature you or your team can think of. Then sort each into one of three groups:

Must have: without it the core job cannot be done.
Should have: valuable, but the product works without it for now.
Later: a good idea that belongs after you have learned from real use.

Be hard on "must have". A useful test: if you launched without it, could a customer still complete the core job? If yes, it is not a must.

Step 3: be clear about what can be manual

Not everything needs to be automated at the start. A booking product might begin with a human confirming each booking by message; an approval flow might send a simple email. Doing something by hand for the first fifty customers teaches you what to automate properly — and costs far less than guessing.

Keep honest about the trade-off: manual steps need staff time, so they suit low volume.

What should not be cut

Reliability of the core flow. If the one thing it does fails, nothing else matters.
Security and privacy basics. Protecting people's data is not a later feature.
A clear, usable screen for the main task, on the devices your customers actually use.
A way to measure and to hear from users, so the release can teach you something.
The language people need. If your customers use English and Chinese, both are part of the product.

Step 4: define success before you launch

Pick a few measures that answer your question, and a date to review them. Examples:

"Twenty of our existing customers make a booking through it within a month."
"Staff spend at least half as much time chasing documents."
"Seven in ten users who start the form finish it."

Numbers should be realistic for your size. If you cannot say what would count as success, you are not yet ready to build.

An illustration: a small tutoring centre

Imagine a centre that wants an app with bookings, payments, progress reports, a parent chat and a loyalty scheme. (An illustrative scenario, not a client.)

The core job: help parents see the timetable and request a make-up class. Version one is a web page with the timetable, a make-up request and a message when a class changes. Payments stay as they are for now; progress reports, chat and loyalty wait. After two months the centre knows how many parents use it, and which of the postponed ideas they actually ask for.

After the first release

Watch what people actually do, and ask a handful of them why.
Fix what blocks the core job first; then consider the "should have" list.
Reorder the "later" list based on evidence, not enthusiasm.
Plan the second release as deliberately as the first.

Keep reading

Frequently asked questions

Is an MVP the same as a prototype?

No. A prototype shows how something might work and is usually thrown away. A first release is real software that real people use, built to be extended.

How long should a first release take?

Often a few weeks to a few months. If it needs much longer, the scope is probably too large to teach you anything early.

Won't customers be disappointed by a small product?

Not if it does the main job well. People usually forgive a missing feature far sooner than something that breaks.

Not sure what belongs in version one?

Send us your idea. We will help you find the core job and a first release worth building.

Request a project quote