IT Glossary
What is technical documentation?
The written material describing how a software system is built, how it works and how it is maintained — architecture, interfaces, deployment and operations.
What happens to your application the week the developer who built it stops answering the phone? The answer is written down in advance or it is not written down at all. Technical documentation is the set of materials that lets someone other than the author operate, change and hand over a system: an architecture overview explaining how the pieces fit, interface specifications for anything that talks to another system, the deployment procedure, environment and credential inventories, the data model, and a runbook for the failures that actually happen. It is deliberately not a description of every function — that ages badly and nobody reads it. Treat it as an asset on the same footing as source code, because commercially it does the same job. It is what makes a competitive re-tender possible instead of theoretical, what turns an incident at two in the morning into a procedure rather than a search, and what an acquirer, an auditor or an insurer asks for when they want evidence the business does not rest on one person's recollection. Specify it in the contract, with acceptance criteria, or expect not to receive it.
Let’s talk about your project
Message us on WhatsApp or send an email — you talk directly to a developer.
office@northdan.com · +40 752 070 247
Why it matters for your business
Independence from people and suppliers
A documented system can be handed to another team without archaeology, which keeps your supplier relationship a choice rather than a dependency.
Cheaper, faster maintenance
Developers who can read how the system works spend their hours changing it instead of rediscovering it at your hourly rate.
Cover during audits and incidents
Data flows, retention rules and recovery procedures on paper answer auditors quickly and shorten outages measurably.
Frequently asked questions
What is the minimum documentation a delivered software project must include?
Six items, and they fit in a contract annex: an architecture diagram with components and their dependencies; interface and API specifications; the build and deployment procedure; an inventory of environments, servers and third-party accounts; the data model with retention rules; and an operations runbook covering backup, restore and known failure modes. Anything beyond that is welcome but negotiable.
The supplier says the code documents itself — is that acceptable?
Partly true and mostly evasive. Well-written code does explain what a function does, but it never explains why an architecture was chosen, which external systems must be reachable, how to restore a database, or what the third-party contracts are. Those live outside the code by definition. Accept self-documenting code as a reason to skip function comments, never as a reason to skip handover material.
How do we keep documentation current after launch?
Keep it in the same repository as the code and make updating it part of the change itself, so a modification without its documentation update simply is not finished. Then review the small set of critical documents — architecture, runbook, environment inventory — once a quarter. Documentation kept in a separate drive folder is stale within two releases, without exception.
Let’s talk about your project
Message us on WhatsApp or send an email — you talk directly to a developer.
office@northdan.com · +40 752 070 247