We keep a shared set of onboarding docs for new client projects — hosting checklist, launch checklist, standard contract clauses for scope changes. Going through them this month, a surprising amount referenced tools and services we had quietly stopped using a year or more ago, which is exactly the kind of quiet drift that internal documentation accumulates when nobody is specifically responsible for keeping it current.
The audit itself was a fairly mechanical process: read every document top to bottom, flag anything referencing a tool, service, or process we no longer actually use, and either update or remove it. What made it worth doing was not any single dramatic finding but the sheer accumulation of small inaccuracies — a hosting checklist step referencing a shared-hosting-era setup process for clients we had since moved entirely to cloud infrastructure, a launch checklist missing any mention of the Docker-based deployment process that had become standard on every new project this year.
What we actually changed
We trimmed anything referencing our old shared-hosting-era checklist, updated the launch checklist to reflect our current Docker-based deployment process, and added a short section on our current stance on Kubernetes for larger clients, pointing back to the actual criteria we now use in scoping conversations rather than leaving it as an open question every project team had to work out independently.
Nothing dramatic, but stale internal documentation is a quiet tax on every new project, and it is worth the occasional afternoon to clear it out. We are adding a recurring calendar reminder to repeat this audit roughly twice a year going forward, on the theory that catching this kind of drift early and often is considerably less painful than letting it accumulate for years before someone finally notices.
Assigning real ownership this time
Part of why these docs had drifted so far in the first place is that nobody specifically owned keeping them current — they were treated as a shared resource everyone was equally responsible for, which in practice meant nobody was really responsible for them at all. Coming out of this audit, we assigned a single rotating owner each quarter, whose job is specifically to review and update these docs as part of their existing responsibilities, rather than leaving it as an ambient, unassigned task that competes with actual client work for attention and reliably loses.
What we learned about writing documentation that ages well
A pattern we noticed across the stale sections: documentation that named specific tools and versions directly tended to go stale faster than documentation that described the underlying principle and pointed to a single, separately maintained source of truth for current tool choices. We rewrote a few of the worst offenders with this in mind — rather than a launch checklist item saying "deploy via our specific current process," it now says "deploy according to our current deployment standard, documented here," with a link to a single page we can update in one place rather than hunting down every document that happened to reference the old process directly.