MVP development: what to build first (and what to leave out)
"MVP" gets thrown around so much it has almost lost its meaning. People hear "minimum viable product" and picture a cheap, half-finished thing. That is not it at all.
An MVP is the smallest version of your idea that lets a real person do a real task and tell you whether it was worth it. The word "viable" matters. It has to actually work. It just does not have to do much.
The one-sentence test
Try to finish this sentence: "A [type of person] can [do one specific thing] in [short amount of time]."
For example: "A clinic receptionist can book and confirm an appointment in under a minute." Or: "A buyer can reorder last month's stock with two clicks."
If you cannot write one clear sentence, the idea is still too fuzzy to build. Spend another week talking to potential users before you spend money on code.
Pick the painful path
Every product has a hundred possible features. Only one path through them is why anyone would use it in the first place. Find that path and build only it.
Everything else goes on a list. Dashboards, settings pages, notification preferences, dark mode, the admin panel with fourteen filters. Most of it will wait.
A useful way to sort things:
- Must have: the product is pointless without it.
- Should have: people will complain, but they will still use it.
- Nice to have: you thought of it in the shower.
Build the first group. Be strict about it. The second group is for version two, once you know which of them people actually ask for.
What you can fake at the start
Not everything has to be automated on day one. Some of the smartest early products had a person quietly doing the work behind the scenes.
- Instead of building an invoice engine, you send invoices by hand for the first ten customers.
- Instead of an admin dashboard, you read the database directly.
- Instead of a recommendation algorithm, you pick the recommendations yourself.
This feels like cheating. It is not. It teaches you what the automation should actually do, and it saves you from building the wrong thing well.
Where not to cut corners
Some things should be solid even in a first version:
- Security and sign-in. If you hold customer data, protect it from day one. We cover the basics in data security for custom business software.
- Payments. If money changes hands, it has to be correct. Adding payments is worth doing carefully.
- The core flow. The one path your idea is built on must feel good. A clumsy core kills the product, however many extras you add.
Feature creep is a people problem
It rarely comes from bad intentions. A stakeholder sees the build, thinks of something useful, and asks for "just one small thing." Then another. Each is reasonable on its own. Together they push the launch date back by months.
A few habits help:
- Keep a visible "later" list, and add to it freely. People relax when their idea has somewhere to go.
- Ask "what would we drop to fit this in?" every time something is added.
- Set a launch date and treat it as a real one.
Launch to a small group
Do not aim for the whole market. Get it into the hands of five to twenty people who actually have the problem, and watch them use it. You will learn more from one afternoon of watching someone struggle than from a month of planning.
Listen for what they ignore as much as what they ask for. A feature nobody touches is a feature you can stop worrying about.
What "done" looks like
An MVP is finished when it can answer a question you actually care about. "Will people pay for this?" "Does this save the team an hour a day?" "Will customers come back?" Define the question first, then build just enough to get the answer.
After that, you either improve it, change it, or drop it. All three are good outcomes, because you got there for a fraction of what a full build would have cost.
An example of cutting a first version down
Suppose you want to build an online platform where small food producers sell to local restaurants. The wish list grows fast: producer profiles, a product catalog, ordering, delivery scheduling, invoicing, reviews, a mobile app, analytics for both sides, and a messaging system.
Run it through the one-sentence test: "A restaurant buyer can reorder this week's produce from a local supplier in a couple of minutes." That is the core.
What does that require at minimum?
- A way for a producer to list what is available this week.
- A way for a buyer to see it and place an order.
- A way for the producer to see incoming orders.
Everything else can start as a manual process. Invoicing can be done by hand from the order list. Delivery can be arranged by phone. Reviews and messaging can wait until people ask. The mobile app can be a web page that works well on a phone.
The result is a product you could build in a fraction of the time, put in front of ten real producers and buyers, and learn from. If restaurants do not reorder, you have spared yourself months of work on the rest. If they do, you know exactly what to add next because they will tell you.
How to know you cut the right things
A few checks help:
- Could someone still complete the main task? If yes, you have not cut too deep.
- Would you be embarrassed to show it to a real customer? A rough edge is fine; a broken core is not.
- Is each remaining feature required by the one-sentence goal? If you cannot link it back, it is a candidate to drop.
- Can you describe what you are deliberately leaving out? If not, you have not decided; you have just not thought of it yet.
Mistakes with MVPs
Some patterns we see again and again:
Calling it an MVP while building everything. If the plan has thirty features and takes a year, it is not an MVP, no matter what the document says.
Building the MVP as throwaway. Cutting scope is good. Cutting quality in the core is not. Code that is meant to be replaced rarely gets replaced, so keep the foundations sound.
Launching without a way to learn. If you cannot tell who used what, or ask people what they thought, you have shipped a product without getting the main benefit of an MVP. Even basic usage tracking and a feedback email address matter.
Treating feedback as orders. Listen to everyone, but build for patterns. One customer asking for a feature is a data point. Five asking for the same thing is a signal.
After the first release
The days following launch are the most valuable. Talk to your early users, watch what they do, and keep a running list of what you hear. Group it into themes: things that confused people, things people wanted, and things nobody touched.
Then choose the next small release. Your first version should not be the last decision you make about the product; it should be the first of many informed ones. That rhythm of building a little, learning, and adjusting is the reason the approach works.
Setting a deadline that helps
An MVP without a date tends to expand. Pick a launch date and treat it as fixed, then decide what fits before it, instead of deciding what you want and letting the date slide.
A good length is short enough to feel urgent and long enough to build something real. For most small products that means a matter of weeks to a few months, not a year. When the date approaches and something is not ready, cut it or simplify it. The discipline of shipping on time teaches you far more than another round of polishing would.
Thinking about a first version of your own? Tell us the one-sentence version and we will help you work out what belongs in it.
