You find out what an agency relationship really costs on the day you try to leave it. Not in the proposal, not in the rate card — on the day you ask for the repos and discover they live in someone else’s GitHub org, the cloud bill goes to someone else’s card, and the only person who understands the deployment left the vendor last spring. Every question on this list is cheap to ask before you sign and expensive to ask after.
The ten questions
Ask these in writing, before contract, and keep the answers. A serious vendor answers all ten in one email without checking with legal.
- 1. Whose org hosts the repositories? — Not “who has access”: whose organisation owns them, from the first commit. If the code starts life in the vendor’s org, migration becomes a favour you negotiate later.
- 2. Whose cloud accounts run production? — Root access, billing, and IAM should sit with you. A vendor who “manages hosting for convenience” holds your production environment hostage by default, whether they mean to or not.
- 3. When is documentation written, and where does it live? — If docs are a project phase, they will be cut when the schedule slips. Documentation and architecture decision records should be part of the definition of done, in your repos, per change.
- 4. What happens when our lead engineer leaves the vendor? — Key-person risk is the quiet form of lock-in. Ask how knowledge is spread across the team and what the continuity plan actually says.
- 5. Can the people on our team be swapped without our consent? — Blended-rate contracts make it profitable to sell you a senior and staff a junior. Named engineers, in the contract, or assume rotation.
- 6. What does the notice period buy us? — Notice should be handover time with obligations attached — knowledge-transfer sessions, runbook completion, credential rotation — not just billing that continues while the team winds down.
- 7. What exactly is in the handover? — Ask for the list now: runbooks, ADRs, infrastructure-as-code, secrets inventory, open-issue register, recorded walkthroughs. If the list doesn’t exist before you sign, it won’t exist when you exit.
- 8. For AI systems: who holds the prompts, evals and datasets? — This is the new lock-in. Prompts, golden datasets and eval harnesses are the accumulated judgement of your system. If the vendor keeps them, you own a model wrapper and they own the product. They belong in your repos like any other source.
- 9. Are there proprietary frameworks or vendor licences in the stack? — An in-house “accelerator platform” is a dependency you cannot hire for and cannot leave with. Boring, mainstream infrastructure is an exit feature.
- 10. Describe your last clean exit. — Every vendor has references from happy ongoing clients. Ask for one from a client who left. How a vendor behaves at the end of an engagement is the only fact that matters here, and past exits are the only evidence.
How to read evasive answers
Evasion here has a recognisable grammar. “That’s all negotiable” means the default is against you and you’ll pay to change it. “We’ll cover that in the SOW” means it isn’t covered. “Our platform handles that” means question nine just failed. “We’ve never had a client want to leave” is not reassurance — it means they have never rehearsed an exit, so yours will be the first. And any answer that routes through the legal department for questions one and two tells you the operational reality: they hold the assets, and lawyers decide when you get them back.
The pattern to watch for is answers about intent where you asked about mechanics. “Of course the code is yours” is intent. “The repos are created in your GitHub org before the first sprint” is mechanics. Only mechanics survive a dispute.
Our answers, for the record
Here is how we answer our own checklist. Your repos and your cloud accounts from day one — we work inside them, we never hold them. Documentation, ADRs and handover drills are part of our definition of done, not a project phase. Teams are named engineers on a fixed monthly team fee — no blended rates, nobody swapped mid-engagement to a cheaper profile, and you interview the tech lead before signing. For AI systems, the prompts, golden datasets and eval suites are versioned in your repos alongside the code they govern, because a production AI system without its evals is not handed over, only half of it is.
The operating principle behind all of it: leaving must always be cheap. Not because we expect you to leave, but because a client who can leave cheaply is a client who stays for the right reasons.
If you want to see how that works in practice — team shapes, the exit-ready definition of done, what an engagement looks like month by month — it’s on our services page, and the first conversation is a technical call, not a sales call.