Guide · Apps and software
Demo, prototype or MVP:what does your idea need?
The three words get used as if they meant the same thing. They don’t, and choosing the wrong one wastes money at exactly the moment you have the least. Here is what each one is for, what it leaves out and how to decide.
A demo: does the idea make sense?
A demo is a small working piece of the idea: one screen, one flow, one automated step. Its job is to check that the developer understood you and that the idea holds up when you see it. It uses sample data, skips accounts and payments, and is not meant to be used by customers.
This is the step I offer for free on suitable projects, with an agreed scope. It is cheap because it is deliberately narrow.
A prototype: does it work for the people who will use it?
A prototype covers the main path through the product well enough for real people to try it and give feedback. It may still run on test data and skip the parts that are expensive to get right, such as security, billing or integrations with other systems.
Prototypes are for learning. Treating one as a finished product is the most common way projects go wrong: the shortcuts taken to build it fast become permanent.
An MVP: can it be used for real?
A minimum viable product is the first version real users can rely on. It has fewer features than the final product, but the ones it has are complete: accounts, data that is stored safely, errors handled, hosting that stays up. It is a paid project with a defined scope and a written quote.
“Minimum” is about the feature list, not the quality. A small product done properly beats a large one done halfway.
How to choose
- You are not sure the idea is understood or realistic: start with a demo.
- You need feedback from users or investors before committing: prototype.
- You have a clear core use case and people ready to use it: MVP.
- You already have users and a product: improve what exists instead of starting over.
Common mistakes
- Building the whole product before anyone has tried the core idea.
- Putting a prototype in front of paying customers and then fixing it under pressure.
- Leaving the scope vague, so the first version never feels finished.
- Choosing the technology before knowing what the product has to do.
Each of these is avoidable with a clear first step and a written scope.
How this works with me
We start with a conversation. For suitable ideas, I prepare a free basic demo with an agreed scope, using AI agents to move quickly and reviewing the result myself. If you want to continue, the prototype or MVP is quoted separately, with features, an estimated timeframe and price in writing.
Questions before we start
Is the demo really free?
Yes, once we agree a basic demo that fits. There is no obligation to continue afterwards.
Can I show a demo or prototype to investors?
Yes, and that is a good use for it, as long as everyone understands it is a demonstration, not the finished product.
How much does an MVP cost?
It depends on the features, integrations and platforms. Accounts, payments and connections to other systems are the usual cost drivers. I quote after we define the scope; there are no fixed packages.
Which technology will you use?
The one that fits the product, your existing systems and the maintenance you can support. You don’t need to choose it; I explain the options before we decide.