Ways to start
Pilot builds
A pilot that cannot fail is not a pilot, it is a first instalment. Ours states in the proposal what result would make us recommend stopping — before the work starts, in writing.
How it works
The structure
- One task. The single automation most likely to pay for itself, not a platform.
- A stated threshold. Written into the proposal: the accuracy, time saved or cost per run below which we say stop.
- A fixed price and a fixed window. Both agreed before starting.
- A real measurement at the end against the threshold, using the evaluation set, not an impression.
Why put the kill criterion in writing
Because otherwise every pilot succeeds. Without a number agreed in advance, the result is always interpreted favourably by the people who built it — that is not dishonesty, it is how anyone reads their own work.
Naming the threshold first also forces a better conversation at the outset. Deciding what "good enough" means for your task is genuinely the hardest question in the project, and doing it before the build is far cheaper than after.
What happens if it fails
We tell you, and we recommend stopping. You keep the code, the evaluation set and the documentation, and you have spent a small fixed amount to find out something true. That is a good outcome, and it is considerably cheaper than the alternative, which is discovering it after a full build.
Where it fails for a fixable reason — the data was not there, the task was scoped too broadly — you get that reasoning too, and can decide whether closing the gap is worth it.
What happens if it works
The pilot is production code, not a prototype to throw away. It runs on your accounts from day one. Extending it is a normal fixed-price build, and the measurement from the pilot becomes the baseline for ongoing monitoring.
Want to test the idea before committing? Tell us the task. We will propose a pilot with the threshold stated up front — including what result would make us tell you to stop.
Get your free review