Rescuing an inherited codebase: what we check in the first two weeks

The call usually sounds the same

A founder or product lead gets in touch about a product that already has users, and a development team that has just left. Sometimes, like a subscription trading-community platform we later rescued, a previous developer had left it unable to log users in; sometimes it's simply a codebase nobody can get running anymore. We've taken on enough of these engagements to know that what we check before writing any new code decides whether a rescue succeeds, whether that takes two weeks on a bigger platform or two days before a demo, and that the checks look much the same whether the product is a trading community, a language-learning platform, or a project-scheduling tool for construction firms.

Can anyone log in, and does the build even run?

The first thing we test is the thing the previous team was supposed to have working. On a subscription trading-community platform, that test failed immediately: login and signup were broken, several backend endpoints the front end called simply didn't exist, and image uploads failed outright. Before any feature work, we had to debug the authentication flow itself, then build the missing endpoints, including registration checks, a Stripe billing portal and post categories, and fix the session, cookie and CSRF handling between the backend and the forum engine it ran on.

On an AI-assisted project-scheduling product, the failure looked different but the diagnostic was the same: an undocumented codebase, a manual build process, and a customer demo already on the calendar within days. We rebuilt the local development setup from scratch with no documentation to go on, because until an application builds reliably on a new machine, nothing else about it can be trusted.

Sometimes there isn't even a build to test. On an AI medical scribe for clinicians, the previous developers had left no accessible git repository, shared root credentials, and code that didn't match what was actually running in production. There was nothing reliable to read or diff against, so before any of the usual checks were possible, the first step was recovering the source into a proper repository, AWS CodeCommit, and redeploying from there.

What's quietly broken underneath the features that "work"

Login and build failures are the loud problems. The quiet ones take longer to find. On that same scheduling product, task dependencies, percentage-complete shading on the Gantt bars and start-date propagation were all subtly wrong, and hidden-column and working-hour settings weren't being saved with the file at all. On a language-learning platform we later re-platformed, the fault line sat underneath the interface entirely: controllers were referencing database tables that no longer existed, payment flows were broken, and the mobile app wouldn't compile on either iOS or Android. That kind of drift, where code and schema disagree with each other, doesn't surface until you go looking for it deliberately.

The first two weeks aren't about writing new features. They're about finding out what the last team's code was actually promising, and what it was actually doing.

A working first-two-weeks checklist

Across these engagements, the same short list of questions keeps paying off before any new feature work starts:

• Can every existing user still log in, and does the code build cleanly on a machine that isn't the last developer's?
• Do the endpoints the front end actually calls exist on the backend, and do they return what the front end expects?
• Are payments, file uploads and any real-time features such as chat, sockets and live updates working end to end, not just rendering?
• Does the database schema match what the application code assumes it does, or has the two drifted apart?
• Is there a staging environment, and a rehearsed, zero-loss way to migrate data before touching production?

Migrate without losing anything, then keep shipping in the open

Once we understand the real state of a system, the fix is usually targeted. For the trading-community platform, a state-management refactor and cached tokens cut the API calls needed per interaction from hundreds down to one, and delivery from then on ran through reviewed pull requests with daily written updates, so the client could see exactly what changed and why. For the language-learning platform, moving to a new schema meant rehearsing a zero-loss data migration with custom console commands and seeders before touching production, then standing up a staging environment and writing deployment runbooks so the next handover wouldn't repeat the same problem.