00Guides

Shipping an AI prototype real users can test

A prototype is an experiment. It is worth building only if it can change a decision, and that decides what you build.

What makes a prototype worth building.

A prototype teaches you something when it is a working application deployed on day one, with real authentication, data and model integration, instrumented against a decision you have agreed in advance. Anything that does not inform that decision is out of scope.

01

Scope to the one decision it must inform

Name the riskiest assumption the prototype exists to test. The build scope is then everything that assumption needs to be exercised by a real user, and nothing else.

Most prototype sprawl comes from building the parts that are comfortable rather than the part that is uncertain. Decide the question first and the scope follows from it.

02

Production code from the first commit

Throwaway code produces a throwaway result. If the prototype works, you want to keep building on it, so it should be typed, deployed and using real data from the start.

Production code is what makes the result something you can act on, and what carries the work forward if you continue. Because the prototype is a real deployment built search-led, it is already the start of the product and can begin being found while you decide its future.

03

Integrate AI properly and state the limits

Model output is non-deterministic. A credible prototype builds the guardrails, logs inputs and outputs, and shows the failure modes rather than demoing only the happy path.

What you are testing is how the feature behaves in real hands, including when the model is wrong. That behaviour is the result.

04

Instrument the test before you run it

Define the events that answer your question and put them in before launch. Without instrumentation a prototype produces opinions and anecdotes rather than a result.

05

Agree the keep-or-kill criteria up front

Decide, before users touch it, what result means continue and what means stop. Criteria set after the fact get rationalised to fit what you hoped for.

Common mistakes

What stops a prototype from producing a usable answer.

  • A clickable mock-up that proves the screens, not the assumption.
  • Scope creep into the comfortable parts and away from the uncertain one.
  • No instrumentation, so the test yields opinions.
  • Treating LLM output as deterministic and demoing only the happy path.
  • No keep-or-kill criteria agreed before the test.

Where this connects

The service and the answers that go with this guide.

Have a concept to validate?

Tell us the decision the prototype needs to inform. You get a fixed scope before anything starts.