Our process
Boring on purpose
AI work fails in ways ordinary software does not — quietly, plausibly, and often only under real traffic. Our process is built to surface those failures early, while they are still cheap.
Define what correct means
Before writing anything, we work out what the system has to get right and what it costs when it gets it wrong. Those two answers decide almost every technical choice that follows.
We look at the actual workflow — the spreadsheets, the copy-paste, the thing someone checks twice on a Friday — and identify where a model genuinely helps. Often part of the answer is that a query or a rule would do the job better, and we say so.
- Workflow mapping
- Feasibility assessment
- Success criteria
- Failure-cost analysis
- Data readiness review
- Build-versus-buy call
Build behind gates
We build the narrowest useful version first and put it in front of real users early — but never with unguarded write access. Every action the system can take is an explicit, typed tool, and high-consequence ones are gated in your backend where a model cannot argue with them.
The evaluation suite is built alongside the feature, not after it. That means from the first week you can answer whether a change made things better, which is the difference between iterating and guessing.
- Typed tool design
- Server-enforced approval gates
- Tool + argument evals
- Multi-provider routing
- Cost metering
- Weekly demos
Measure, then hand over
Going live is where the useful data starts. We export real transcripts, redacted of personal data, and do open-coded error analysis on what people actually did — which is reliably different from what everyone predicted in the kickoff.
Those failures get named and written down as a taxonomy your team can use. Once a failure has a name it can be counted, prioritised and argued about productively instead of being described as “the AI being weird sometimes”.
- Measured before and after
- Failure taxonomy
- Handover documentation
- Ongoing support
Why this process
AI projects fail in predictable ways
Each phase above exists to prevent a specific failure we have watched happen — usually to someone who did the demo first and the thinking afterwards.
The impressive demo that never ships
A prototype that works on five hand-picked examples meets real inputs and collapses. Defining success on real data first is what stops this.
Nobody can tell if it improved
Without evals, every prompt change is a matter of opinion. Teams eventually stop touching the system out of fear.
The unbounded bill
An AI feature with no cost metering is a variable expense you discover monthly. Metering belongs in the first version.
Locked to one provider
Hardcoding a model means a deprecation or a price change becomes an emergency. Configuration and fallback ordering make it a Tuesday.
The agent that did something bad
Write access without server-enforced gates is the single fastest way to a serious incident. Prompts are not a security boundary.
AI applied to the wrong problem
Some things want a database query, not a language model. The audit exists partly so we can tell you that cheaply.
Next step
Tell us what you’re trying to build
Most engagements start with a fixed-price audit, so the first thing you buy is a decision rather than a commitment.