In short: A prototype is an early version of a product, built to test an assumption – not to sell or to impress. A good prototype tests one important thing: whether the core thing you’re promising is even possible. It should be fast and cheap, and reach real customers as early as possible.
When we founded Highcon, we interviewed potential customers, distilled the challenge and started thinking about a solution. Then came the moment to build something real. We went looking for parts in scrapyards, and built a prototype.
It wasn’t pretty. It wasn’t supposed to be. It was supposed to prove one thing – and it did: that packaging can be produced digitally, without the cutting dies the analog method requires.
I wrote about that period in the first chapters of my book, “Light and Shadow – A Mental Journey of Entrepreneurship”.
I see this lesson again and again with the founders I mentor: the first prototype is there to prove, not to impress.
What is a prototype?
A prototype is an early version of a product, built to test something. It can be a sketch, mock screens, a cardboard model, partly working software, or a machine assembled from used parts.
What makes it a prototype isn’t how it looks, but why it was built: to test one specific assumption before investing in full development.
Proof of concept, prototype or MVP?
Three terms that get mixed up a lot. Each one tests a different risk:
- Proof of concept (POC) answers the question “Can we build this?”. It’s a focused technical experiment, usually internal and with no interface, that checks whether the core technology works.
- Prototype answers the question “What will it look like and how will it work?”. It demonstrates the product – the look, the experience, how it’s used – to get feedback from users, customers and investors. It usually isn’t sold.
- MVP (Minimum Viable Product) answers the question “Will anyone use this and pay for it?”. It’s a real product with only the essential features, released to real customers to test demand. If the answer is good – you keep building on it.
The common order: proof of concept, then prototype, then MVP. In practice the lines aren’t always sharp, and they look different in hardware and in software.
Prototypes in hardware and in software
In software, a prototype can be clickable mock screens, built in days. Today, with AI development tools like Claude Code, you can build a prototype that actually works within hours, and sometimes skip almost straight to an MVP. And after that the pace stays very fast: you release an update, see what users do, and fix – sometimes several times a day. At large software companies the product is updated dozens or even hundreds of times a day. When building is this cheap, the main risk is almost never “can we build it”, but “does anyone need it”.
In hardware, everything is slower and more expensive, so testing the right risk at each stage matters even more:
- A proof of concept is usually a lab rig that only checks that the technology works.
- A prototype often splits in two: a works-like prototype that tests how it functions, and a looks-like prototype that tests shape, size and experience. You start with whichever carries more risk.
- An MVP combines the two into first units that customers actually use. Every change after production starts is expensive, so you don’t rush there.
Highcon’s first prototype was like that: it was mainly a proof of concept – and it proved that packaging can be produced digitally, without cutting dies.
What should the prototype prove?
Every idea rests on several assumptions. The first prototype should test the riskiest one – the one that, if it’s wrong, nothing else matters.
- In a hardware startup, it’s usually whether the technology works in reality. At Highcon, it was whether packaging could be cut and creased without a die.
- In software, it’s usually whether customers understand the value and want to use it.
- In a B2B product, it’s sometimes whether the customer is willing to change the way they work today.
Before you start building, write one sentence: “This prototype will prove that…” If it’s hard to write, it’s too early to build.
Five common mistakes
- Polishing too early. Beautiful design and perfect finish take time and money, and don’t help you test whether the core assumption is right.
- Building everything. A prototype should test one thing. Every extra feature hides the answer.
- Not knowing what you’re testing. Building “to see what happens” – and in the end, not knowing whether it worked.
- Not showing it to customers. A prototype that stays in the lab only tests what the team thinks.
- Falling in love with it. A prototype is a learning tool. If it shows the assumption is wrong – that isn’t failure, it’s an answer.
How to build a first prototype
- Define what you want to test first. Don’t start by planning the product, but from the assumption the prototype needs to prove. At Highcon, for example: “Can packaging be produced digitally, without cutting dies?”
- As cheap and fast as possible. Used parts, existing tools, simulation – whatever is enough to test the assumption.
- Define success in advance. What needs to happen for you to know the assumption is right?
- Show it to customers early. An ugly prototype in front of a real customer beats a perfect one in a drawer.
- Write down what you learned, and decide: continue, change, or stop.
Prototypes and investors
Early-stage investors don’t expect a finished product. They want to see that you’ve tested the most important assumption, and that you know how to move without a lot of money. A prototype built cheaply that proves something real says more about you than any pitch deck.
Want to check if you’re ready for that meeting? Try the “Ready to meet an investor?” quiz.
Frequently asked questions
What’s the difference between a prototype and an MVP?
A prototype demonstrates how the product will look and work, to get feedback, and usually isn’t sold. An MVP is a real product with only the essential features, which customers use and pay for, to test whether there’s demand. Before both, there’s sometimes a proof of concept (POC), which only checks whether the technology works.
How long does it take to build a prototype?
In software – sometimes hours or days, especially with AI tools. In hardware – weeks to months. If it takes much longer, the prototype is probably testing too many things.
Do you need a prototype before raising money?
Not always, but it helps a lot. A prototype that proves the most important assumption gives investors a reason to believe the idea is possible.
Does the prototype need to look good?
No. It needs to show whether the assumption is right. Looks and finish come later.
The bottom line: A good prototype isn’t measured by how impressive it is, but by how fast it shows you whether your most important assumption is right. Build it cheap, show it early, and let it surprise you.
Want support at this stage – from market validation to a prototype and fundraising prep? Early Stage Mentoring, or book an intro call.
