The words get used loosely
A business owner comes to a conversation about a piece of software wanting “an MVP” or “just a quick prototype” or “the real thing, done properly.” Often they mean three different things by those three phrases, and sometimes they mean the same thing by all of them. That confusion isn’t a communication problem to smooth over — it’s the first decision you actually need to make, because it changes the cost, the timeline, and what you’re allowed to get wrong.
Here’s a working definition of each, and a practical way to work out which one fits where you are.
A prototype answers “does this idea even work?”
A prototype exists to test an assumption cheaply, usually before you’ve committed to building anything real. It doesn’t need to handle real customer data, real payments, or real load. It can be held together with duct tape — a clickable mockup, a spreadsheet doing the work behind a nice front end, a tool only you and a couple of trusted people will ever touch.
The right question for a prototype is narrow: will people actually use this the way I think they will? If you’re not sure whether customers want to book online instead of calling, or whether your staff would actually follow a new quoting flow instead of falling back to the old paper form, a prototype answers that for a fraction of the cost of building it properly — and it’s fine if it falls over the moment you push it too hard, because that was never its job.
An MVP answers “should we keep building this?”
A minimum viable product is a real product, used by real customers, doing the one thing it needs to do well — deliberately without the ten things you’re tempted to add. It has to be reliable enough that a genuine user can rely on it, but it doesn’t need every feature on your wishlist, and it doesn’t need to scale to a size you haven’t reached yet.
The mistake we see most often here isn’t building an MVP that’s too small. It’s building one that’s too big — trying to ship the finished vision on the first attempt, which means it takes months longer to learn anything and costs far more before you know if the idea holds up commercially. A good MVP is embarrassingly narrow. If it isn’t a little embarrassing, it’s probably not minimal.
A production build answers “we know this works — now make it solid”
Production means the thing is depended upon. Customers expect it to be there. Staff run their day through it. Downtime costs you something real — a missed booking, an annoyed customer, a day of manual workarounds while it’s fixed. At this stage the priorities shift: reliability, security, proper error handling, a sensible way to make changes without breaking things, and enough monitoring that you find out about a problem before your customers tell you.
This is also the point where cutting corners becomes expensive rather than cheap. A shortcut in a prototype costs you nothing — you throw it away. The same shortcut left in a production system quietly becomes a liability that someone eventually has to unpick, usually at a worse time than now.
Deciding which one you need
Ask yourself what you actually don’t know yet.
- If you don’t know whether people want this at all, you need a prototype. Spend as little as possible finding out.
- If you know people want it but you don’t know whether it holds up in daily use, or whether it’s commercially worth building further, you need an MVP. Spend just enough to get real usage.
- If you already know it works and people are depending on it, you need a production build. Spend what’s required to make it dependable.
The expensive mistake is skipping a stage in the wrong direction — either building production-grade infrastructure for an idea nobody’s confirmed they want, or leaving a genuinely load-bearing tool running on prototype-quality foundations because it “seems to be working fine.” Both are more common than they should be, and both are usually driven by the same thing: nobody stopped to ask which of the three questions was actually still open.
A related pattern worth watching for
Plenty of internal tools started life as a prototype or an informal MVP — something built to solve one team’s problem — and quietly became load-bearing without anyone deciding that on purpose. If a spreadsheet macro or an internal script has become something the business would genuinely struggle without, that’s usually the signal it has already crossed from prototype into production in every way that matters except how it was actually built. Worth an honest look before it fails at the wrong moment, not after.