When there's a promising idea, the usual path is to document requirements, get quotes and commit to a build. That makes sense for well-understood problems. For anything genuinely new, it can lock in assumptions before anyone has tested them.
What a prototype proves
A focused prototype puts something real in front of the people who would use it. It tests whether the idea solves the problem, whether the data behaves as expected and whether the integrations are as simple as they looked on paper. It turns opinions into observations.
What it doesn't prove
A prototype that works in a demo is not a production system. Before anything goes live, there's still real work to do:
- Security: access control, data protection and how credentials are handled.
- Reliability: what happens under real load, with bad data or when a connected system is down.
- Ownership: who owns the system, the data and the decisions about changing it.
- Testing: repeatable checks that it still works after every change.
- Support: who fixes it at 7am on a Monday, and how they know something is wrong.
Decide stop or go before you start
The most useful thing you can do is agree up front what result would justify going further, and what would mean stopping. Writing it down before you see the results keeps everyone honest.
- Question
- Can incoming enquiries be sorted to the right team accurately enough to save time?
- Scope
- Two weeks, last quarter’s anonymised enquiries, no live customers
- Go
- At least 85% routed correctly, with every enquiry reviewed by a person, no urgent or high-consequence enquiry missed in the evaluation, and checking demonstrably faster than sorting manually
- Stop
- Below 70% routed correctly, any urgent or high-consequence enquiry missed in the evaluation, or reviewers spending longer correcting than they did sorting manually
- Otherwise
- Investigate where it struggles before spending more
These figures are illustrative, not a general standard for AI accuracy. Agree the thresholds, test sample and consequences of different errors before starting. A 'go' result supports further work; it does not approve unattended routing or prove the system is ready for production.
Some prototypes confirm the idea and speed up the full build. Others point to a better direction or show the problem sits somewhere else. Both are useful, and both are far cheaper to learn early.