The kickoff meeting ran two hours and ended with 47 features on the whiteboard. "But this is just the MVP," the sales manager said, "the bare minimum to get started." Six months later the system was still in development, the budget was gone, and not a single customer had used it.
When a software development company hears "we want an MVP," the first thing worth asking is what the client wants to learn from that first version. The answer is almost never in the feature list. A well-scoped MVP (minimum viable product) is the first version of a piece of software that puts an idea in front of real users as soon as possible, so you can find out whether it deserves more investment. A badly scoped one is the full product under a different name.
This article covers how to narrow that MVP down: what goes in, what waits, how to measure it and what to do with what you learn. If you haven't written your requirements yet, start with how to put together a requirements brief for quotes. And if price is the worry, read what drives the cost of a custom application.
What an MVP is (and what it isn't)
Eric Ries popularized the term through the Lean Startup method. His definition, published by Lean Startup Co., says the MVP is the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort.
Notice the word "learning." You judge an MVP by the question it answers; the number of screens is beside the point. A few examples of those questions:
- Will field sales reps enter orders from their phones, or keep sending them over WhatsApp?
- Will customers use a self-service portal, or would they rather call?
- Does automatic dispatch calculation really cut the errors that come out of today's spreadsheet?
It isn't a clickable mockup either. A prototype helps you test a design with a handful of people in a room. An MVP works, handles real data and gets used by people doing their actual jobs. That's why it has to be stable and secure even when it's small. A system that crashes or loses data teaches you nothing about the idea, only that it was badly built.
What goes into the first version of your software
The most practical way to scope it is to pick one complete workflow, end to end, for one type of user. Instead of half-building an orders module, an inventory module and a reporting module, you build the whole path of a single order: it gets entered, approved, sent to the warehouse, and the customer gets a confirmation.
To sort everything else, put each feature into one of four buckets (the MoSCoW method, common in agile teams):
| Bucket | What it means | Example in an order system |
|---|---|---|
| Must have | Without it you can't test the idea | Enter an order, check stock, confirm to the customer |
| Should have | Matters, but there's a manual workaround for now | Volume discounts (approved by email in the meantime) |
| Could have | Nicer experience, doesn't change what you'll learn | Order history with filters |
| Won't have (yet) | Out of this version, by explicit agreement | Customer-facing app, CRM integration |
That last row is the hardest to write and the most useful. Putting in writing what the first version won't include keeps scope from growing one meeting at a time.
Some things shouldn't be cut even on a tight budget: user authentication, backups, error logging and a way to measure usage. If the system will handle personal data, protecting it by design belongs on that list too. In Chile, Law 21.719 is still set to take effect on December 1, 2026. The bill that would push it to October 15, 2027 was approved in general by the Chamber's Constitution Committee on November 4, but it isn't law yet. In practice, an MVP that launches now will run under the law as it stands.
How to measure with real users
Before anyone writes code, pick two or three metrics that will tell you whether the idea works, and write down the value you expect for each. If you don't decide beforehand, any result will look like a win afterward.
Some that tend to work:
- Actual use: how many invited users open the system at least once a week.
- Replacing the old process: what share of orders comes through the system, and how many still arrive by email or WhatsApp.
- Business outcome: time from order to dispatch, or data-entry errors per month.
Numbers tell you what's happening. To find out why, you have to talk to people. Set aside half an hour every two weeks to sit with two or three users and watch them work with the system. What you see in that half hour (the field nobody understands, the step everyone skips) won't show up in any report.
Choose the pilot group carefully. A small team with a manager who wants this to succeed will give you better information than a company-wide launch to people who never asked for the change.
Deciding the next iteration
After four to eight weeks of use you'll have enough to decide. You'll usually land on one of these:
- Keep going: the metrics look good and users want more. You move on to the "should have" items, prioritized by what you saw on the ground.
- Adjust: people use it, just not the way you expected. Maybe the real problem was a different one, or the workflow runs backwards. Fix that before adding anything.
- Stop: nobody uses it and you understand why. It stings, but you found out for a fraction of what the full product would have cost.
Lean Startup calls this the build-measure-learn loop. The decision has to come from the data and from conversations with users. If it comes from whoever most wanted their feature built, you're back where you started.
One technical point that matters here: if the MVP was built with shortcuts that won't scale, version two starts with a rewrite. Ask your vendor which decisions they made to ship fast and which ones should be revisited if the system keeps going. We covered what comes after go-live in what happens after custom software is delivered.
Common mistakes when commissioning an MVP
| Mistake | What happens | What to do |
|---|---|---|
| Calling the full product an MVP | Months of development before anyone uses it | One workflow, one user type, one question |
| Not defining metrics up front | Any result gets read as success | Two or three metrics with expected values |
| Cutting security and backups | The pilot fails for technical reasons, not business ones | Keep the basics even with few features |
| Launching to the whole company | Lots of noise, little useful information | A small, committed pilot group |
| Adding features during the pilot | You can't tell which change caused which result | Freeze scope until the review |
Frequently asked questions
How long does it take to build an MVP?
It depends on the workflow you choose and the integrations it needs. If a software development company proposes an MVP that takes many months, look hard at the scope: it probably includes more than you need to answer your question.
Is an MVP only for startups?
No. Established companies use the same approach when they want to digitize a process or launch a new service without betting the whole budget up front. The logic is the same: learn before you scale.
What happens to the MVP code if the project continues?
If it was built with sound practices, it becomes the foundation. That's why the MVP should be small in features but not sloppy in quality, and why the code and accounts should be in your company's name.
Start with the question, not the list
At Disrupsoft we start every project by understanding your requirements and processes, and we stay in constant contact with your team while we build custom web and mobile applications with Angular, Node.js, Azure and Power Platform. If you have an idea and want to figure out which first version is worth building, let's talk about your custom software development project.
