Prototype Sprint
One bounded prototype, built to answer one question
A demonstration is not a system, and it should not be sold as one. A sprint builds the smallest thing that proves whether an approach works against your own data – with the acceptance criteria agreed first, so the answer is defensible either way.
- Acceptance criteria agreed first
- Built against your own data
- Production explicitly not included
- Who it is for
- Teams who need evidence before committing to a full implementation
- The unit
- One bounded prototype against agreed data, formats and acceptance criteria
- What it ends with
- A demonstration, tests, and a written read on whether to proceed
- Production
- Explicitly not included. A prototype that ships unchanged is a liability
When a sprint is the right step
When the honest answer is "we do not know yet"
A sprint is worth running when a real decision hangs on a question that argument will not settle.
A board wants evidence, not a slide
Approval depends on showing that the approach works on the company's own material, not on a vendor's curated demonstration.
Two approaches, no clear winner
The team is split, both options are plausible, and the disagreement has outlasted its usefulness. Build the smaller one and look.
Nobody knows if the data supports it
The idea is sound in principle. Whether your actual records carry enough signal to make it work is an empirical question.
A vendor claim needs testing
A platform promises it handles your case. A sprint against your own examples establishes whether that survives contact with reality.
The scope keeps growing
Every conversation adds a requirement. A bounded prototype forces the question of what the thing actually has to do.
An earlier attempt stalled
Something was built, it impressed people, and it never reached production. A sprint with acceptance criteria establishes what was missing.
What you get
Evidence you can take to a decision
A sprint ends with something you can show people, and an honest read on what it did and did not establish.
- 01
The working prototype
Running against the agreed data and formats, yours to keep.
- 02
A live demonstration
Walked through against real examples, including the difficult ones.
- 03
Results against the criteria
Measured against what was agreed before the build, pass or fail.
- 04
The code and its tests
Handed over, with what is solid and what is scaffolding made clear.
- 05
A written recommendation
Proceed, change approach, or stop – with the reasoning.
- 06
What production would require
An honest read on the distance between this and a system you can rely on.
Scope
A prototype is a prototype
Being explicit about this is the point. The most expensive AI mistakes start with a prototype that someone decided was nearly production.
Included
- One bounded prototype against agreed data and formats
- Acceptance criteria agreed in writing before the build
- A demonstration against real examples, including edge cases
- Tests covering the agreed criteria
- Handover of the code and what was learned
- A written recommendation on whether to proceed
Not included
- Production hardening, monitoring or incident cover
- Integration with live systems beyond what the demonstration needs
- Security, compliance or penetration review
- User training or change management
- Ongoing development after the sprint ends
- Any promise that the prototype is safe to put in front of customers
Anything on this side is scoped and priced on its own, once the shape of it is clear. Submit a use case →
How it runs
Bounded at both ends
The boundaries are the product. A sprint without agreed acceptance criteria is just an unbilled argument about whether the result was good enough.
- 01
Submit the use case
What the prototype should demonstrate, what data exists to demonstrate it against, and what decision the result will inform. If the question is not answerable this way, we say so.
- 02
Agree the boundary and the test
What is in, what is explicitly out, which data and formats are used, and what result would count as success – written down and agreed before the build starts.
- 03
Build the prototype
The smallest thing that answers the question honestly. Not a production system, not a foundation to extend – a piece of evidence.
- 04
Demonstrate it against real examples
Including the awkward ones. A prototype shown only on the examples it was tuned against has not established anything.
- 05
Test it against the criteria
Measured against what was agreed at the start, including where it fails. A clear negative is a successful sprint.
- 06
Hand over and recommend
The code, the tests, what was learned, and a written read on whether to proceed – including what a production version would actually require.
Against the alternatives
A demonstration is not a system, and it should not be sold as one.
A sprint builds the smallest thing that proves whether an approach works against your own data – with the criteria agreed first, so the answer is defensible either way.
| A vendor demo | A full build straight away | This sprint | |
|---|---|---|---|
| The data | Theirs, or a tidy sample | Yours, once it is built | Yours, agreed up front |
| What it proves | That it can look good in a meeting | Whether it worked, after the spend | Whether the approach works, against criteria agreed first |
| Production | Not addressed | Everything at once | Explicitly not included; what it would require is written down |
| What you keep | A recording | The system, whatever it turned out to be | The prototype, its code and tests, and a written recommendation |
Evidence
The sprint is the evidence
This is the one service where the proof is the deliverable rather than something we have to ask you to take on trust. There are no client prototypes published here – they are not ours to show – but the whole point of a sprint is that at the end of it you are looking at your own data going through the thing, measured against criteria you agreed in advance. If it does not meet them, that is the finding, and it is still worth what it cost compared with discovering it in month four of an implementation.
Daniel Rondeau
The person on the call, and the person making the decisions.
Daniel on LinkedIn →Ask on the fit call how a decision like yours has been approached before.
What it costs
No price list. A written scope for one bounded question.
How bounded the question really is, how much work the data needs before it can be used at all, how many formats have to be handled, and how much integration the demonstration requires to be convincing. Submitting a use case produces a written scope with a figure attached, before anything is committed.
Before you book
The questions that usually come first
Can we put the prototype into production?
Not as it stands, and we will not say otherwise to close a sale. A prototype is built to answer a question, not to survive real traffic, bad input, or a bad day. What it does give you is a well-informed scope for the production version.
What if the prototype fails?
Then it did its job. A clear negative against criteria you agreed in advance has saved you an implementation budget, and the written recommendation will say what would have to change for the approach to become viable – or that it will not.
How long is a sprint?
Short enough that the answer arrives while the decision is still live – the exact window depends on how bounded the question is and how ready the data is, and it is agreed in the written scope before the build.
Do we own the code?
Yes. The prototype and its tests are handed over at the end, with an honest note about which parts are solid and which are scaffolding that exists only to make the demonstration run.
Can you use our real data?
Redacted samples are usually enough and are the default. Where the question genuinely cannot be answered without something closer to production data, that is raised in scoping and decided by you, in writing.
What if we want to keep going afterwards?
Then implementation is scoped separately, informed by what the sprint established. There is no obligation, and taking the prototype and its recommendation to someone else is a legitimate outcome.
Not the right engagement? The others
Start with a conversation
Bring the question the arguing has not settled
What the prototype would have to show, and what decision the result informs. If a sprint is not the right way to answer it, you will hear that.
Pick a time that suits you. Or write to daniel@gotai.com