What Is a Working Prototype?

These terms are often used interchangeably, but they refer to different things at different stages of a project.

A wireframe is a sketch of the layout. It shows where elements will go on the screen — navigation here, content there, button at the bottom. Nothing works. It is a blueprint, useful for agreeing on structure before anything is built.

A mockup is a wireframe with visual design applied. It looks like the finished product but still does not function. You can see the colours, typography, and spacing. You cannot click a button and have something happen. Mockups are design tools, not engineering tools.

A proof of concept (PoC) answers a specific technical question: "Can we do this?" A PoC for an AI pricing engine might be a script that takes vehicle data and returns a price. It has no interface, no user flow, no polish. It proves the technology works. It does not prove the product works.

A working prototype sits above all three. It has an interface you can use. It connects to real data sources. The core logic runs end to end. You can enter a vehicle registration and get a real price, or upload a photo and get a real shade match. The edges are rough — error handling may be incomplete, the design may be basic, edge cases may not be covered — but the core path works.

A working prototype changes the conversation from "what do you think this should do?" to "does this actually do what you need?" Stakeholders can interact with it, test it against their own knowledge, and give feedback based on experience rather than imagination.

This matters because specification documents are unreliable. People describe what they think they want. When they see it working, they often realise the actual need is different. A prototype surfaces these misunderstandings in days rather than months. The cost of changing direction at the prototype stage is a fraction of the cost of changing direction after a full build.

A working prototype also reduces risk for both sides. The client sees real output before committing to a full project. The developer validates technical assumptions before building on them. If the prototype reveals that the approach does not work, the loss is a few thousand pounds and two weeks — not tens of thousands and six months.

At NikkSi, every project starts with a working prototype delivered in 2 weeks. The first few days are spent understanding the problem and gathering data. The remaining time is spent building a functional version of the core feature — the pricing engine, the shade matcher, the matching algorithm — that the client can test with real inputs.

The prototype is not a demo with fake data. It connects to real data sources, runs real logic, and produces real outputs. If the project is a pricing engine, you can enter an actual registration number and see an actual price. If it is a property matcher, you can swipe through actual listings.

The purpose of the 2-week prototype is to answer one question: does this work for your business? If the answer is yes, the full build continues with confidence. If the answer is no, you know early and cheaply. Either way, you have a concrete artefact to evaluate rather than a specification document to imagine.