Some teams want to own their AI system outright, but not build it alone. We build it in your environment, operate it until it is stable, then transfer it to your own engineers with proof they can run it without us.
Why build-operate-transfer exists
Hiring a full AI team before you have a system is a gamble. Inheriting a finished system your team has never touched is a bigger one.
Build-operate-transfer avoids both. Your future owners work inside the team while we build and operate, so by the time the keys change hands, the system is already theirs in practice. The transfer is a formality, not a cliff edge.
What you get
These are the commitments behind every build-operate-transfer engagement; the exact scope and phase criteria are agreed with your team in writing.
The system is built in your cloud, your repositories and your accounts. There is no parallel setup to migrate later, because the transfer is a change of hands, not a change of address.
What to verify: Ask to see where the code and infrastructure live on day one, and confirm nothing sits in our accounts.
We run the system in production while it is new: monitoring, evaluation, incident response and the small fixes every young system needs. The operate phase ends when the metrics say it is stable, not when a calendar says so.
What to verify: Ask what the stability criteria are for ending the operate phase, and who decides they are met.
During build and operate, your future owners work inside the team: pairing on real tickets, sitting in reviews, taking on more each month. They are not briefed at the end; they grow into the system.
What to verify: Ask how your engineers are involved during build and operate, and what they own by the time transfer starts.
Transfer completes when your team runs the system unaided for an agreed period: deploys, incident response, evaluation and model changes, with us watching but not touching. That run is the proof.
What to verify: Ask what the final unaided run looks like, how long it lasts, and what happens if something goes wrong during it.
When transfer completes, our access is revoked, credentials are rotated, and you hold the code, documentation, evaluation sets and runbooks. The exit checklist is agreed at the start, not negotiated at the end.
What to verify: Ask for the exit checklist before signing, including how access is revoked and verified.
AI in the engagement
The measure of a good transfer is what your engineers can do the week after we leave.
The evaluation set is built to be operated by your engineers, not by us. By transfer, your team runs it, reads it and extends it without help.
Why a model, prompt or pipeline looks the way it does is written down as decisions are made, so your team inherits the reasoning, not just the result.
Our engineers use AI tooling inside the build, and your team learns those workflows too, so the productivity does not leave when we do.
The three phases
One engagement, three phases, each gated by evidence rather than dates.
Working principles
Phase gates, your people's involvement and a designed-in exit decide whether a transfer actually works. We make those commitments explicit rather than implied.
Build, operate and transfer are one engagement with one plan. The criteria for moving between phases are agreed in writing before work starts.
The model only works if your team ends up owning the system confidently. Hiring and training your engineers is part of the plan, not an afterthought.
Everything is built on your infrastructure with mainstream, well-documented technology. The system must be operable without us, because that is the entire point.
We move from build to operate, and operate to transfer, when the evidence says so. If a phase needs longer, we say so and show why.
Security & trust
Everything is built inside your perimeter from the first commit, and our access shrinks on a schedule until it is gone.
Code, infrastructure, data and accounts are yours from the first commit. We work inside your perimeter throughout.
Our access is agreed in writing, reviewed each phase, and revoked at transfer with the rotation of every credential we touched.
Production data stays in your environment. Test data is anonymised or synthetic unless you agree otherwise in writing.
Working arrangements
The work runs remotely inside your rituals, in your cloud and your repositories. Kick-off, the start of transfer and the final unaided run can be in person.
Build and operate run remotely inside your tools and rituals, so your team sees the real day-to-day, not a staged version.
Development, staging and production all live in your cloud and your accounts, from day one to the day we leave.
Kick-off, the start of transfer and the final unaided run are the moments where being in the room genuinely helps, and we plan for them.
How it works
The phases and their gates are agreed in writing before work starts, so nobody is surprised by what 'done' means.
We build the system in your environment, with your future owners inside the team from the start. The phase ends when the system is live and the evaluation set passes.
We run the live system: monitoring, evaluation, incidents and improvements, while your engineers take on more of the operation each month.
Your team runs the system unaided for the agreed period, with us watching but not touching. When the run completes, access is revoked and the exit checklist is signed off.
You own the system outright. If you want help later, a rolling partnership or a fixed-scope piece of work can follow, but nothing obliges you to one.
A pod is an ongoing team that builds with you. Build-operate-transfer has a defined end: we build the system, run it until it is stable, then hand it to your own team and leave. A pod stays; a transfer finishes.
It depends on the system, but the phases are gated by evidence, not dates. Build ends when the system is live and evaluated; operate ends when stability criteria are met; transfer ends when your team completes the unaided run. We agree the criteria in writing before starting.
Hiring your future owners is part of the plan. We help define the roles, and your hires join the team during build or early operate so they grow into the system rather than inherit it cold.
That is what the run is for. If your team cannot resolve an incident without us, transfer is not complete: we fix it together, update the runbooks, and the run continues until it is genuinely unaided.
Yes. Many clients follow a transfer with a rolling ongoing partnership for monitoring and improvements, or call us back for fixed-scope additions. But the system is designed to run without us, and the choice is yours.
You do, from the first commit. Code, documentation, evaluation sets and infrastructure all live in your accounts and are yours outright.
When you do not intend to own the system in-house, a dedicated pod or ongoing partnership fits better. And when the scope is still unclear, start with a two-week sprint to define it before committing to a build.
Let's talk
Tell us what you want to own and who you have today. We will tell you honestly whether build-operate-transfer fits, and what the phases would look like.