Short answer
#What is actually lost
Being precise about this is what makes the next month tractable, because two of the four are recoverable and two are not.
| What | Example | Recoverable? |
|---|---|---|
| Structure | What the system is made of, what talks to what, what depends on what | Yes — it is a property of the code |
| Behaviour | What happens when a payment fails, what the nightly job does | Mostly — readable from the code with effort |
| Reasoning | Why it was built this way, what was tried and rejected, what the constraint was | No. Only from them, and only while they will answer |
| Operational habit | What they check after a deploy, which alert is always noise, how they fix the recurring thing | No, and this is the one that hurts at 3am |
Most companies in this situation spend the notice period trying to recover the first two — asking for documentation, asking for a walkthrough — and lose the last two entirely, because nobody thinks to ask for them.
Invert it. The first two can be derived from the system by somebody else, later, without them. Their remaining hours are the only source in the world for the second two.
#The first week, in order
-
Inventory the access before you change any of it
List every account the system needs: repository host, cloud, domain registrar, DNS, database, CI, error tracking, payment provider, email, storage, monitoring. For each one, write down whose name it is in.
Whose name, not who has access. These are different questions and the second one is not the dangerous one.
-
Confirm you can deploy without them
Not “we have the credentials” — actually deploy something trivial. A surprising number of handovers discover on day forty that a step in the release process existed only on one laptop.
-
Confirm you can restore from a backup
Also actually do it, into a scratch environment. A backup nobody has restored is a belief, not a backup.
-
Get an independent technical picture
Have somebody who still has the code run an analysis of it. The output you want is not a summary — it is a map with citations and an explicit list of what could not be established.
This is what 1ADK does. A coding agent alone will also produce a good version of this; what it will not do is separate what it read from what it inferred, or still be holding the answer in three months.
-
Turn the gaps into questions for them
The unknowns from that analysis are the shortest possible list of things only they can answer. Send it as a list. Not “please write documentation” — twelve specific questions.
A specific question gets answered in a leaving week. An open-ended request does not.
#Access, in the right sequence
The instinct is to revoke everything immediately. That instinct locks people out of their own systems.
The failure mode is specific and common: an account is in the developer's name rather than the company's. Revoking their access to it does not transfer it — it removes the only route into it. Cloud organisations, domain registrations, app store accounts and payment provider logins are the usual candidates.
-
Establish ownership first
For each account: is the owning identity a company address you control, or a personal one? Anything in the second category is a transfer, not a revocation.
-
Transfer what needs transferring
Domain, cloud organisation, registrar, app stores, payment provider. Several of these have a multi-day process and one of them will surprise you.
-
Create your own route in
Company-owned admin accounts on everything, with recovery going to an address the company controls. Verify each one works before the next step.
-
Then revoke
Personal accounts, personal tokens, SSH keys, and anything on their machine. Rotate every credential they could have seen — treat them as exposed, without implying anything about the person.
The one that catches people
Recovery email and phone number on critical accounts. If the recovery address on your cloud account is a personal one, everything else you did above can be undone by whoever controls that mailbox. Check this on every account you cannot afford to lose.
#What to ask, if they are still reachable
Assume you get one hour of genuine attention, not forty. Spend it on what only they have.
Do not ask for documentation. It will be written under duress, in a hurry, and will describe what they remember rather than what is there. Ask questions instead, and ask them in writing so the answers are kept.
Reasoning — the part that is genuinely unrecoverable
- Which part of this system would you be nervous about somebody changing, and why? This single question reliably surfaces the thing nobody would have found for six months.
- What did you try that did not work, and why did you go this way instead?
- What is here because of a constraint that no longer exists?
- What would you have done differently if you had had another month?
Operational habit — the 3am knowledge
- What do you check after a deploy?
- Which alerts do you ignore, and which ones actually mean something?
- What breaks regularly, and what do you do about it?
- What has to be done manually, and when? Monthly and quarterly manual steps are the ones that get discovered in month three.
External and human
- Which outside services does this depend on, and whose account is each one in?
- Who outside the company would notice if this stopped — partners, integrators, a customer with an API key?
- Is there anything running that is not in this repository?
- Who else has ever had access to any of this?
What to request before a developer leaves is the longer version of this, arranged as a handover.
#What you can establish without them
More than most owners expect, and it costs one instruction rather than a consultancy engagement.
Anybody who still has the code — a remaining developer, a contractor, an agency you are considering, or you, if you can check out a repository — can produce a structured technical picture of the system without any help from the person who left. That includes:
- the components the system is made of, with a readable purpose for each;
- what depends on what, and in which direction;
- the external services it needs in order to work;
- the interfaces it exposes, and roughly what each operation does;
- the data it holds and where that data moves;
- and — the part that matters most here — a list of what could not be established, and why.
That last list is the thing to optimise for. It converts an unbounded fear ("we don't understand our own system") into a bounded task ("there are eleven specific questions, four of them matter, here is who might know").
#Where 1ADK helps, and where it does not
Where it helps
- Producing the picture without giving anybody repository access.
- Separating what was read from what was inferred, so a new team knows which sentences to trust.
- Turning gaps into a prioritised, specific question list.
- Keeping the result, so the next person to arrive does not start again.
- Showing what has changed since — including which earlier claims no longer hold.
Where it does not
- Recovering reasoning. Why it was built this way is not in the code.
- Recovering operational habit. What they checked after a deploy is not a property of the software.
- Transferring accounts. That is your work, and the order matters.
- Telling you whether the code is any good.
- Finding security vulnerabilities.
#Making the next one cheaper
This will happen again — with the next developer, the next agency, or you. Three things make the second time substantially less expensive, and all three are cheap while nothing is on fire:
-
Every account in a company identity
Domain, cloud, registrar, provider dashboards. Recovery addresses on company mailboxes. This is an afternoon and it removes the worst category of surprise entirely.
-
A current technical picture that lives outside anybody's head
Refreshed when something material changes, not on a calendar. The value is not the document — it is that the difference between two of them is visible.
-
The open questions written down as they appear
Every time somebody says “actually nobody knows how that works”, that is an entry. Written down while the person who could answer it is still in the building.
The developer dependency check is a fifteen-question version of "how bad would this be if it happened tomorrow", and needs no account.
Questions people actually ask
Most of the technical picture is, because it is a property of the code rather than of the person. What is not recoverable is reasoning: why an approach was chosen, what was tried and rejected, what a constraint was. Recover the picture first — it is what tells you which of the missing reasons actually matter.
Establish which accounts they hold and in whose name each one is, before you change anything. Revoking access in the wrong order can lock you out of an account that was only ever in their name. The order matters more than the speed.
Yes, and you should — it is fast and it works. The two things it will not do are tell you which of its statements are inferred rather than read, and be there in three months to say what has changed. If this is a one-off question, an agent alone is the right answer.
An analysis is minutes to hours of agent time depending on the size of the system. Working through the open questions it produces is the part that takes real effort, and it is bounded — a specific list rather than an unbounded investigation.
Slightly, and less than people expect. Documentation that exists is treated as a declaration rather than an observation anyway, because it may be years out of date. A system with no documentation and a system with wrong documentation are closer to each other than either is to a system with current documentation.