Legacy code documentation
Get the knowledge out of one person's head, or out of the code, and into something your business owns.
An undocumented system creates dependency on individuals. When they leave, so does the understanding. The usual fix, writing documentation by hand, was too slow and expensive to be done, so it wasn't.
AI has changed that. Documentation that once took weeks of reading code can be generated far faster, and then checked against the real application, so it's useful rather than merely plausible.
Who needs it
- You've inherited a system and nobody knows how it works. Legacy application takeover
- You're hiring or onboarding a developer and want them productive quickly
- A key person is about to leave, or already has
- You're selling, buying or investing in a business that depends on the software (technical due diligence)
- You're planning an upgrade or migration and need to know what will be affected
- A security review, insurer or auditor has asked for documentation you don't have
What I produce
| Document | What it explains |
|---|---|
| System overview | What the application does, who uses it, and how the parts fit together |
| Architecture | Structure, frameworks, libraries and how requests flow through the code |
| Database documentation | Tables, relationships, important fields, and what writes to what |
| Integrations | Payment, email, APIs and third-party services, and how each is used |
| Scheduled processes | Cron jobs, queues and background tasks, with what they do and when |
| Deployment and hosting | How the application is built, released and run, and where everything lives |
| Business workflows | Key processes traced through the code: orders, invoices, onboarding, reports |
| Risks and quirks | Fragile areas, known problems, security concerns and "don't touch this" warnings |
| Developer onboarding guide | What a new developer needs to get started |
You choose what's in scope. A focused document on the one scary subsystem is often the most valuable piece.
How I do it
1. Agree scope and audience
Who is this for: developers, managers, auditors, or all of them? That decides the level of detail.
2. Map the system
AI-assisted analysis explores the codebase and database, drafting documentation of structure, dependencies, data flows and workflows. How I use AI
3. Verify against reality
This is the step that matters. AI can describe code confidently and be wrong. I check the documentation against the running application: tracing real workflows, comparing with live behaviour and testing assumptions. Anything I couldn't confirm is marked as unverified, rather than presented as fact.
4. Capture business knowledge
Code shows what happens, not why. Where the reasons matter (a strange discount, a customer exception) I ask you or your team, so that knowledge is written down too.
5. Deliver in a form you can keep
Documentation is delivered in an open, portable format, typically Markdown with diagrams, and can live in your repository, wiki or shared drive. You own it outright.
6. Keep it alive (optional)
Documentation goes stale. I can set it up so it's easy to update, and keep it current as part of ongoing care.
Why this is now practical
Hand-writing documentation for a large legacy system used to take weeks of expert time, so it rarely happened. With AI-assisted analysis, a first draft can often be produced in hours, and the checked version in days. That's a very different cost, and it changes whether documentation is worth doing at all.
The speed-up is real, but the checking is what makes it trustworthy, and that's why it takes an experienced developer, not just a tool.
Documentation and tests together
Documentation tells you what the system does. Tests prove it keeps doing it. For critical workflows I can write tests that capture current behaviour, giving you a safety net for any later change. How I make changes safely
Data protection
Documenting a system means reading it, and sometimes seeing data. I work least-privilege and read-only where possible, prefer sanitised data, and can sign an NDA and data processing agreement. Documentation is written to avoid embedding credentials or personal data. Data protection and security
What it costs
Documentation is part of the Legacy System Assessment, from £2,500, which includes architecture, database, integration and risk documentation at assessment depth. Deeper or broader documentation is quoted fixed-price once scope is clear, or at £950 per day. Pricing
For agencies
Need documentation for a client system you've inherited, or before a handover? I can produce it white-label. Agency terms
Frequently asked questions
How accurate is AI-generated documentation?
Only as accurate as the checking. That's why I verify it against the live application and mark anything unconfirmed. Unchecked AI documentation can be confidently wrong.
How long does it take?
It depends on size and scope. I'll give you a timeline with the quote. As a rough idea, drafting is now measured in hours rather than weeks, with verification taking longer.
Will the documentation include our business rules?
Where they can be found in the code or confirmed with you, yes. Reasons behind decisions often need a conversation, and I'll ask.
In what format will we receive it?
Usually Markdown with diagrams, which is portable, searchable and easy to keep in version control. Other formats can be agreed.
Do you need to see our live data?
Usually not. Structure and code are the focus. If real data is needed, we agree safeguards first.
Can you keep it up to date?
Yes, as part of ongoing care, or by setting up a process for your own team.
Tell me what you've inherited.
If nobody can explain how your application works, that's the place to start.
Book a free conversationLegacy System Assessment, from £2,500