Rapid prototyping: how to test product ideas without building the wrong thing

Most product teams start with good intentions: build something valuable for real users. Yet months later, they arrive at the same place. A product that is too complex, solves the wrong problem, or simply goes unused. Not because the team did poor work, but because they waited too long to test.

Rapid prototyping is the counter-move. Instead of building first and validating later, you flip the order. You test an idea as quickly and cheaply as possible with real users, before large budgets are committed.

At Livewall, we apply rapid prototyping on nearly every digital product we build. Not as a formality, but as the sharpest tool we have to stop a team from investing months in the wrong direction.

What rapid prototyping actually means

Prototyping is not the same as building an early version. An early version is code. A prototype is a question. You want to know: do users understand what to do here? Does this solve their problem? Are they willing to take action?

A rapid prototype can be anything: a clickable Figma screen, a static web page, a paper mockup, or a partial interface with no backend. What matters is that you can observe real user behaviour without having built the full solution.

Speed is the point. A good first iteration takes two to five days. You are not building the product. You are building just enough to answer the most important questions.

The five questions every prototype must answer

Before you start, write down the assumptions you want to test. Not all of them at once. Choose the three to five that carry the most risk: if any one of them is wrong, the product direction changes entirely.

Typical questions include:

Do users understand the core functionality? Can they take the first step without instructions?

Does it solve the right problem? Do users recognise the problem you are trying to solve, or do they name something else entirely?

Is the value proposition clear? After thirty seconds, do users understand why this product is relevant to them?

Are users willing to perform the real behaviour? Will they click 'sign up', even knowing the product is not live yet?

What do users do that you did not expect? Every surprising click or question is a data point.

Once you have the questions, build the minimum required to answer them. Nothing more.

From prototype to MVP: the transition

Rapid prototyping and MVP development are not the same thing. A prototype proves that a concept works with users. An MVP is the first working product you take to market.

The prototype phase prevents you from building an MVP on the wrong foundation. We have seen projects at Livewall where an initial prototype, built in three days, disproved three fundamental assumptions. The MVP that followed was smaller, more focused, and far more successful than the original vision could ever have been.

After validation, the path to an MVP becomes clear. You know which features matter, which flows work, and where users get stuck. That knowledge accelerates the build phase considerably.

When rapid prototyping delivers the most value

Not every project needs the same intensity of prototyping. But there are situations where you should almost always do it:

When the concept is new and the user group is unfamiliar. If you have never worked with this audience, you do not know what they find obvious.

When you are choosing between multiple product directions. Rather than debating internally, test two variants with users simultaneously and let the data decide.

When technical complexity is high. The more intricate the architecture, the more expensive a course correction later. Validate the user experience early so the build phase does not rest on guesswork.

When stakeholders disagree. A prototype makes abstract discussions concrete. Watching a user struggle with your product for five minutes says more than ten presentation slides.

The AvroTros Eurovision voting app is a strong example: a product with hard timing constraints where early testing was essential to launching on time with an app capable of handling 141,000 users.

The mistakes we see most often

Testing internally instead of with real users. Team members know the product too well. They understand what is meant, even when it is not clear. Outside users do not have that context, which is exactly why their feedback matters.

Trying to test too much at once. A prototype that tests twelve features tests none of them well. Stay focused. One or two core questions per round.

Treating prototyping as a checkbox. If rapid prototyping is just a box you tick before the 'real work' begins, you have missed the point. The findings need to actually change the product direction.

Waiting too long before user testing. We regularly see teams who only test once the UX is fully designed. That is too late. Test as early as possible, even if the prototype is rough. Rough prototypes often generate the most honest feedback.

At Livewall, we integrate UX/UI design and prototyping as one continuous process, not a sequence of separate phases.

How to set up a first prototype in five steps

Step 1: Name your riskiest assumption. What needs to be true for this product to work? Start there.

Step 2: Determine the minimum representation. What is the least you need to build to test that assumption? Figma screens, a simple web page, a clickable demo?

Step 3: Write your test scenarios. What task are you giving users? Keep it realistic. Observe without guiding.

Step 4: Test with five to eight users. That is enough to see the major patterns. More users add little to the first round.

Step 5: Process and decide. What confirms your assumptions? What disproves them? Adjust the direction and start the next iteration, or move to the build phase with confidence.

The Sportvisunie community platform is a case in point: multiple prototype rounds significantly simplified the final feature set and accelerated the launch considerably.