Rescuing a stalled project: our audit-first playbook

Rescue work starts with a written audit, not with code. Before anything is touched we answer three questions on paper: what actually runs, what only looks like it runs, and what is going to burn next week.

"Only looks like it runs" is the category that surprises people. A dashboard fed by mock data. A payment webhook that returns 200 and does nothing. A test suite that passes because the assertions were commented out during a deadline. These are not rare; they are the normal residue of a project that stalled under pressure.

We never rewrite in the first week. A rewrite proposed before the audit is a guess with an invoice attached, and it throws away the one asset a stalled project still has: the accumulated knowledge of what the business actually needed, encoded — badly — in the existing code.

What the client gets is a blunt report with severities and a path that is either stabilize-in-place or the smallest rebuild that ships value. Usually the first: restore backups, fix the boundary bugs, get deploys reproducible, and only then discuss architecture. A project that can deploy on a Tuesday afternoon without ceremony is already half rescued.

We run the same playbook on our own products, which is how this site got its own audit — and why several claims that used to sit on this page are no longer here.