Probably. But maybe not yet — and almost certainly not the kind you're thinking of.
That's the answer, and you should spend a little time understanding it before you commission anything or spend a weekend on Bubble trying to make something that works.
The instinct to build a prototype is usually right. The instinct about what to build and when to build it is frequently wrong — because the word "prototype" covers a lot of ground and the question "should I build a prototype?" is actually three different questions compressed into one.
This article separates them.
The Three Questions Hiding Inside "Should I Build a Prototype?"
Question one: Do I need to make this idea tangible before I can think about it clearly?
If the idea exists primarily in your head and you're struggling to communicate it to others — to a potential cofounder, an investor, a developer, even yourself at 2am — then yes, you need something. But that something might be a set of sketched screens, a Figma mockup, or a simple user journey diagram rather than anything that runs code.
Question two: Do I need to validate whether users will actually engage with this?
This is a different need from the first. You're not trying to communicate the idea — you're trying to test a specific assumption about user behaviour. Does the flow make sense? Do people understand what to do? Do they drop off where you thought they would or somewhere unexpected? For this, you need something interactive — not necessarily something functional.
Question three: Do I need to validate whether people will pay for this?
This is the most commercially significant question and the one that requires the most caution. Answering it doesn't always require a working app. Sometimes it requires a landing page, a manual service, or a sales conversation. Often, founders build a functional prototype to answer this question when they could have answered it faster and cheaper without building anything.
Most people asking "should I build a prototype?" are actually asking question two or three. Which one you're actually asking changes the answer significantly.
When You Should Build a Prototype
When you need to test the experience before committing to the build.
This is the strongest case for a prototype, and the one where it delivers the clearest return on investment.
If you're planning to commission a full custom development engagement — spending an app prototype budget of £20,000, £40,000, or more on building the real product — building an interactive prototype first is not an additional cost. It's insurance.
A designer-built interactive prototype in Figma, costing £2,000–£5,000, lets you test the user experience with real people before any development work begins. Problems discovered here cost a designer a day to fix. The same problems discovered during development cost a developer a week to fix. The same problems discovered after launch cost you user trust and potentially the product's early reputation.
The economics are straightforward: a prototype that surfaces three significant UX problems pays for itself several times over in development cost avoided.
When you need something tangible to raise investment.
Many pre-seed and seed stage investors will talk to founders with nothing more than a strong pitch deck and a compelling idea. Many more are willing to have a more serious conversation when there's something they can see and interact with.
An interactive prototype — properly designed, realistic-feeling, demonstrating the core user journey — makes the product vision real in a way that a pitch deck never does. Investors who understand software know the difference between a Figma prototype and a working product. Most of them also know that a well-designed prototype signals that the founder has thought through the product seriously, has a view on user experience, and is not just describing a concept they haven't tested.
When you need alignment within your team or with stakeholders.
If multiple people need to agree on what's being built — cofounders, advisors, a board, a client commissioning custom software — a prototype is the clearest and most efficient way to achieve that alignment.
Verbal descriptions of product functionality produce different mental models in different listeners. A clickable prototype produces the same experience for everyone who uses it, surfaces disagreements early, and replaces hours of "but I thought it would work like..." conversations with a shared, concrete reference point.
When you need to test a specific behavioural assumption.
"Users will want to complete this flow before seeing their results" is a hypothesis. A prototype lets you test it. You can watch real users go through the flow and find out whether they do what you assumed, where they hesitate, and what they reach for when the interface doesn't give them what they expected.
This kind of usability testing, done early, with a prototype rather than a built product, is one of the highest-return activities in product development. The feedback is specific, actionable, and cheap to act on.
When You Should NOT Build a Prototype Yet
When you haven't validated that the problem is real.
A prototype tests your solution. It doesn't test whether the problem you're solving is real, painful, and worth paying to fix. Those are different questions — and if you haven't answered them, building a prototype is premature.
The evidence that a problem is real comes from conversations with real people who have it. Twenty well-conducted customer interviews, asking open questions about how they currently handle the problem, will tell you more about whether your idea is worth building than any prototype. If those interviews confirm the problem, the prototype becomes the next step. If they reveal the problem is different from what you assumed, the prototype would have been built for the wrong thing.
Customer conversations cost nothing. Build after them, not before.
When the core question is commercial rather than experiential.
"Will people pay for this?" is not a question that always requires a prototype to answer.
Sometimes it requires a landing page with a "request early access" button and a count of how many people sign up. Sometimes it requires manually delivering the service — doing by hand what the software will eventually automate — and seeing if customers pay and come back. Sometimes it requires a direct sales conversation where you describe the product and ask someone to commit to being a paying customer when it's built.
If the validation question is "will anyone pay for this?", a manual approach to answering it is often faster and more convincing than building a prototype. A prototype shows that the experience could work. Actual paying customers, even for a manual service, shows that people value the outcome enough to exchange money for it.
When you don't yet know what to put in it.
A prototype built without sufficient user research and product thinking is a prototype that will need to be redone.
The prototype should be the output of a process of thinking clearly about users, problems, and solutions — not the input to that process. If you sit down to design the prototype and you find yourself making decisions based on preference rather than evidence, you're not ready. The thinking needs to happen before the designing.
When what you actually need is the full product.
Sometimes founders consider a prototype when what they actually need is an MVP. The distinction matters commercially.
If you've validated demand, you know what you're building, and you're ready to build it — a prototype is a detour. The time and money spent on a prototype that will be shown to five people and then superseded by the real product is time and money that could go directly into building the real product correctly.
Know which stage you're actually at. If the validation question has already been answered, skip the prototype and build the thing.
What to Do Before Building Anything
Regardless of which type of prototype you're considering, two things should happen first.
Talk to your users
Twenty conversations. Open questions. What are they doing today to solve this problem? What frustrates them about the current approach? What would they want from a solution? The answers to these questions shape every decision in the prototype — what screens to include, what flow to design, what to prioritise. Building without this knowledge produces a prototype built on assumptions. Building with it produces a prototype built on evidence.
Define the one question the prototype needs to answer
Not five questions — one. The clearer this question is, the more useful the prototype will be as a research tool rather than a general expression of the product vision. "Does the booking flow make sense to first-time users?" is a question. "Is the product good?" is not.
With those two things done, the prototype is a focused instrument for answering a specific question rather than an expression of enthusiasm. The first kind pays back quickly. The second is the kind that people spend money on and then aren't quite sure what they learned.
Where Octogle Comes In
We work with founders at the point where the prototype question has been answered and the build question begins.
Our process includes a design phase — producing the interactive prototype that validates the experience before development starts. For founders who are ready to move from prototype to product, we take that design work and build from it: properly scoped, properly developed, on a timeline and at a cost that reflects how development actually works with the right team.
If you're not sure whether you're at the prototype stage or the build stage — or whether what you need is a prototype at all — that's a useful conversation to have before spending anything.
Octogle Technologies helps founders move from prototype to product — interactive design that validates the experience, then development that builds it properly. Tell us where you are and we'll tell you what makes sense next.
