Skip to content

Proof in Production

One use case, actually running.

The scan, then the build. A single use case taken from idea to something your people genuinely use, with the integration and the documentation that make it survivable after I leave.

The problem

Pilots are where AI projects go to be admired.

The usual failure is not technical. A pilot works, everyone is pleased, and then it never crosses into the systems people actually work in, because the last fifth of the job is integration, permissions, error handling and the unglamorous question of who fixes it at four on a Friday.

So this engagement is defined by where it ends rather than by what it demonstrates. Running, in your business, used by the people it was built for, documented well enough that someone else could take it over.

What you get

A

One use case, built

Chosen for being worth it and finishable, not for being the most impressive thing on the roadmap.

B

Integration

Into the systems your people already work in. A tool that lives in a separate tab is a tool that gets used for three weeks.

C

Documentation

What it does, what it assumes, how it fails, and what to check first. Written for whoever inherits it.

D

A handover

To your team or your supplier, with the access, the runbook and a conversation rather than a zip file.

E

The running cost

What it will cost per month to keep alive, stated before you commit rather than discovered afterwards.

How it runs

Six to eight weeks. Usually the second engagement rather than the first.

01

Scope hard

One use case, with an explicit list of what is out. Most overruns are scope that was never written down as excluded.

02

Build in the open

Working software early and often, so the disagreements happen while they are cheap.

03

Put it in front of people

Real users, real data, real failure modes. The first contact with actual work is where the design gets corrected.

04

Hand over

Documentation, access, runbook, and a named person on your side who can answer for it.

What this looks like

One client build, and the products I run myself.

What it costs

EUR 45,000 to 65,000

Fixed fee, six to eight weeks, remote

A range, because the integration decides it.

The spread is not vagueness, it is the difference between a use case that touches one system and one that has to reconcile four. Where you sit in the range is settled at scoping, before anything starts, and then it is fixed.

If a scan has already run, scoping is short. If it has not, expect the first week to do that work.

Fit

Usually the second engagement.

This works when the use case is already chosen and defensible, which is why it normally follows a scan. Commissioning a build before deciding what the build is for is the most expensive way to learn what it was for.

It is a poor fit if what you actually want is a demonstration for a board. That is cheaper and faster as a prototype, and I will tell you so.

Common questions

Who owns the code?
You do. Handed over with documentation and access, with no dependency on me continuing.
What if it turns out not to work?
Then we find out in week two or three rather than week eight, because it is in front of real users early. A use case that dies early has saved you the rest of the fee.
Do you work with our existing developers?
Yes, and it usually goes better. They know the systems and they are the ones who will hold it afterwards.
Is the running cost included?
No, and it is stated up front. Model usage, hosting and any licences are yours, and I will tell you roughly what to expect per month before you commit.

Worth starting when you know which use case, and you want it in production rather than in a slide.

Start a conversation