Where the documentation an organisation has to keep tends to live. Decisions, runbooks and architecture notes, in the place an organisation has already agreed to look for them.
Runbooks, architecture decisions and handover material, where the client’s own people will maintain them afterwards. It is the documentation that has to outlive the engagement, so it belongs where the client’s own people already work rather than anywhere we would prefer.
Documentation that belongs beside the code. Anything that goes stale the moment the code changes should be in the repository. A page describing how the code works is stale the week after it is written; that belongs in the repository, next to the thing it describes.
Handover written where the people taking over already look, not where it was convenient for us to write it. Architecture decisions are recorded when the decision is taken, with the options rejected and the reasons — the part that is always missing when somebody asks a year later.
Where this appears on the site
We work in Confluence, and no case study or service page currently published on this site prints it in its stack. Rather than describe an engagement you cannot check, this space stays empty until one does. Ask us and we will talk you through it directly.
Tell us what it is running, what it costs you today, and what you need it to do next. A senior engineer will tell you what we would keep and what we would change.
