The developer left. The agency stopped responding. The technical co-founder moved on. However you got here, you now own a system that generates revenue and that nobody currently understands — and every decision you make is blocked on the same question: how bad is it?

You cannot answer that by reading code, and you should not answer it by asking the next vendor, whose incentive is to recommend a rebuild. You answer it with a structured audit that produces evidence. Ten working days is enough.

The five questions the audit must answer

1. Can we operate it? Can we deploy, restore and recover without the original author.
2. Can we change it safely? Is there any mechanism that tells us when a change breaks something.
3. Is it exposed? Are there credentials, vulnerabilities or access paths that need closing this week.
4. Do we own it? Is the IP chain intact and are the dependency licences compatible with our business.
5. What does the next year cost? To maintain it, to extend it, or to replace it.

Everything below serves those five answers. Nothing else belongs in the first two weeks.

Days 1–2: Take control of access

Before analysis, secure custody. Inventory every account the system depends on — hosting, domain, DNS, database, payment processor, email, third-party APIs — and confirm each is registered to a company address you control, not a personal one belonging to someone who has left.

This is the most urgent step and the one most often skipped. A system you cannot access is not a technical problem; it is an existential one. If a domain or payment account is registered to a departed contractor, start recovery immediately, because it takes longer than everything else in this plan.

Days 3–4: Prove you can deploy and restore

Have an engineer deploy a trivial, visible change — a text correction — through whatever process exists, and document every step. Then restore a backup into a clean environment and confirm the data is intact and current.

If either fails, you have found the most important finding of the audit, and everything else is secondary until it is fixed. A system you cannot deploy to and cannot restore is not an asset yet.

Days 5–6: Map it

Produce a diagram of components, data flows and external dependencies. Identify where personal data and payment data live. List every scheduled job and background process, because those are where undocumented business logic hides.

This map is the deliverable with the longest useful life. Everything you do for the next two years will reference it.

Days 7–8: Assess risk

• Scan dependencies for known vulnerabilities and note which are exploitable given how the system is exposed.
• Scan repository history for committed secrets, then rotate anything found.
• Review the access control model — is authorisation enforced at the data layer, or checked in the interface.
• Check the licences of every dependency against how you distribute the product.
• Confirm every past contributor is covered by a valid IP assignment.

Days 9–10: Cost the three options

Conclude with numbers, not adjectives. Three options, each with a cost and a timeline: maintain as-is, stabilise and extend, or replace incrementally. Include what each option means for the next twelve months of your roadmap.

In our experience the middle option wins far more often than founders expect at the start of the audit. Systems that feel untrustworthy are frequently just undocumented and untested — which is weeks of work, not months.

What to do with the result

Fix anything in the "exposed" category immediately, regardless of the strategic decision. Then choose a path with the evidence in front of you, rather than with the anxiety of not knowing. And whatever you choose, add the tests and documentation first — otherwise you are about to inherit the same problem from yourself.

A system nobody understands is not a technical debt problem. It is a business continuity problem wearing technical clothing.

We run this as a fixed-price engagement with a written report and a costed set of options. Most founders come to us having already been told by someone that a rebuild is the only path; more than half of the time, it is not.