🎉
Revolution wins Sustainable Business of the Year 2026!
Revolution wins Sustainable Business of the Year 2026!
Most projects go wrong early. A client has a vision, a brief gets written, and work begins. Halfway through, the structure doesn’t fit the content, the user flow has gaps, and three different pages turn out to serve the same purpose. By the time anyone notices, fixing things takes days of effort.
Prototyping addresses this by catching problems before they become expensive. It applies to a simple lead generation website built on a purchased template and to a fully bespoke application developed from scratch. The scale varies between projects, while the underlying logic stays consistent.
A prototype can be simple. Its purpose is to serve as a testable representation of the thing being built, rough enough to produce quickly and detailed enough to reveal real problems.
In practice, it can take several forms:
The medium matters less than the purpose. A prototype exists to test whether the structure, content, and user flow work before any significant build effort begins. The goal at this stage is clarity about whether the logic holds. Visual polish comes later.
Before any design work begins, before a template is selected or a single component is built, a minimal prototype should be in place. This is the stage where a project gets its foundation.
The starting point is content. Who provides it? What already exists? What needs to be produced? In e-commerce projects, the product catalogue is the essential first input. It determines how navigation, filtering, and the entire catalogue structure should be organised. Trying to design or build without it leads to assumptions that often turn out to be wrong.
With content established, the prototype maps the key pages, the user flow between them, and the calls to action at each stage. Appearance can stay rough, as long as the format is visual. Text-based wireframes alone fail to reveal dependencies between elements clearly enough to catch real structural problems.
What gets tested at this stage:
That last point matters more than it might seem. Reviewing conversion elements at the prototype stage costs almost nothing. The same review in a live build, after the structure is locked, can be expensive to act on.
For template-based projects, this prototype also informs which template to purchase, because the structure is already mapped and the choice becomes informed. For bespoke projects, it serves as the foundation from which design work begins.
Once the first prototype exists, it goes to the client for review and approval. This step is worth more than it might appear.
The prototype is the point at which a client can meaningfully evaluate what is being built. Later, when a site looks finished but needs structural changes, the cost of those changes increases significantly. Getting genuine feedback and approval at this stage, when everything is still easy to move, is one of the most valuable parts of any project process.
The approval matters because it creates a reference point. Once a client signs off on the prototype, it becomes the single source of truth for everything that follows. Changes after that point are legitimate, though they represent additional work. Making sure clients understand this distinction, and what the prototype actually represents, forms part of the process itself.
Once the structure is approved, the project moves into design. And design, in this context, is also a prototype.
This stage tests visual direction, interaction patterns, and refined UX. It answers questions the first prototype couldn’t: how does this look and feel, does the visual hierarchy support the user flow, does the interaction logic hold up when rendered with real design intent?
For bespoke projects, this stage involves a full custom design developed from scratch to match the brand, the audience, and the specific requirements of the project. For template-based projects, it may be a lighter pass, adapting a chosen template to match the approved structure and brand identity. In either case, the output is reviewed and signed off before development begins.
This prototype also requires client approval before development starts. Once approved, it becomes the source of truth for what gets built. Development against a reviewed and signed-off design runs more cleanly and produces fewer disputes later.
For more complex work, such as applications with significant interactivity, large-scale e-commerce, or anything with custom functionality, there may be additional stages. Interactive prototypes can test specific user journeys in detail before any code is written. For most projects, two stages cover what needs to be covered: structure first, design second.
A well-executed prototype process has consequences beyond the individual project.
When a client-approved prototype exists, with clear content, user flow, page structure, and design direction, work can be delegated cleanly. A developer or contractor receiving a reviewed prototype alongside the necessary assets has everything needed to build without ambiguity. The source of truth is explicit, and the question shifts from what is being built to how to build it.
This matters both for internal teams and for external contributors. It also makes project planning more reliable. Without a secured prototype, estimating scope, timeline, and resources accurately is difficult. With one, the unknowns are significantly reduced.
The core discipline here, test before you build, get approval before moving forward, and treat each approval as the source of truth for the next stage, is common sense applied consistently.
What makes it difficult in practice is the pull to start building. A client is enthusiastic, a deadline exists, and a prototyping stage can feel like overhead. In reality, fixing a structural problem at the prototype stage takes hours. Fixing it in a live build, after a client has seen the finished product and formed expectations about how it should work, takes days. Often longer.
Prototyping is how the real work begins properly.
