What is an MVP, and should a small business start with one?
An MVP, short for minimum viable product, is the smallest working version of software that does its main job for real users. For a small business it is usually a sound way to have software built: you get one core task working, learn from real use, then decide what to add. Leave out the extras, but not security, backups or ownership of your own data.
What an MVP is
"Viable" is the important word. An MVP is not a mock-up or a demo. Real people can use it for the real job, even though it does little else. A first version might let customers upload photos of a problem so that you receive them in one place, and nothing else.
"Minimum" means one main job done well. Everything that is nice to have waits until the first version has shown what is actually needed.
Why a first version is a sound way to have software built
- A common risk in a software project is building the wrong thing. Real use is usually a better guide than a long list written in advance.
- A smaller stage is easier to check. The related answer on how to check a developer's work before paying for more describes approving one stage at a time.
- It is easier to change direction early. If the first version shows that a bought product would do the job, you learn that before a large build.
- Projects tend to run over when the scope keeps growing, as the related answer on what decides the cost of custom software explains. A first version puts a boundary around the scope.
What to leave out, and what not to
| Usually fine to leave out at first | Do not leave out | |
|---|---|---|
| Features | Rarely used options, extra reports, extra kinds of users, a polished look | The one task the software exists for, working from start to finish |
| Connections | Links to tools you could still handle by hand for now | Anything the main task cannot work without |
| Safety | Cosmetic extras | Sign-in that protects other people's information, and care with any payment or personal details |
| Your data | Fancy exports and dashboards | Backups with a test restore, and a way to get your data out |
| Ownership | Nice-to-have admin screens | Accounts and code in your name, as the related answer on who owns software built for your business explains |
How to decide what comes next
- Let real people use the first version for a few weeks before adding anything.
- Keep one written list of requests, with how often each one comes up.
- Rank each request by what it saves or earns and by how much work it is. Often the most repeated request is the best next step.
- Add one change at a time, and check each against the same plain-words test: can the person do the job, and do you receive what you expected?
- If most requests point toward a different tool, that is a useful result too. The related answer on custom software or off-the-shelf software covers that choice.
Related answers
- Should you buy off-the-shelf software or have something built?
- How do you check a developer's work before paying for more?
- What decides how much custom software costs, and why do projects run over?
Custom software and apps
Off-the-shelf tools get you most of the way. When the last stretch is where the time goes, we build the part that fits: the dashboard, the portal, the internal tool or the app.