What to build first in an MVP

Build the one flow that solves your users' main problem from start to finish, and almost nothing else. An MVP (minimum viable product) exists to test whether people want what you are offering, so the first version needs the shortest path from "I have this problem" to "it is solved", plus the minimum around it to make that path safe and usable. Everything else can be done by hand, faked honestly, or postponed until real users ask for it.

#Start by naming the one problem

Most MVPs grow too large because the problem behind them was never written down in one sentence. Before listing features, write a statement in this form: "[Who] needs to [do what], and today they [do it badly in this way]." For example: "Small gyms need to take class bookings online, and today they take them by phone and lose track of who is coming."

That sentence becomes the filter for every feature request. If a feature does not help that person do that thing, it does not belong in the first version. A clear problem also tells you who to test with, which is half the value of an MVP.

A quick check: if you cannot name ten real people or businesses who have this problem today, talk to potential users before you build anything. The cheapest MVP is a conversation that proves the idea wrong.

#Map the core flow

The core flow is the sequence of steps a user takes to get the main result. For the gym example it might be:

1. A member opens the schedule and sees available classes.
2. The member picks a class and books a spot.
3. The member receives a confirmation.
4. The gym sees who is booked for each class.
5. The member can cancel, and the spot becomes free.

Write the flow out step by step, then for each step ask what the simplest working version is. Perhaps confirmation is a plain email, the gym's view is a single list per class, and cancellation is a link in that email. Each step must work for real, because a broken step breaks the whole test.

Then add only what the flow cannot do without: accounts if users must return, payments if the test depends on people paying, and the basic security around both.

#What to leave out of the first version

These are the usual candidates for later. Each one costs real time, and none of them tells you whether the core idea works.

• A full admin panel. Early on, a simple list, a spreadsheet export or direct database access by the developer is often enough.
• Several user roles. Start with the two or three roles the core flow needs. Fine-grained permissions can come when real teams use the product.
• Social login, notifications in every channel, profile pages. Useful, but rarely the reason someone adopts a product.
• Every integration. Pick the one the flow depends on. Accounting exports and CRM syncs can wait.
• Native apps on both platforms. A responsive web app often tests the idea faster. Build a mobile app when the flow needs the phone itself: camera, location, push notifications or offline use.
• Edge cases that rarely happen. Handle them manually and write them down.

Keep a written list of what you left out and why. It stops the same discussions from returning every week, and it becomes your backlog once you have data.

#Fake doors and manual back offices

Two techniques let you test more of the idea without building it.

Fake doors

A fake door is a button or menu item for a feature that does not exist yet. When someone clicks it, they see an honest message such as "This is coming soon. Tell us how you would use it," with a short form or an email field. Counting the clicks tells you how much demand there is before you spend anything on the feature. Use the technique sparingly and never on anything people pay for, because a page full of dead ends damages trust.

Manual back offices

Many steps that look like software can be done by a person at first. Matching customers with providers, approving accounts, generating reports or issuing refunds can be handled by someone on your team using the admin list and email. Users get the result, you learn exactly how the process works, and you automate it only once you know the rules and the volume. This is often called a concierge or "Wizard of Oz" MVP.

The one rule: be honest with users about timing. If a step is done by hand, tell them when to expect the result.

#Decide how you will measure it before you launch

An MVP without measurement is just a small product. Before launch, write down the two or three signals that will tell you whether the idea works and what result would make you continue, change direction or stop.

• Completion of the core flow. How many people who start a booking finish it? Track each step as an event, so you can see where they drop off.
• Return use. Do people come back for a second booking or a second order? One use can be curiosity. Repeat use suggests real value.
• Willingness to pay. If the business depends on payment, test it early, even with a small price or a pre-order.
• Qualitative feedback. Talk to users. Five short calls often explain what the numbers only hint at.

Set up analytics with privacy in mind: collect only what you need, and respect consent rules where your users are. The targets themselves depend on your market, so decide them based on your own costs and goals rather than borrowing someone else's benchmarks.

#Build so the MVP can grow, without overbuilding

A minimal product should still be built properly in the places that are expensive to change later. Cutting features is fine. Cutting foundations creates a rewrite.

Get right from the start	Safe to keep simple
A clear data model for the core entities	Admin screens and reporting
Authentication through a well-tested framework or library	Visual polish beyond clean and usable
Database migrations kept in the code	Scaling across several servers
Automated tests on payments, login and data changes	Tests on every screen
Code, hosting and accounts in your name	Separate services or a microservice architecture
Backups and basic error logging	Advanced monitoring dashboards

Pick a mainstream, well-documented stack that many developers know, so you can grow the team or change it later. Avoid designing for millions of users before you have hundreds. A single well-built application on ordinary hosting can carry an MVP a long way, and it is far easier to change than a distributed system.

When you are ready to talk to developers, a short software project brief built around your problem statement and core flow will get you sharper estimates. If budget is the main question, our article on what drives the cost of a custom web application explains which choices move the number most.

#How PN Scripts can help

PN Scripts builds web applications and MVPs in any mainstream stack, starting from a written scope and estimate that you approve before work begins. You see a working demo every two to three weeks, so you can adjust the scope as you learn. If you have a problem statement and a core flow, see how we approach web development.