Build a proof of concept when you’re not sure the idea can work. Build a prototype when you’re not sure people will understand it. Build an MVP when you’re ready to find out if people will use it and pay for it. Most startups don’t need all three, and many need only one.
The three get mixed up all the time, and the mix-up is expensive. Some founders spend months polishing an “MVP” that is really a clickable prototype nobody can sign up for. Others pay for a full product before checking that the hard part, often the AI, works on their data. This guide explains what each one proves, what you get at the end, how long it takes, and how to decide which to build first.
Key numbers in 30 seconds
- A proof of concept tests one risky technical idea. It usually takes 1 to 2 weeks and is often thrown away afterwards.
- A prototype tests whether people understand the product. Clickable screens, no real back end, usually 1 to 2 weeks of design.
- An MVP tests whether people will use it and pay. At Emergen, a focused MVP costs $12,000 to $25,000 and takes 4 to 7 weeks.
- An MVP is not a demo. Real sign-ups, real data, and a codebase that grows into version 1 instead of being rebuilt.
- Most founders we speak to are ready for an MVP. AI products are the main exception: they usually need a short proof of concept first.
MVP vs prototype vs proof of concept at a glance
| Proof of concept (PoC) | Prototype | MVP | |
|---|---|---|---|
| Question it answers | Can this be built? | Do people understand it and want it? | Will people use it and pay? |
| Who sees it | Your team, maybe an investor | 5 to 10 target users | Real customers |
| What you get | A rough test of the hardest technical part | Clickable screens with no real back end | A working product with login, data and payments if needed |
| Real users can sign up? | No | No | Yes |
| Typical time | 1 to 2 weeks | 1 to 2 weeks | 4 to 7 weeks |
| Typical cost | A small fixed scope, quoted per project | Usually part of the MVP design phase | $12,000 to $25,000 |
| What happens to it after? | Usually thrown away; the learning stays | Designs carry into the MVP | Becomes version 1 of your product |
The MVP range is the one we publish in our web app development cost guide. A focused MVP covers one core workflow, login, basic account separation and simple billing. If your product needs much more than that to be useful on day one, it is really a version 1, which typically costs $25,000 to $60,000 and takes 8 to 14 weeks.
What a proof of concept proves
A proof of concept is a small, private test of the riskiest technical assumption in your product. It answers one yes-or-no question for your team. Customers never see it.
A real example: an AI assistant over your documents
Say you want an app that answers staff questions from 2,000 internal PDFs. The scary question isn’t “can we build a login page?” It’s “will the AI find the right answer in these files, or make things up?” A useful PoC loads a sample of the real PDFs, asks 30 real questions, and checks how many answers are correct and cite the right file.
The key is to agree the pass mark before you start, for example “at least 26 of 30 answers correct, with the right source”. Without a pass mark, every PoC looks like a success in the demo. If it passes, you know the core works. If it fails, you’ve saved the cost of a full build.
This is exactly how a RAG system works: the AI looks up the answer in your documents first, then replies. Our guide on what a RAG chatbot is explains it in plain words. A full RAG knowledge assistant on our AI chatbot development page costs $3,000 to $6,000 and usually takes 3 to 5 weeks, so for small document sets the PoC and the first build can be the same project.
Build a PoC when
- Your product depends on AI, a new API, hardware, or data you haven’t tested.
- An investor or your CTO asks, “are you sure that’s possible?”
- One technical failure would sink the whole idea.
Skip it when
The product is mostly standard parts: accounts, dashboards, payments, bookings, chat, file upload. These have been built thousands of times. Paying to prove they’re possible is wasted money.
What a prototype proves
A prototype shows what the product will look like and how people will move through it. It is usually a set of clickable screens made in a design tool like Figma. Nothing is saved, and no real data moves.
Three levels of prototype
| Level | What it looks like | Best for | Typical time |
|---|---|---|---|
| Paper or whiteboard sketch | Boxes and arrows, drawn by hand | Agreeing the flow with a co-founder | An afternoon |
| Wireframes | Grey screens with real labels, no styling | Checking that every step makes sense | 2 to 4 days |
| Clickable high-fidelity prototype | Looks like the real app, taps move between screens | User testing and investor demos | 1 to 2 weeks |
How to test a prototype properly
Put it in front of 5 to 10 people from your target market. Give each one a task, such as “book a car wash for Saturday”, and watch. Don’t explain the screens. Where they hesitate, tap the wrong thing or ask a question, your design needs work.
Example: you’re building a booking app for car-detailing shops. A shop owner taps through “add a service” and says, “I’d never set hours per day, just per week.” That one comment saves a week of building the wrong screen.
Build a prototype when
- The flow has many steps and you’re not sure people will follow it.
- You need to show the idea to users, co-founders or investors, and words aren’t enough.
- You want feedback before you pay for code.
Skip it when
Your product follows a pattern people already know, like a standard dashboard or a simple marketplace. Go straight to a small MVP. Every MVP we build starts with clickable designs in week one anyway, so you still see the screens before any code is written.
What an MVP proves
Eric Ries, who made the term popular in The Lean Startup, describes the MVP as the version of a product that lets a team collect “the maximum amount of validated learning about customers with the least effort” (Lean Startup). In practice, it is the smallest real product that does the one job your customers care about most. People can sign up, use it with their own data, and pay if you charge.
What a focused MVP usually includes
- One core workflow, done properly. For example: record a voice note, transcribe it, edit it, save it and export it.
- Sign-up and login, plus basic separation so each customer only sees their own data.
- An admin view so you can see users and fix problems without a developer.
- Simple billing with Stripe if you’re charging from day one.
- Analytics on sign-ups, the key action and where people drop off.
- Deployment on production infrastructure, not a demo server.
A well-scoped MVP covers about 5 to 8 core user flows. Team accounts, ten integrations, a mobile app and an AI layer can all wait for version 1 unless one of them is the core job.
Decide what success looks like before launch
An MVP is an experiment, so write down what result would mean “keep going”. Three numbers work for most products:
- Activation: the share of sign-ups who complete the key action at least once.
- Retention: the share still using it after 4 weeks.
- Willingness to pay: how many trial users convert, or agree to a paid pilot.
Pick target numbers that fit your market before you see the data. Otherwise any result can be explained away.
Which one should you build first?
Answer these three questions in order, and stop at the first “no”.
- Are you sure the hardest part can be built? If no, start with a proof of concept. This matters most for AI, data-heavy and hardware products.
- Are you sure users will understand the flow? If no, build a prototype and test it with 5 to 10 people from your target market.
- Do you have people who might pay? If yes, build an MVP. If not, line up 10 to 20 potential users first with a waitlist, a few calls or a landing page. An MVP with nobody to test it teaches you nothing.
What to build first for common startup ideas
| Your idea | Biggest risk | Start with | Then |
|---|---|---|---|
| AI assistant that answers from company documents | Will answers be correct on your data? | PoC with your real files and questions | MVP or straight to a RAG build |
| Two-sided marketplace | Will both sides understand and use it? | Prototype tested with both sides | MVP for one city or one niche |
| B2B SaaS for a workflow you know well | Will customers pay? | MVP | Version 1 after 4 to 8 weeks of usage data |
| App that relies on a new API or device | Does the integration actually work? | PoC of the integration | Prototype, then MVP |
| Pre-seed pitch with no product yet | Will investors and users get it? | Clickable prototype plus user interviews | MVP once funded |
Most founders we talk to are ready for an MVP. They have a clear problem, users they can reach, and a product built from standard parts. Founders building on AI are the main exception, because “will the AI answer correctly on our data?” is a real risk that a small test can answer quickly.
How the three fit together on a timeline
If you need all three, they run one after another, and each one makes the next cheaper:
| Stage | Typical time | What you keep |
|---|---|---|
| Proof of concept | 1 to 2 weeks | The answer to your biggest technical question, and often the core code idea |
| Prototype | 1 to 2 weeks | Screens, flows and user feedback that become the MVP design |
| MVP | 4 to 7 weeks | A live product that grows into version 1 |
Doing all three takes about 6 to 11 weeks. But because the prototype becomes the MVP design, the real cost of adding a prototype is small. For a week-by-week view of what comes after the MVP, see our SaaS development timeline guide.
5 expensive mistakes founders make
1. Calling a prototype an MVP
If users can’t sign up and use it with their own data, you can’t measure real behavior. You’ll get polite feedback instead of facts.
2. Putting everything into the MVP
Every extra feature adds time and makes it harder to see what users value. A simple test: if a feature doesn’t help answer “will they use it and pay?”, it waits for version 1.
3. Building a PoC for things known to work
Login, payments, chat and file upload don’t need proving. Save the PoC budget for the part that is new.
4. Throwing away the MVP code
A well-built MVP should still be running a year later. We build MVPs on Next.js, React, Node.js and Supabase so the same codebase grows into version 1. Ask any team you hire: “Will this code still be in use a year from now?”
5. Launching without tracking
An MVP without analytics is a guess. Make sure you can see sign-ups, the key action and drop-off from day one.
Red flags when hiring a team to build your MVP
- A quote before anyone asks what to cut. A good team helps you remove features before pricing them.
- No design phase. If code starts on day one, the screens get decided by whoever writes them.
- “We’ll rebuild it properly later.” That means you’re paying for a prototype at MVP prices.
- No plan for analytics or admin tools. You’ll be blind after launch.
- You won’t own the code and accounts. Your repository, hosting and domain should be in your name.
For the full list of questions to ask, read how to choose an AI development company. Most of it applies to any software partner.
Do you need a custom build at all?
Sometimes the best first step is none of the three. If an existing tool already does 80% of what you need, test your idea with it first. A no-code tool or an off-the-shelf platform can validate demand in days. Our guide to custom web apps vs off-the-shelf software shows how to compare the long-term cost.
What building AI products has taught us
For AI products, the first question is almost never about screens. With Abee, an enterprise assistant that answers from company documents, the risk was whether answers stayed grounded in the right files and respected who was allowed to see them. With Sakkar AI, which answers from published medical research, the risk was that a confident wrong answer could do real harm.
In both cases, the screens were the easy part. The time went into proving that retrieval and answers held up on real content. That’s why, for AI ideas, we usually suggest a short PoC on your real data before anything else.
About this guide
This guide was written by Huzaifa Imran, CTO at Emergen, who leads our product and AI builds. Prices and timelines are the ranges we publish on emergen.io. Outside quotes link to their source. We update this page when our ranges or process change.
Frequently asked questions
A proof of concept tests whether something can be built. A prototype tests whether people understand and want it, using clickable screens. An MVP is a real, working product that tests whether people will use it and pay for it.
No. A proof of concept tests whether something can work technically, and users usually never see it. A prototype is built for users to click through, to check that they understand the product and want it.
Some founders do, especially at pre-seed. A clickable prototype plus user interviews shows you understand the problem. Many investors still want real usage, which only an MVP gives you.
At Emergen, a focused MVP usually takes 4 to 7 weeks from kickoff to launch. Scope changes and slow feedback cause most delays, so it helps to have one decision-maker on your side.
Our focused MVPs typically cost $12,000 to $25,000. Products with payments, several user types or many integrations sit at the top of the range. If a product needs much more on day one, it is really a version 1, which typically costs $25,000 to $60,000.
Often, yes. The main risk with AI is answer quality on your own data. A short test with your real documents, real questions and an agreed pass mark tells you that before you commit to a full build.
The designs can. The clickable prototype itself usually can’t, because it has no real back end. The screens, flows and user feedback carry straight into the MVP build.
Not sure which one you need?
Bring your idea to a free 15-minute call. We’ll tell you whether to start with a proof of concept, a prototype or an MVP, what to cut, and a realistic price range. Prefer email? Send us a message.
