# Prototype

A prototype is a working model of a product, built to test an idea with real people before you pay to build it properly. It can be drawn on paper, clicked through in a design tool, or written as a small piece of real code.

Also called: Product prototype, Clickable prototype, Coded prototype, Interactive prototype.

## In short

- A prototype exists to answer one question about a product before the expensive part starts.
- Paper and clickable prototypes test order, layout, and wording. **Coded prototypes** also test behavior and real data.
- Pick the cheapest kind that can answer the question you actually have.
- A prototype is a test with a few people. An [MVP](https://www.choie.co/glossary/mvp) is a live product that strangers use on their own.

## What a prototype is for

Every product idea rests on guesses. People will understand the first screen. They will finish signing up. The workflow matches how they already work. A prototype is the cheapest thing you can make that puts one of those guesses in front of real people while you watch.

Decide what you want to learn before you decide what to make. Testing whether users understand a pricing step needs a different prototype from testing whether a supplier's data arrives fast enough to show on screen. The question sets the type, the time, and the cost.

A prototype usually sits between a [wireframe](https://www.choie.co/glossary/wireframe), which shows what goes on each screen, and a real build. It is made to be tested and then rebuilt or thrown away, so it can cut corners that a finished product cannot.

## Paper, clickable, and coded prototypes

Prototypes range from sketches to small pieces of working software. Each step up costs more and tells you more.

- **Paper prototypes.** Screens drawn by hand or printed, with a person playing the computer by swapping sheets as the tester taps. They are good for checking that the order of steps makes sense.
- **Clickable prototypes.** Designed screens linked together in a tool such as Figma, so a tester can tap through a planned path. They look finished, which makes them good for testing layout, labels, and navigation.
- **Coded prototypes.** A small piece of real software, often a single workflow, with real inputs, real data, and real responses. They show how the product behaves when someone uses it for real.

| Type | Good for testing | Cannot tell you | Typical time |
| --- | --- | --- | --- |
| Paper | Whether the steps and content make sense | How the design looks or feels to use | Hours |
| Clickable | Layout, wording, and navigation on a planned path | What happens off that path, or with real data | A few days |
| Coded | Real behavior, speed, data, and edge cases | Whether strangers will keep using it for months | One to two weeks |

Clickable prototypes have one blind spot worth knowing about. Testers can only go where the designer drew a link, and every list is filled with tidy sample data. Problems that appear when someone types a long name, uploads the wrong file, or waits for a slow response stay hidden until code exists. That gap is why Choie's prototypes are coded with real behavior instead of drawn as a Figma mockup.

## When a coded prototype is worth it

A coded prototype costs more than a clickable one, so it earns its place when the risk sits in the behavior. That usually means one of these situations.

- The core workflow depends on live data, an outside service, or AI output that you cannot fake convincingly.
- Testers need to do real work in it, such as entering their own records or finishing a task they would normally do in a spreadsheet.
- You want investors or early customers to use the product with their own hands instead of watching a demo.

If the risk is about understanding, such as confusing labels or an unclear first screen, a clickable prototype answers it faster and for less. Either way, run the sessions as [usability tests](https://www.choie.co/glossary/usability-testing) and give what people do more weight than what they say.

## How a prototype differs from an MVP

The two get confused because both come early and both are small. A prototype is a test instrument, used by a handful of people in sessions you set up. An [MVP](https://www.choie.co/glossary/mvp) is a live product that strangers sign up for and use without you in the room.

**Diagram: Prototype and MVP side by side.**

**Prototype**
- Tested in sessions you run
- Sample or limited real data
- Shortcuts in the code are fine
- Answers one question
- Usually rebuilt afterward

**MVP**
- Used by strangers on their own
- Real accounts and real data
- Built to be maintained
- Does one real job end to end
- Grows into the product

_Many teams prototype the riskiest workflow first, then build the MVP with the answers in hand._

Prototype first when the riskiest guess can be tested without a full build. Go straight to an MVP when the problem is well understood and the open question is whether people will keep using it.

## Common mistakes

- **Prototyping without a question.** A polished prototype that tests nothing in particular is a design exercise. Write the question down first.
- **Testing with the wrong people.** Colleagues and friends know too much about the idea and are too kind about it.
- **Shipping it as the product.** Prototype shortcuts turn into [technical debt](https://www.choie.co/glossary/technical-debt) the moment real users depend on them.

## Prototyping with Choie

Choie builds [one-week coded prototypes](https://www.choie.co/services/coded-prototype) of one critical workflow, with real behavior, for a fixed $4,900, with no tax added on top. The fee is credited in full against a build that starts within 60 days, and the same people design the prototype and write its code. The [pricing page](https://www.choie.co/pricing) has the details.

## Common questions

### How long does it take to make a prototype?

Anywhere from an afternoon to two weeks, depending on the type. A paper prototype takes hours, a clickable one a few days, and a coded prototype of one workflow usually a week or two.

### Is a prototype the same as a wireframe?

No. A wireframe is a static layout that shows what goes on a screen. A prototype adds interaction, so someone can move through it and try to complete a task.

### Can a coded prototype become the real product?

Sometimes, but plan as if it will not. Prototype code is written to answer a question quickly and often skips the security, testing, and structure a production build needs. The design and the data model are what usually carry over.

### Who should test a prototype?

People who match the user you are building for, ideally ones who have the problem today. Colleagues are a poor substitute because they already know how it is meant to work. Choie's prototype week does not include recruiting testers, so founders put the finished prototype in front of their own users after delivery.

Related: [Minimum viable product (MVP)](https://www.choie.co/glossary/mvp), [Wireframe](https://www.choie.co/glossary/wireframe), [Usability testing](https://www.choie.co/glossary/usability-testing), [User flow](https://www.choie.co/glossary/user-flow), [Product discovery](https://www.choie.co/glossary/product-discovery).

HTML: https://www.choie.co/glossary/prototype