Documentation, ownership, authentication, backups, dependencies, source control, and the handoff plan every internally developed tool needs.
The failure mode for internal tools is not a bug. It is a resignation. Something built by one enthusiastic person becomes genuinely useful, spreads quietly, and then that person is promoted, retires or leaves. Nobody else has the password, nobody knows where it runs, the annual renewal is on a personal card, and there is no documentation because the author never needed any. Building so somebody else can take over is mostly unglamorous housekeeping done early. Write documentation aimed at a competent stranger. Name an owner who is a role rather than a person. Keep the code in source control the department controls. Record what it depends on and what those dependencies cost. Back up the data, and test the restore. Make sure administrative access exists for more than one person. Know where it is hosted and what renews, and when. Store API credentials somewhere the organisation owns. Keep a change history so the next person can see what happened and why. Test the thing. And write down the handoff plan before you need it. The honest test: if you were unavailable for a month, could someone else keep this running from what is written down?
If you read one thing on this subject, read this.
Practices covering source control, dependencies, change history and review.
Why it matters
The housekeeping in this lesson is the plain-language version of several of these practices.
Everything above was published by someone else, and is here because it is the clearest treatment of the subject we could find and verify. The Hub’s own guide to this topic is still being written. If you know a better source than the ones listed, that is worth telling us before it is.
Send a note