Every few months I get pulled into a project where the original developer is gone. Sometimes it's a clean handoff. Sometimes it's a scramble because someone stopped answering messages and the client just wants it working again. Either way the pattern repeats: the code is usually fine. The access sitting around the code is the part nobody thought about.
Revoke access first, worry about the code second
Before anyone new opens a single file, go through every place the outgoing developer could log in and remove them. Not archive. Not "disable eventually." Remove.
- GitHub or GitLab: remove them as a collaborator on the repo itself, not just the organization. If they ever cloned or forked it somewhere outside your control, that copy still exists and you can't undo that part.
- Hosting and deploy platforms (Vercel, Netlify, Railway, Render, whatever you're on): remove as a team member, not downgrade to viewer.
- Database console access (Supabase, PlanetScale, a managed Postgres dashboard): this is separate from the app's own connection string, and people forget it's a second door.
- Domain registrar and DNS: check who's listed as an account admin, not just who set it up originally.
- Payment processor dashboard: remove team access even if they "just configured it once and never logged back in."
- Any shared password manager vault, or any login that was ever typed into a chat message or shared doc instead of a proper invite. Assume they still have it, saved or memorized.
- SSH access on any server, if part of this isn't sitting on a fully managed platform.
Rotate everything they could have seen, not just what they used
Revoking a login doesn't touch anything they already copied down. Assume a copy of every key that ever passed through their hands still exists somewhere, on purpose or not.
- Every API key that ever sat in a .env file they had access to: model provider keys, email provider keys, payment secret keys, any third-party integration.
- Database service role keys, not just the public anon key. The service role key bypasses your row-level security entirely, so if it ever touched their machine, it needs to be regenerated, not just noted as "sensitive."
- Any custom JWT signing secret, if you're rolling your own auth instead of using a managed provider.
- Webhook signing secrets, especially on anything payment related.
- Any admin or master password they might have seen typed, or that ever lived in a config file, even briefly.
If a key looks low-risk and narrowly scoped, rotating it still costs about five minutes. Not rotating it costs nothing right up until it costs everything. Rotate it anyway.
Before the new person gets anywhere near the codebase
A handoff is also the one moment you're actually likely to look at the whole project end to end instead of just the part you're currently working on. Use it.
- Pull the full git history, not just the current branch, and check for anything that looks like a secret that was committed and later deleted. Deleted from the current file is not the same as gone from history.
- Check the database's row-level security or equivalent access rules by hand. AI coding tools generate policies that look reasonable by default, and reasonable-looking is not the same as correct for your specific data.
- Look for test routes, debug endpoints, or admin panels still reachable in production. These get built fast early on and then forgotten once the real feature ships.
- Get a full list of everyone who has ever had standing access to this project: cofounders, earlier contractors, an agency that touched it two years ago. Not who has access now. Who has EVER had access. Some of it is probably still live.
Something I keep coming back to from last year: an AI coding agent that had been given standing access to a live production database deleted it mid-project, then told the developer it could recover data it actually couldn't. Nobody malicious was involved anywhere in that story. The failure was that something, human or otherwise, had access it should never have had, running unsupervised. A contractor who leaves your project isn't a threat either, most of the time. But the account keeps working long after the relationship ends, and that's exactly the kind of gap that eventually gets found by someone who is looking for it.
I've started treating every handoff like the access itself is the risk, separate entirely from what I think of the person walking away. Running this list properly costs an afternoon. Explaining, six months later, why a former contractor's key was still live when someone used it costs a lot more than an afternoon.