One person built the system, held the entire model of it in their head, and has now gone. The application still runs, which buys time, but nobody can safely change it and nobody knows what happens when it fails. The instinct is to rewrite. That is usually the most expensive available option, and it is rarely necessary.
01Stabilise before you understand
The immediate risk is not that the code is unclear, it is that you cannot recover from an incident. Before any analysis, confirm you can deploy, that backups exist and restore successfully, that you control the domains, certificates and cloud accounts, and that credentials are recoverable without the person who left.
This ordering matters. Teams that begin by reading code frequently discover weeks later that the deployment process only existed on a departed laptop, or that nobody has ever tested a restore. Those are business-ending problems; unclear code is merely expensive.
| Item | Why it comes first | Verified by |
|---|---|---|
| Deploy access and process | Cannot ship a fix without it | Deploying a trivial change |
| Backup restore | Backups that fail are not backups | Restoring to a scratch environment |
| Domain and DNS control | Expiry takes the product offline | Logging into the registrar |
| Certificate renewal | Silent expiry causes outages | Checking auto-renewal works |
| Cloud and vendor accounts | Billing and root access | Confirming an owner exists |
| Third-party API keys | Rotation needed after departure | Inventory of keys in use |
02Read the system, not the source
Reading a codebase front to back is slow and produces surprisingly little understanding of behaviour. Start from the outside: what endpoints exist, what jobs run on a schedule, what integrations send and receive data, what tables hold the most rows and which are written to most often.
Then trace two or three critical paths end to end - typically signup, the main transaction and billing. Understanding those thoroughly gives you more operational capability than a shallow familiarity with every file, and it maps directly onto what the business cares about.
03Add tests around behaviour you must not break
Characterisation tests capture what the system currently does rather than what it should do, including the behaviour that looks wrong. Something downstream may depend on that oddity, and a test that records it protects you while you learn which parts are deliberate.
This converts an unmodifiable codebase into a modifiable one incrementally. Each test added is a small permanent increase in the number of changes you can make safely, and it compounds far faster than reading does.
| Rewrite | Stabilise and evolve | |
|---|---|---|
| Time to first value | Months | Days |
| Risk | High - unknown requirements are lost | Low - behaviour preserved |
| Knowledge gained | Deferred until late | Immediate and cumulative |
| Business disruption | Feature freeze during rewrite | Delivery continues |
| Appropriate when | Technology is genuinely unsupportable | Almost always |
04Why rewriting usually costs more than it appears
A working system encodes years of accumulated decisions, edge cases and fixes that exist in no specification. A rewrite reproduces the visible features and loses the invisible ones, which surface as regressions over the following months in exactly the situations that were rare enough to be forgotten.
There is a narrower case where replacement is right: an unsupported runtime with known unpatched vulnerabilities, or a dependency that no longer exists. Even then, replacing component by component behind a stable interface preserves delivery in a way that a full rewrite does not.
05Make sure it cannot happen again
The underlying failure was organisational rather than technical: one person was permitted to be the only one who understood a critical system. Rotating who handles changes, requiring review, and keeping documentation in the repository where it is updated alongside the code all address that directly.
A practical test is whether any single person could be unavailable for a fortnight without work stopping. If the answer is no, the concentration has simply moved to someone new, and the same event will produce the same crisis.
Topics
Lena Voss
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer