Rails rescue and takeover

We take over a Rails codebase that another team left broken, undocumented or unshippable, stabilize it first, and then decide with you what it should become. Rebuild is not the default; in our experience it is the exception that has to be argued for.

Sources: GHSA-xr9x-r78c-5hrm.

Companies whose developers left with the deploy knowledge. Teams that fear deploying more than they fear not shipping features. Products delivered by a vendor that no longer answers. Codebases where an upgrade branch was abandoned halfway and production is now pinned to a version nobody can reproduce locally.

Not for you if: Anyone who has already decided to rewrite and wants us to agree. Anyone who wants the old team blamed in writing; we document what we find, not who did it. Applications with no repository access and no production access; we cannot rescue what we cannot see.

Read-only access to the repository and to production logs, then a review focused on three things: can we build and deploy it, what is on fire, and what is quietly wrong (query semantics, callbacks, cache formats, secrets handling). The first deliverable is a reproducible local build and a deploy we have done ourselves. Nothing else is credible before that.

The first fixes are the ones that can take the business down while everyone is still learning the codebase: exposed secrets, an unpatched advisory, irreversible migrations pending on a branch, no rollback path, one person who knows the deploy. Then the sequenced plan: Ruby hops between Rails hops, a verdict for every gem, the front-end decision scoped separately.

Rescuing other developers' work is the single most frequent theme in the public recommendations our founder received between 2007 and 2012. One client wrote in 2009 that we had fixed the work of the previous programmer and become part of the team. Two anonymous case studies are on the site, with the detail behind them under NDA.