# Test the product idea before anyone builds it.

Publish a working prototype of the feature and put it in front of stakeholders and test users. They use it in a browser, and you change it between sessions at the same link.

## Why a working prototype tells you more

Specs and static mockups tend to get a yes in the meeting and surprises during the build. A working prototype with real data shows those surprises early, like the filter nobody understood or the button people couldn’t find.

The Quarry prototype above behaves like a real invoicing app, down to the VAT on a new invoice. Test users can do the whole job, start to finish.

## From idea to test session

1. **Describe the job, not the screens** “Agency owners need to see what’s overdue and chase it in one click.” Give the agent sample data that looks like your customers’ and the states you want to test.
2. **Publish it to the team first** In a team workspace, **Private** already means everyone on the team can open it. Engineers can check what’s feasible while everyone else tries it out.
3. **Share with test users** Turn on a **Secret code** for a round of sessions and switch off **Show controls** so it looks like the product. Turn the code off when the round is over.
4. **Change it between sessions** “Move Send reminder into the row and rename Draft to Not sent.” The next participant opens the same link and gets the new version.

## Learn from who used it

On secret-code and public links, **Views** counts daily views and visitors and shows where they came from. On Private and Email links you see each person by name.

> **Match notes to versions.** Each version keeps its message, so you can line up session notes with exactly what each participant saw.

## Hand it to engineering

When the idea holds up, the prototype becomes part of the spec. Put it in a project with the PRD and the flow diagram. Engineers can open the source, and their agents can read it through the same connection you used to publish.

## Limits

- Prototypes run in the browser, with no server. Use sample data, not production data.
- Pages don’t keep what testers enter between visits; each session starts from the same state.
- For a real beta with accounts and a database, deploy the product properly.

## Make your own

Have these ready:

- The job the user needs to get done
- Realistic sample data
- The states to test
- Your product’s look

Then ask your agent:

```
Build a working prototype of this feature as one self-contained HTML page
that looks like our product. Use the sample data I attach. Every control that
matters must work: navigation, filters, search, sorting, a create flow with
validation, and the states I list (empty, error, success). Totals must stay
consistent everywhere when something changes. Add a small "Prototype, sample
data" marker. On phones, use a layout that fits.

Publish it privately to artifact.guru and give me the link.
```

## Questions

### Can test users open it without an account?

Yes, with a secret code or a public link. Switch the link back to Private when the round of tests is over.

### Can our engineers reuse the code?

They can download the source from the artifact, or have their agent read it. Treat it as a reference, not production code.

Source: https://artifact.guru/use-cases/product-prototypes