The point of a prototype is to kill or confirm an idea before it consumes a roadmap. I build the smallest working thing that answers the real question, and I tell you what it actually proved.
A prototype is an experiment, not a small version of the product. It exists to answer one uncomfortable question: will the model be good enough at this job, will anyone use it, and is the thing underneath it feasible at all?
That framing changes what gets built. Auth, billing, admin panels, and scale are deliberately skipped. What is not skipped is the part the answer depends on — usually the model behaviour on your real data, with real users touching it.
Picked by which question you actually need answered.
Can a model do this job on your data at an acceptable quality and cost? Built against real inputs, measured, and reported with the failure cases included.
A real interface on a real pipeline that you can put in front of users, a design partner, or an investor without caveats about what is faked.
An end-to-end agent doing the loop it would do in production, instrumented so you can see where it succeeds and where it breaks.
A test set and scoring setup so "is it good enough?" becomes a number you can track, rather than an argument in a meeting.
Write down the single decision this prototype informs and what result would change your mind. If we cannot write that down, building is premature.
Everything not serving that decision is explicitly deferred, in writing, so scope creep has to be a deliberate choice.
Synthetic demos hide exactly the problems you need to find. The prototype runs on your actual inputs, including the messy ones.
Real users or a design partner, with the behaviour instrumented so what happened is observable rather than remembered.
What it proved, what it did not, what the failure modes were, and a recommendation — including "do not build this" when that is the answer.
| In scope | Deliberately out of scope |
|---|---|
| The core model or agent behaviour | Production auth, roles, and billing |
| A real interface users can touch | Scale, load testing, and HA |
| Your real data, including edge cases | Full admin tooling |
| Instrumentation and evals | Polished visual design system |
| An honest written recommendation | Long-term maintenance commitments |
Have the decision, the data, and the users lined up. A prototype with no real data to run on, or nobody to show it to, produces a demo — which feels like progress and answers nothing.
A clearly stated decision the prototype will inform, access to representative data (even a messy export), and a handful of people who will actually try it. Those three things determine the timeline more than anything I do.
Prototypes are scoped and priced individually against that decision, not sold as a fixed package — the whole point is to buy the smallest thing that answers your question, and that size differs every time.
If the prototype says build, we talk separately about what production would take. Nothing about the prototype engagement commits you to continuing with me.
The build is rarely the bottleneck. What moves the date is how quickly you can give me representative data, system access, and people to test with, and how tightly the question is defined. A sharp question with data ready moves fast; a vague one with data still being exported does not. Tell me the specifics and I will give you a real range.
Usually not, and that is intentional. Prototype code optimises for learning speed, not maintainability. Some parts — evals, prompts, data handling — often carry forward; the scaffolding around them normally should not.
That is a successful outcome. Finding out in weeks, for the cost of a prototype, is much cheaper than finding out after a year of roadmap. You get a written account of why, which is usually reusable for the next idea.
Larger consultancies bring multidisciplinary teams and are built for sustained delivery alongside your engineers. This is one engineer, a tighter scope, and less coordination overhead — better when the goal is a fast answer to a specific question, worse when you need a staffed team for months.
Helpful but not always required. Someone who can grant access to data and systems, and answer domain questions quickly, matters more than engineering time.
Agreed in writing before work starts, and built in your accounts and repositories from day one so there is nothing to extract later. Ask and I will explain how I usually structure it.
Tell me the decision you are trying to make and what data exists today. I will tell you whether a prototype is the right way to answer it.
Get in touch →Got an idea, question, or just want to say hi?