Handing a system over
Start with the checklist if a handover is happening, with what to ask for if somebody is leaving next month, and with the risks page if you are trying to decide how much to worry.
- Guide The handover checklist Nine areas, forty-one items, and the order they should happen in — with the three acceptance tests that replace "documentation delivered" as the definition of done. What has to change hands when software moves to a new team?
- Guide What to ask for before they go Assume one hour of genuine attention, not forty. Spend it on the two things nobody else can supply — reasoning and operational habit — and derive everything else from the system afterwards. What should I ask for before a developer leaves?
- Guide Transferring a codebase The mechanics: repository and history, environments, secrets, the demonstration week, and the sequence in which access is transferred and then rotated — which is the part people get backwards. How do I transfer a codebase to a new development team?
- Guide Handover risks Eleven things that go wrong, sorted by whether they cost you time or cost you the ability to operate — and what specifically prevents each one. What can actually go wrong in a software handover?
- Guide Handover documentation Most handover documentation is written under time pressure about what somebody remembers. What is worth writing by hand, what should be derived instead, and how to specify it so you get the useful half. What documentation should a software handover produce?
Depending on one supplier
Most of this is compatible with keeping a supplier you like — which is usually the right outcome. Ownership first; everything else after.
- Guide Who owns production Access is not ownership. Which accounts must be in the company name, why the recovery address matters more than the login, and how to move them without a fight. Who should own the cloud accounts, the domain and the production data?
- Guide Reducing agency dependency Six moves in order of value per hour spent, almost all of them compatible with keeping a supplier you are happy with — which is usually the right outcome. How do I reduce dependency on a development agency?
- Guide Changing agency A step-by-step transition from before notice is given to the consultation window afterwards, including what to secure first and where the expensive gap opens. How do I move a software project from one agency to another?
- Guide Vendor lock-in Not all lock-in is bad, and avoiding all of it is expensive. Six kinds, what each one costs to escape, and the two that are worth spending money on now. Which kinds of vendor lock-in are actually worth avoiding?
Software nobody here understands
Legacy is rarely about age. It means the people who understood it are gone and what is left cannot answer questions.
- Guide Understanding a legacy codebase Seven steps in the order that works, starting with what runs rather than with the code — and the four things to stop doing while you do it. How do I understand a legacy codebase?
- Guide No documentation at all The first week when there is nothing written down and nobody to ask: what to establish, in what order, and why no documentation is a better starting position than wrong documentation. I inherited a codebase with no documentation. Where do I start?
- Guide Mapping existing architecture Five passes in order — what runs, what it is made of, what it talks to, where the data goes, and what nobody could establish — plus what to record for each element so the map survives its second update. How do I map the architecture of software that already exists?
- Guide Documenting a legacy system Documentation projects on legacy systems almost never finish, because nobody can tell how much is left. What to derive, what to write by hand, and how to make the task bounded. How do I document a legacy system nobody understands?
Software written faster than it was read
None of this is an argument against coding agents. It is an argument that understanding has to keep pace with them.
- Guide Understanding AI-written code The specific difference is that nobody read it on the way in. What to check first, how to separate what an agent read from what it inferred, and the patterns fast agent work leaves behind. How do I understand code that was written by a coding agent?
- Guide Agent-built production checklist Twenty-eight checks across data, money, the unhappy paths, external edges, access, operations and understanding — the ones with the highest hit rate on systems written faster than they were read. What should I check before software built with a coding agent takes real traffic?
- Guide Shipping what nobody read Not "AI writes bad code". Seven specific exposures that come from understanding failing to keep pace with production, and what each one actually costs. What are the real risks of shipping software that nobody fully read?
- Guide AI-generated documentation Generated documentation is fluent, extensive, and impossible to tell apart from verified documentation. How to test it, what to keep, and why unverified documentation is worse than none. Can I trust documentation that a coding agent generated?
- Guide AI-built SaaS for owners You do not need to read code. You do need to know which questions have different answers when a system was written faster than anybody read it — and there are nine of them. What should a non-technical founder know about a product built with AI?
Owning software you did not write
For an owner who does not read code, and for a technical leader arriving in a system somebody else built.
- Guide What a founder should know Not how it works. Twelve things you should be able to establish about a system you own, why each matters commercially, and how to get each one without reading code. What should a founder actually know about their own software?
- Guide Questions to ask your CTO Twenty-four questions grouped by how often to ask them, with what a good answer sounds like — because you can evaluate the shape of an answer without understanding its content. What should I be asking my CTO, and how do I read the answers?
- Guide Understanding your own SaaS A four-week sequence for an owner: the inventory, the dependencies, the data, and the concentration count — none of which requires reading code or a large project. How do I get a picture of my own SaaS product?
- Guide A new CTO first 30 days One deliverable: an account of the system that does not depend on any one person describing it. Week by week, what to establish, what to ask, and what not to announce. What should a new CTO do in their first thirty days?
- Guide What to ask the existing team What to request, what to derive instead of requesting, and the handover a new technical leader should be given but almost never is. What should a new technical leader ask the existing team for?
How these are written
- A question as the title, and the answer in the first three sentences. If that is all you needed, stop there.
- Every example is invented and labelled as such. 1ADK has no customers yet, so there are no case studies and there will be none until there is somebody to write about, with their name and their permission.
- Every guide says what it does not cover. A page with no limitations section was written to sell rather than to be right.
- A date and an author. A technical claim with neither is a claim nobody can weigh.
- Nothing is behind an email address. Not the checklists, not the templates, not the tools.