Software project rescue for late, stalled and inherited projects
Software project rescue is for the project that has gone wrong: the launch date has slipped three times, the agency has stopped answering, or you’ve inherited a codebase nobody on staff understands. You need someone senior to find out what you actually have, stop it getting worse and get something working into production.
I do that in a two-week sprint. You get a triage, a stabilized system and one real thing shipped, then an honest recommendation – including “this is fine, you need less help than you think” when that’s true.
The usual situations
- The vendor is gone. An agency or freelancer built it, the relationship ended, and you have a repository (hopefully) and a production server (probably) but no handover.
- A stalled software project. The team is working hard, tickets move, but the release never arrives. Every fix seems to break something else.
- An inherited codebase. You acquired a product, or the original developer left, and now you own code in a framework version that went out of support years ago.
- The website keeps crashing. Outages under load, memory climbing until the process dies, a database that falls over every Monday morning.
- It worked for one customer. The platform was built around a single client’s needs and now can’t take the second, third and tenth. That was the situation at Feenstra Group when I stepped in on the platform behind their new software vertical.
Two weeks: triage, stop the bleeding, ship one thing
- Secure the keys (days 1–2). Source code in a repository you control. Cloud, DNS, domain, email-sending and payment accounts owned by the company, not the departed vendor. Credentials rotated where the old team still has access.
- Prove it can be built (days 2–4). I build and deploy from a clean machine. If the only working deploy process is “SSH in and git pull on the server”, that’s noted and replaced with something repeatable.
- Find out what’s actually broken (days 3–7). Error tracking turned on if it isn’t, logs read, slow queries listed. Rescue projects tend to have a few root causes behind dozens of symptoms.
- Stop the bleeding (week 2). Backups that restore, basic uptime monitoring, the single worst crash or data-loss risk fixed.
- Ship one real thing (week 2). A bug fix or feature your users notice, through a process that will still work next month. This is the proof that the project can move again.
- Written triage. What you have, what it would take to finish, and whether to fix, partially rebuild or stop.
Why the website keeps crashing
Repeated crashes in a rescued system usually trace back to a short list of causes, and they’re worth checking before anyone suggests a rewrite:
- Database connections exhausted because each web worker opens its own pool and nothing like PgBouncer sits in front of Postgres.
- N+1 queries on a page that was fine with 50 rows and now loads 50,000.
- Cron jobs or background workers running on the same box as the web server and starving it on schedule.
- No timeouts on outbound HTTP calls, so one slow third-party API ties up every worker.
- A disk filling with logs or uploads until the database can’t write.
- Memory leaks masked by nightly restarts that someone stopped doing.
Each of these is usually a fix measured in days or weeks, not months. Deal with them before anyone commits to a rebuild.
Why software projects fail in the first place
Rarely because the developers were bad. The usual pattern is that nobody senior owned the technical decisions, scope grew faster than the team, and there was no way for the person paying to verify progress except demos. Weekly deploys to a staging environment the client can use, and a single person accountable for “is this done”, prevent most of it.
If you’re taking over a software project from an agency, I’ll also tell you whether the problems are in the code or in how the project was run. They need different fixes.
Rewrite or rescue?
My default is to rescue. A rewrite throws away the bug fixes and edge cases that live in the old code, and it stretches your timeline while the old system still needs care. I recommend rebuilding only when the data model is fundamentally wrong for the business, or the platform has no security support and no upgrade path. Even then, I prefer to replace it piece by piece. The trade-offs are covered in rewrite vs refactor and the strangler fig pattern.
If the code was generated quickly with AI tools and nobody fully understands it, that’s a specific kind of rescue – see vibe-coded app rescue.
After the rescue
Some projects need two weeks and a clear plan the existing team can follow. Others need me embedded for a few months to finish the release and hire the people who’ll own it. Either way, the goal is a system your team can run without me, with the decisions written down.
Questions
Can you take over a software project from another agency?
Yes. The first step is making sure you own the source code, cloud accounts and domains rather than the agency. With access secured, the two-week sprint is aimed at getting the project building, deploying and shipping fixes.
What do you need from the previous developers?
Ideally repository access, cloud and third-party account ownership, and any credentials for production services. Documentation is nice but rare. If the old team won’t cooperate, accounts registered in your company’s name can usually be recovered through the hosting and domain providers, though it takes longer. Anything registered in the vendor’s name comes down to your contract, and may need a lawyer.
Should we rewrite our inherited codebase?
Probably not yet. Most inherited codebases have a handful of root problems that can be fixed in place. A rewrite makes sense when the data model or platform is fundamentally wrong, and even then an incremental replacement is usually safer than a big-bang rebuild.
How quickly can you start on a stalled software project?
It depends on my current commitments, since I keep few clients at a time. When there is space, the two-week sprint starts as soon as I have access to the code and infrastructure. Get in touch and I’ll tell you honestly when I can begin.
Project late, vendor gone or code inherited?
Send me what you know about the state of it. In two weeks you’ll have a triage, a steadier system and one real fix in production.
GMT+2 · Full EU overlap · US East mornings