Building a Comprehensive Continuity Package So My Client Could Replace Me
streamforge.ltdHappy to answer questions about the process.
Quick context: I've been the lead developer for this client for over six years across four interconnected systems (ERP, competitive analysis platform, iOS app, infrastructure). All the institutional knowledge lived in my head. I brought up the bus factor problem myself and built a continuity package to eliminate it.
A few technical details that might be interesting to this crowd:
The credentials problem was the hardest part. You need secrets accessible for handoff but you can't commit them. I ended up with a two-layer system: the documentation repo has references to every credential (what it is, where it's used, who owns it) but zero actual values. A separate gitignored secrets directory holds the real .env files, SSH keys, and service credentials organized by project. One command pulls current .env files from production. Another command packages the entire secrets directory into a dated archive for the business owners to store in their vault. The two layers never mix.
On the AI side: I used AI as a research and drafting partner to produce the initial dozens of pages. It read the source code across all four systems, mapped architecture, and generated first drafts. I reviewed and corrected everything, then filled in the business context and institutional knowledge that only exists in my head. The repo also includes a prompt file so any future developer with AI tooling can point it at the file and maintain the documentation going forward. That part has been surprisingly effective for keeping things current.
The automation piece: a server audit script connects to both production servers weekly and collects current state (PHP/MySQL versions, disk usage, running services, cron jobs, SSL expiry). A pipeline sync tool pulls CI/CD configs. Everything assembles into a PDF with a TOC that gets emailed to the business owners automatically.
Happy to dig into any of this.