Guide · Apps and software
Demo, prototype or MVP: what does your idea need?
A demo, prototype and MVP serve different purposes. Choosing the right one helps you test the idea before committing to a larger build. This guide explains what each includes, what it leaves out and when to use it.
A demo: does the idea make sense?
A demo is a small working piece of the idea: one screen, one page or 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 costs little to build 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 can use test accounts and isolated sample data, leaving production features such as billing or integrations with other systems for later. That keeps the test manageable; it does not make security optional.
Prototypes are for learning. If you start using one as a finished product, shortcuts from the test version can end up in everyday use without anyone reviewing them.
An MVP: can it be used for real?
A minimum viable product is a first version for real users. Its scope is small, but it must complete the agreed task from start to finish. It includes the permissions, data storage, error handling and hosting that task requires, with recovery measures for failures. I quote it as a paid project with scope and price in writing.
Keep the feature list small enough to finish and test properly. The included features still need to work reliably for their intended use.
To budget for that first release, review what makes an application expensive.
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.
Once the scope is clear, consider whether a freelance developer or an agency fits.
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.
Where do a proof of concept (PoC) and a pilot fit?
A proof of concept answers a technical question, such as whether a sensor can be read or a program connected, and often has no finished interface. A pilot is real use by a small group for a limited period, usually with an MVP or a finished product, before a wider rollout. A demo can include a small proof of concept when the idea depends on one risky technical step.
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.