An MVP is the smallest version of a product that completely solves one single problem, for a real user, in real conditions. The key word is "completely." An MVP does one thing and does it all the way through, including everything that implies: the case where it goes well, and the case where it goes wrong.
That is also the line separating an MVP from what often gets sold under the name: a version that does five things halfway. The first is usable and tells you something. The second is neither usable nor informative, and costs the same.
01.Where the term comes from and what it turned into
The term comes from the world of software products, where the original idea was about learning: build the minimum needed to find out whether your assumption about users is true, before investing in the rest.
In everyday practice it came to mean something else. It gets used as a polite synonym for "the cheap version" or, worse, for "the version we did not finish." The confusion is commercially useful, because it allows something incomplete to be delivered under a respectable name. It is worth knowing the difference before you sign, because it is the difference between paying for an experiment and paying for a postponed promise.
02.Three things that are not an MVP
It is not a cheap version of the full product. An MVP does not contain every feature in a weak form. It contains a few features in a good form. If the quote you receive lists every module from the final vision and simply cuts the quality of each, what you have in front of you is not an MVP. It is an underfunded product.
It is not a broken version. An MVP ships to real users, so it has to work. Errors, lost data and flows that jam are not "to be expected in an MVP." They are unfinished work with a convenient label.
It is not a demo. A demo shows how it would be. An MVP gets used. The practical difference: a demo has invented data and a route prepared in advance, an MVP has your client's data and the route they choose themselves.
03.The rule that decides what goes in: one flow, all the way through
The most useful rule we know for choosing what goes into a first version: pick one complete flow, from beginning to end, and build all of it.
A flow is the road a person travels to get a result. It is not a feature, it is a story with an ending. "A client creates an account" is not a flow. "A client creates an account, books a session, receives the confirmation, and can cancel it up to 24 hours before" is a flow.
Choosing the right flow usually follows one of two logics. Either you pick the flow that produces money, because it justifies the rest of the investment. Or you pick the flow that eats the most manual time, because the saving is immediate and visible. What does not work is picking the flow that is easiest to build, which is the natural temptation and leaves you with something that changes nothing.
04.A concrete example
Say a small clinic wants "an app for patients." The full vision has appointments, medical records, messaging with the doctor, payments, prescriptions, notifications, and reports for the administrator.
The MVP, as one complete flow: the patient logs in, sees the free slots of a single doctor, books an appointment, receives an email confirmation, and can cancel up to 24 hours before. Reception sees the bookings on a simple screen and can cancel on the patient's behalf if they phone.
What goes in, even though it looks like a lot: the cancellation, the confirmation notification, the reception screen. All three look like "phase two" and none of them are, because without them the flow is not complete. A patient who cannot cancel will phone, and reception will keep a parallel notebook anyway, which means you have tested nothing.
What stays out: medical records, messaging, payments, prescriptions, reports, and the other doctors. Not because they do not matter, but because they are not needed in order to find out whether patients book for themselves or still call the front desk.
And that is the question. An MVP gets built to answer a question, and the question is written down before, not after.
05.Prototype, MVP or pilot: three different things
The terms get mixed together in conversation, and each answers a different question.
A prototype is a mockup you can navigate, with no working code behind it. It saves no data and connects to nothing. It answers the question "is this clear?" and costs the least of the three. It is the right instrument when you are unsure about the structure or the flow on screen.
An MVP is real software, used by real people, with their own data. It answers the question "do they use it?".
A pilot is an MVP released under control, to a small and known group, usually clients you already have a good relationship with. It answers the same question as an MVP, with less reputational risk, because you know who is seeing it.
The natural order is prototype, then MVP or pilot. Skipping the prototype is tempting and usually gets paid for: adjustments on a mockup cost hours, the same adjustments on code cost days.
06.How you know whether it worked
Before building, write this sentence and complete it: "We will know it worked if, in the first month, ______."
In the example above: if at least a quarter of bookings come through the app instead of the phone. It can be any realistic threshold, as long as it is chosen beforehand. A threshold chosen after delivery always moves so that the result comes out good.
Without that sentence, the MVP becomes just a first invoicing instalment, and the decision to continue gets made on the basis of how much has already been spent, which is the worst possible criterion.
07.The mistakes that make an MVP useless
- Too many flows, none of them whole. The classic result of trying to please everyone in the company. Nobody can use the product for anything real, so you learn nothing.
- No real users. An MVP tested only internally, by the team that commissioned it, produces no information. People who know how it is supposed to work do not behave like people who do not.
- No question formulated in advance. If you cannot say what you want to find out, you will deliver something and call the result a success, whatever it is.
- Design treated as a later phase. If the product is confusing, people do not use it, and you will conclude the idea was wrong when in fact the screen was. It is the most expensive false conclusion on this list.
- No plan for the data. If the MVP works and then has to be thrown away because the data cannot move into the next version, you have paid twice.
08.What happens afterwards
An MVP ends with one of three conclusions, and all three are valid outcomes.
It works, it extends. You add the second flow, then the third, in order of value. This is the usual path and it is why it is worth building on serious foundations even at small scale.
It works partly, it gets adjusted. People use it, but differently from how you expected. This is the most valuable result of the three, because you bought information you could not have obtained any other way.
It does not work, it stops. Rare, but real. You spent a fraction of the full budget to find that out, which is precisely the point of the exercise. A project stopped after an MVP is a project that cost you far less than one stopped after a full launch.
We wrote about the stages and timelines of each phase in how long an app takes, and about the price bands in how much an app costs.
09.When you do not need an MVP
If the problem is known, the process is stable and products already exist that do the thing, you do not need an experiment. You need an implementation. An MVP suits situations where there is a real unknown about how people will behave. Where there is none, it is simply a delivery split into two, which is fine, but deserves the correct name.
If you are not sure which case you are in, the conversation comes earlier and we wrote it separately: do you need an app or a better process.
10.The GoodGlyph take
If you take one thing from this: write down the question you want answered and the threshold at which you will call the result a success, both before the first line of code. Then cut the list until one single flow remains, taken all the way through. That is how we work on custom apps: the first version is small but whole, and built on foundations that carry the rest. Write to us with the flow you would choose and we will tell you what is still missing from it, before any quote.
11.Closing
A good MVP is not a smaller product. It is a narrower one. The difference shows up in the first month: one gets used by real people and tells you something, the other gets presented in meetings and waits for phase two.
Frequently asked questions
It depends on the flow, but a properly built MVP usually sits in the lower band for apps, from a few thousand euros. If a quote for an MVP approaches the price of the full product, most likely nothing was cut from the scope.
