The client gets what they bought
A client took over their platform with a clean repository they can build, check and deploy themselves, and none of the tooling used to build it. How to design a handover for AI-assisted delivery.
, updated , filed under ai, handover, delivery, coding-agents, consulting
In September a client took over the repository for their reinsurance underwriting platform. They got a clean repository they can build, check and deploy themselves, with a record of exactly where it came from. The architecture checks came with it and still gate their production deploys.
What they didn’t get was the tooling used to build it. No docs corpus, no docs search tool, no agent skills, no agent instructions. That was designed in from the start, and the release fails if it isn’t true.
They got exactly what they bought. Nothing more.
Why this matters now
AI-assisted delivery produces a lot more than the application. The source repository had hundreds of documents, a docs search tool, agent skills and delivery tooling in it. That’s how the product was built. It’s not what was sold.
Copy that repository across and the client gets clutter they didn’t pay for and can’t maintain, and the supplier gives away the tooling that makes the next project faster.
The handover is also an IP boundary. The client owns the product outright: every line of the application, its tests and its infrastructure. The supplier’s tooling, the docs corpus, agent skills and delivery scripts that make each project faster, stays with the supplier. Drawing that line in code, not just in a contract, means neither side has to wonder later who owns what.
Export, don’t copy
OES put a lot of work into a script that transfers just the agreed application, rather than everything used to build it. Work on the release pipeline started in mid-May, weeks before the first production deploy.
- An allow-list decides what goes across. If it isn’t listed, it doesn’t ship.
- Forbidden paths and forbidden text patterns catch the things that shouldn’t leave: docs folders, agent configuration, references to internal repositories. Environment files never go.
- The export writes a README for the client and a provenance record of exactly which source it came from.
Verify, don’t trust
A verification step fails the release if anything internal leaks through: a docs folder, an agent skill, even a reference to an internal repository. The export has its own tests, like any other code.
When the handover came, the export was extended for the final release rather than anyone copying files by hand.
What each side keeps
The client gets the product: a repository they own outright, can run without its supplier, and that enforces its own architecture.
The supplier keeps the docs corpus, the agent skills and the delivery tooling. Those are what make the next project faster.
Questions to ask your supplier
If someone is building your product with AI tooling, ask:
- What exactly is in the repository you’ll hand over, and what isn’t?
- Can we build, check and deploy it ourselves, without you?
- What enforces quality after you’ve gone?
- Is there a record of which source the handover came from?
- What’s yours, what’s ours, and where is that line enforced?
If AI tooling is part of how you deliver, decide early which parts are the product and which parts are yours.
Commissioning AI-assisted delivery and want a clean handover? Let’s talk.