Reviewed by LAB/02 editorial check (AI-assisted)
Should you prototype before building your business idea?
Decide what you need to learn before paying for software: a clear customer journey, a clickable prototype, or a focused feasibility test.
Start with the decision, not the deliverable
A new digital service can look convincing and still leave an important question unanswered. Will customers understand the offer? Can they choose the right option without help? Does the next step feel worth taking? Before commissioning a full build, write down the decision you need to make and the evidence that would help you make it.
Imagine an independent events business that wants people to discover a night out and request places. The first uncertainty might be the journey from discovery to selection, not payment processing. A prototype can make that journey tangible without pretending that tickets, payments or availability are already connected.
A clickable prototype is a conversation with something concrete
An interactive prototype connects key screens so someone can try a task. Instead of explaining every step in a presentation, give a potential customer a small scenario and observe what they do. Ask them to find a suitable experience, review a choice and reach the next step. Note where the interface helps and where you still have to explain it.
This is not a forecast of demand and it is not a production service. A successful session does not prove people will buy. It gives you a more specific set of questions, a clearer journey and a basis for deciding what to revise before development.
Choose a different starting point when the uncertainty is different
If you need a distinctive first visual direction, Core Screens may be sufficient: a set of agreed screen designs, not working software. If you already have a developer, an Agency-Ready package focuses on making the design buildable. If the difficult question is whether a rule or external system connection can work, a Proof of Concept is more appropriate than a polished clickable journey.
A prototype is useful when the interaction itself is the question. It should not disguise an engineering uncertainty or become a substitute for agreeing scope, responsibilities and acceptance criteria.
Define the boundary before you start
Agree the customer task, the screens included and the feedback you want to gather. Be explicit about what is simulated. No real bookings, payments or account security should be implied by a prototype. Record what remains unknown and which decision follows the review.
At LAB/02, Interactive Prototype has an indicative starting budget from EUR 4,500. Projects follow Submit, Review, Scope and Build; acceptance is selective and a final scope is agreed before a paid engagement. Collaboration is written, with no video calls.