Types of Software Prototypes: Choose the Right One Before Development

01

One word can describe several very different things

Ask three people to make a software prototype and you may receive three completely different results. A designer might create linked screens in Figma. A developer might write a small coded experiment. A director might expect something polished enough to show customers or investors. All three can be reasonable, but only if they answer the question the business actually has.

This is where prototype work often goes wrong. The team begins by choosing a tool or asking how many screens it needs. It should begin by naming the uncertainty. Do we understand the journey? Can users complete the task? Will the integration work? Can the technical approach handle the awkward rule? Are decision makers imagining the same product?

The best prototype is not the most impressive one. It is the least expensive credible way to turn an important assumption into evidence. Sometimes that is a sketch made in an afternoon. Sometimes it is a coded model that takes several weeks. The type follows the decision, not the other way around.

02

Low fidelity prototypes explore structure quickly

A low fidelity prototype can be a paper sketch, a rough wireframe or a simple sequence of boxes and links. It deliberately avoids the visual finish of the intended application. That roughness is useful because people are more willing to challenge an unfinished idea than a screen that already looks approved.

Use this type when the important questions concern order, content and responsibility. A business planning a claims portal might sketch how a customer starts a claim, what information is requested and where the case moves next. The team can compare several routes before anybody spends time polishing colours, components or animations.

Low fidelity work is also good for finding disagreement. One person may assume customers choose a product first while another expects the system to identify it from a policy record. Drawing both routes makes that difference visible. The prototype has done useful work even if none of its screens survive.

Its limit is realism. A rough wireframe cannot prove that detailed content fits, that an interaction feels natural on a phone or that somebody unfamiliar with the project can complete the journey. It should lead to a decision or the next level of testing, not become a vague design phase that continues forever.

03

Clickable prototypes test journeys and understanding

A clickable prototype connects designed screens so a person can attempt a task. It may contain realistic labels, representative records, validation messages and different states while still using no live database or production integration. Tools such as Figma make this useful middle ground relatively quick to create and change.

This type suits questions about navigation, comprehension and user flow. Can a customer find the right action? Does a reviewer understand why a case is waiting? Can a manager move from a summary to the records behind it? A participant should be able to try the task instead of watching the designer demonstrate the happy path.

The danger is that a convincing surface can look more complete than it is. A clickable dashboard may show totals that were typed into the design. A successful upload may only move to another screen. None of that proves that permissions, calculations, storage or integrations work. State clearly what is simulated so approval does not become based on fictional technical progress.

04

Coded prototypes make selected behaviour more realistic

A coded prototype behaves more like a real application. It may accept form input, apply a business rule, use sample records or connect to a controlled test service. This can be the right choice when a static design cannot reproduce the interaction that needs testing.

Consider an internal pricing tool with several dependent questions. The route changes as answers are entered, calculations update and some combinations require manual review. A coded prototype can let staff use representative cases and expose where the logic is unclear. It can also test whether the experience works across common devices and browsers.

Realistic behaviour creates a serious boundary to manage. Prototype code is written to learn quickly. It may not include production security, accessibility, error handling, monitoring, automated tests or the structure needed for years of change. GOV.UK guidance makes the same point plainly: prototype code should not simply be copied into a live service.

Before work begins, decide whether the code is disposable or expected to evolve. If it is disposable, protect the team from pressure to launch it. If it may continue, give architecture, quality and ownership more attention from the start and be honest about the extra cost.

05

A proof of concept tests technology, not the whole product

A proof of concept is a focused technical experiment. Its job is to find out whether one uncertain approach is possible enough to justify the next investment. It may test an old system connection, document extraction, response time, a hardware link or whether sample data is good enough for a proposed model.

This is different from testing whether somebody understands a user journey. A proof of concept may have an ugly interface or no interface at all. That is acceptable when the evidence sits in the technical result. The mistake is using a successful experiment to claim the whole business product has been validated.

Suppose a team proves that an AI service can extract ten fields from a sample document. Useful questions remain. How often is it wrong? What happens with poor scans? Which results need human review? Is the data allowed to leave the organisation? How will the cost change at real volume? The proof reduces one uncertainty and should reveal the next ones.

06

Throwaway and evolutionary prototypes need different rules

Prototype types can also be described by what happens after the learning. A throwaway prototype is built to answer a question and then discarded. This gives the team freedom to take shortcuts because the result is knowledge, not reusable software. Rapid sketches and many clickable designs belong here.

An evolutionary prototype begins with a deliberately narrow working base and is refined towards the real product. That can suit a difficult operational system where learning continues through use, but it changes the standard of the early work. Data structure, access control, deployment and testing cannot all be treated as temporary if the same foundation will remain.

The middle ground is risky. A prototype starts as disposable, gains a few convincing features and is suddenly called the first release because rebuilding feels wasteful. The hidden shortcuts then become production constraints. Decide the intended fate early and review it whenever the project crosses from learning into live responsibility.

07

Prototype a complete task and test it without coaching

A gallery of screens can avoid the difficult moments between them. Choose one valuable task with a clear beginning and outcome. For a customer portal, that might run from opening a new request to supplying the required evidence and understanding what happens next. For staff, it might run from receiving that request to deciding, querying or approving it.

Use representative information, including an awkward example. Empty cards and perfect records make most systems look simple. A realistic long address, missing document, duplicate customer or unusual permission exposes the decisions that polished sample data hides.

Then put the prototype in front of people who represent the real users. Give them a task and allow them to hesitate. Do not explain each control before they reach it. Watch what they expect, where they stop and which words mean something different to them. Several people struggling at the same point is stronger evidence than a meeting room saying the design looks good.

Record what was observed, what changed and what remains uncertain. A prototype earns its value through the decision record it creates. Without that record, the organisation can repeat the same debate during development and lose the benefit of testing early.

08

Do not confuse a prototype with an MVP

A prototype is normally a learning tool. A minimum viable product is a live product with enough dependable capability to deliver value and gather evidence from real use. The letters MVP do not mean a prototype with a login screen, and they do not excuse weak security, missing backups or unreliable data.

The distinction affects cost and responsibility. A prototype can use sample data, simulate an email and ignore rare failure states if those choices are documented. An MVP handling customer information needs appropriate security, support, monitoring, recovery and legal care even when its feature set is deliberately small.

A sensible path may move from sketches to a clickable journey, then to one technical proof and finally to a production first release. Not every project needs every stage. Each stage should exist because it resolves an uncertainty that would otherwise make the next commitment unsafe.

09

Finish with a decision, not a demonstration

The end of prototype work should leave the business able to continue, change direction or stop. Summarise the question tested, the people involved, the evidence observed, the assumptions still open and the production work not represented by the prototype.

If the idea continues, translate the learning into a first useful scope. Identify the essential users, rules, data and integrations. Separate confirmed requirements from later possibilities. Run a technical investigation where an uncertain dependency still affects price or feasibility. This gives developers a stronger starting point than a folder of polished screens and meeting notes.

A prototype is worthwhile when it changes the quality of a decision. It can save a business from building the wrong route, expose a smaller solution or give enough confidence to fund the next phase. The aim is not to remove all uncertainty. It is to remove the uncertainty that would make the next commitment reckless.

If you are shaping a portal, internal system or new software idea, I can help choose the smallest useful prototype, test the important journey and turn the findings into a clearer development decision.