A short, fixed-fee engagement that inspects the real workflow, code and constraints, then tells you whether to proceed, what to build first and how you will know it worked.
Most stalled AI and automation projects are not missing a model. They are missing a shared understanding of where the system fails, what the business can tolerate and which change would make the biggest difference. A readiness review produces that understanding in writing, before anyone commits to a large build.
The review is deliberately small. It starts from the system you already have — a prototype, a pilot, a manual process or a half-finished integration — and establishes a baseline from evidence rather than interviews alone. Where the honest answer is that an existing platform, ordinary deterministic software or no project at all is the better choice, the review says so.
Because the deliverable is a decision rather than a slide deck, it ends with acceptance criteria you could hand to any competent engineering team, including your own.
How the system or process performs today on the measures that matter — failure rate, turnaround, latency, cost or manual effort — and how each figure was obtained.
The specific components, decisions or dependencies that limit the outcome, ranked by impact and by the effort required to address them.
The smallest implementation that would change the outcome, with what is in, what is out and which existing tools or platforms should be reused rather than rebuilt.
Testable scenarios that define success, safe failure and rollback, written so another team could deliver against them.
What could not be established during the review, what would change the recommendation and who needs to answer it.
Agree the workflow, the decision the review must support, the people involved and the access route. The fixed fee is confirmed in writing before work starts.
Read the code and configuration, run or observe the workflow, collect failure cases and measure the baseline.
Separate model behaviour from system behaviour, identify the limiting components and compare build, buy and do-nothing options.
Walk through findings with the owner and engineering lead, then deliver the written report and acceptance criteria.
The demo works. Now it has to launch.
Usual first step →Stabilise an AI project that is losing confidence
Usual first step →Make a demanding workflow shorter and dependable
Usual first step →Give security something it can approve
Common follow-on →No. The report is written so that your own team or another supplier can deliver against it. Many clients do continue with a sprint, but the review is a complete engagement on its own.
Then the report explains why, with the evidence, and the fee has bought a decision that avoids a larger failed project. Recommending an existing platform, a simpler integration or no project at all is a legitimate outcome.
Usually, yes. A review can work from a staging environment, a guided walkthrough, exported logs with sensitive fields removed or synthetic examples. The report states which findings depend on that limited view.
Yes, once agreed. The range reflects how much needs inspecting. If the review uncovers a much larger system than described, we agree any change in writing before doing extra work.
Other engagements: focused engineering sprint · embedded senior ai engineering · ongoing engineering support. Compare them all on the engagements overview.
£3,000–£6,000, fixed in writing · 1–2 weeks
Ask about this engagement