The point is that you can keep changing it after we go.
An eight to twelve week program that puts a working AI development capability inside your existing engineering organisation — the environment, the guardrails, and the practice of using them.
The thing you are actually worried about.
Not that the vendor will fail. That the vendor will succeed, hand over something impressive, and leave — and eight months later a model gets deprecated, or a prompt starts behaving differently, or someone needs one field added to an output, and nobody on your payroll can safely touch it.
Then it either freezes, or you are back on the phone to the vendor at their day rate, permanently, for a system you paid to own. That is a very common way for this to end and it is rarely anyone's stated plan.
So the program is built backwards from that. If your engineers cannot maintain it without us, it did not work — regardless of what it does in a demo.
How the program runs.
Three phases. Your engineers are in all three, doing the work, not watching it.
Weeks 1–2 — What you already have
Your cloud, your data boundaries, your review and release process, and what your engineers are already comfortable with. This is deliberately unglamorous and it is where the schedule is actually decided. A team with a mature CI pipeline and a team without are not doing the same project, whatever the statement of work says.
It also ends the discussion about which use case goes first, which is the argument most of these programs lose a month to.
Weeks 3–8 — Building the first one together
One real workload, in your environment, on your account, in your repositories. Paired, reviewed by your people, merged by your people. Nothing gets built in a workspace you cannot see, and nothing lands that your reviewers did not approve.
The environment gets built as a consequence of needing it — evaluation harness, prompt versioning, cost and latency visibility, the boundary that decides what may leave your network. Standing all that up first, in the abstract, produces a platform shaped like our assumptions rather than your work.
Weeks 9–12 — Taking it back
We stop writing and start reviewing. Your team builds the second workload with us reading the pull requests instead of opening them. That inversion is the actual test, and it is scheduled while we are still being paid to be there — which is the only time it is useful to find out the answer is no.
Ends with the runbook, the failure modes we hit and how they were resolved, and a named person on your side who has done every part of it once.
When this is the wrong thing to buy.
If you have no engineering organisation to transfer capability to, this program has nothing to attach to and you want Build instead — a system delivered and run, without the pretence that someone internal will pick it up.
If the goal is one automation and there is no second or third behind it, the program is more machinery than the problem needs.
And if your engineers have already shipped a couple of these, you probably need a specific problem solved rather than a capability built. Say so and we will tell you if it is one we would take.
Worth a conversation?
Tell us about your team and your cloud. If the shape does not fit, we will say that rather than reshape the program around the sale.