Services
From trying AI
to trusting it.
Identify, develop, adopt.
Every engagement runs the same three phases. We find the few things worth building, develop one of them properly, then stay until your team is actually using it.
You are not buying a discovery phase that ends in a slide deck. Identify takes days and ends with a written build plan and one fixed fee. If nothing there is worth building, that is the finding, and you have spent days rather than a quarter learning it.
How the work runs
Identify
Decide what is worth building before anyone builds it.
Most of what gets pitched as an AI project is not worth building. This phase finds the 5% that is. We follow how the work actually happens: where the hours go, which decisions sit waiting on one person, and what breaks first when volume doubles. Then we pick one constraint and size it honestly, in terms you already track. You leave with a build plan, a fixed fee, and a written definition of what done looks like.
What that looks like
- Working session
- Two hours with the people who own the work, to agree where it actually jams.
- Process walkthrough
- We follow one workflow end to end and write down every handoff, wait, and manual step in it.
- Opportunity sizing
- Hours, volume, and error rate as they stand today, against what the same work costs once a system does it.
- Build plan
- What gets built, the data it needs, the integrations, and the checks that decide when it is finished.
- Fixed quote
- One fee for the whole build, agreed before any of it exists.
Where this phase did the work
The whole build came down to one decision made in this phase: what order to check things in. Plumbing before symptoms. Everything else followed from that.
Develop
Ship something that runs in production, not something that demos well.
Development starts the week the plan is signed off. It runs in short passes against your real data and the tools your team already opens, because a system that only works on a clean sample is not a system. Anything that spends money, reaches a customer, or cannot be undone stops and asks a person first. You see it working while it is being built, which is early enough for your feedback to change it. No demo that falls over on the first real case. No pilot that lives on somebody’s laptop.
What that looks like
- Data and access first
- The rules, records, and history a system needs in order to be right go into one place before any agent reads them.
- Integrated into your stack
- It runs inside the tools your team already uses, not beside them.
- Human checkpoints
- Every step that moves money or sends something out stops and asks.
- Evaluation set
- A fixed set of real cases the system is scored against on every change, so a change that made it worse is caught the same day.
- Weekly working builds
- Something you can use every week. Nothing goes dark for a month.
Where this phase did the work
The database came before the agents. Rules, accounts, personas, and what had already worked, written down first, so the agents had something to be right against.
Adopt
Make it how the work gets done, not a thing that exists.
Shipping is not the result. A system nobody trusts gets worked around within a fortnight, and the work quietly goes back to how it was. So this phase is about use. We train the people who will actually run it, sit with them while they do, and fix the things that only surface once real work meets it. We watch what it does in production and tune what it gets wrong. At 90 days we check it against what we agreed at the start, using the same method. If it did not do what we said, the build failed, and we say so in those words. By the time we step back it is not a project any more. It is just how the work gets done.
What that looks like
- Baseline on the record
- The before figure is written down in the first phase, so there is nothing to argue about at the end.
- Team training
- Hands-on sessions with the people who will use it: what it does, where it stops, and how to tell when it is wrong.
- Production monitoring
- Every run is logged. When something goes wrong you can see which step, on which input, and why.
- Tuning passes
- Accuracy, speed, and cost get worked on against real use rather than guessed at in advance.
- Handover and runbook
- How it works, how to change it, how to switch it off. Written down, in your repository.
- The 90 day read
- Same figure, same method, measured again. One page, and an honest verdict.
Where this phase did the work
The hours saved were the easy part. What mattered was whether anybody changed what they did because the report arrived on a Monday.
Pricing
Fixed scope. Fixed fee.
One price, agreed in writing before the build starts, that does not move because the work took longer than planned. An estimate that drifts is an estimating problem, and it is ours to carry rather than yours to absorb.
No hourly billing
You are buying a working system, not somebody’s time. Working faster should not cost you more.
No overrun charges
If the build runs long, the fee is still the fee. That risk sits on this side of the table.
No surprise invoices
The only thing that changes the price is you asking for something that was not in the plan, and you approve that before it starts.
You own the system
Code, prompts, evaluations, and documentation land in your repository, on your accounts and your keys. Run it, change it, or hand it to someone else without asking.
There is no price list here, because the fee depends on what you are trying to move. Give a budget band on the next page and you get a straight answer on whether it is workable, usually the same day.
Start
Tell us what keeps not getting done.
One form, three minutes. A person reads it and replies with an honest read on fit, including a straight no if this is not the right work for you.
Start a project