Rescuing a Stalled Software Project: The First Two Weeks

The first two weeks of a software project rescue are about facts, not fixes. In days 1 to 3 we get the project building and deploying from a clean machine. In days 4 to 10 we map what works, what half-works, what is missing and where the data lives. By day 14 you have a short written plan with weekly milestones you can check on a staging link.

Rescue projects arrive in a similar state: a codebase nobody fully understands, a deadline that has already passed, and a team that has lost confidence in estimates. Sometimes the previous vendor has gone quiet. Sometimes the original developer has left. Either way, the business still needs the product, and nobody can say with any certainty how far away it is.

Why the first instinct is usually wrong

When a project is late, the pressure is to start fixing immediately. Pick the most visible bug, ship something, show progress. It feels productive, but on an unfamiliar codebase it often makes things worse. A fix in one place breaks something elsewhere, and now the team has lost more confidence, not less.

The other common instinct is to throw everything away and start again. Sometimes that is right. More often, parts of the project are sound and worth keeping. You cannot tell which until you have looked properly.

So the first two weeks are spent finding out what is actually there.

Days 1 to 3: get it running

Before changing anything, we get the project building and deploying from a clean machine. If that takes three days, the next team would have lost those three days too.

This step reveals more than it seems. It shows which secrets and keys are hard-coded, which steps live only in the previous developer’s head, and which services the product depends on that nobody listed.

What “running” means

• The code builds from the repository with no manual edits
• A fresh database can be created and filled with test data
• The app runs locally and connects to the services it needs
• It can be deployed to a staging environment by following written steps
• Every one of those steps is written down

Accounts and access

At the same time we list every account the product relies on: code hosting, cloud hosting, database, domain and DNS, email sending, payment gateway, app store accounts, maps and analytics. For each one, the question is simple: is it registered to your company?

Anything held under a former vendor’s or employee’s personal account is a risk. Moving it is often the most valuable thing done in the first week, even though it involves no code at all.

Days 4 to 10: map what exists

With the project running, we work through it feature by feature and record what we find.

• Which features work, which half-work, which are missing
• Where the data lives and who can access it
• Which parts are safe to keep and which need rewriting

How we sort the code

Category	What it means	Usual action
Keep	Works, readable, has a clear purpose	Leave alone, add tests where useful
Repair	Mostly works, with known bugs or gaps	Fix in place during the plan
Rewrite	Unreliable, unreadable or unsafe	Replace, in small pieces
Remove	Unused or abandoned code	Delete, after confirming nothing calls it

Keeping the categories simple makes the plan easy to discuss with non-technical stakeholders. Everyone can see the shape of the problem.

The data matters more than the code

Code can be rewritten. Data cannot be recreated. We check the database structure, look for records that are inconsistent or duplicated, and confirm backups exist and can actually be restored. If production data is involved, we make sure no one is working against it directly before anything else changes.

Talk to the people who use it

The code shows what was built. The users show what was needed. We spend time with the people who will use the product, or who tried earlier versions, to hear where it failed them. Often the gap between what was specified and what is needed explains much of why the project stalled.

Days 11 to 14: a plan you can check

The output is a short written plan with weekly milestones, each one demonstrable on a staging link. Confidence comes back when progress can be seen, not just reported.

A milestone you cannot click on is a status update, not progress.

What the plan contains

1. A plain summary of the current state, using the keep, repair, rewrite and remove categories
2. The risks we found, ranked, with what we will do about each
3. Weekly milestones, each one something you can try on staging
4. What is deferred, and why
5. What we need from you, and by when

The plan is deliberately short. A long document is harder to check, and the point is that you can check it. Every Friday you open the staging link and see whether that week’s milestone is there.

Common findings in stalled projects

Across rescue work, the same issues come up again and again:

• No way to set up the project from scratch. Knowledge lived in one person’s head.
• Accounts in the wrong names. Hosting or app store accounts under the previous vendor.
• No staging environment. Changes went straight to production, so every change was risky.
• Scope that kept growing. New requests were added without anything being removed.
• Status reports instead of demos. Progress was described rather than shown, so problems surfaced late.

Most of these are not technical failures. They are process failures that made the technical problems invisible until late.

How to avoid needing a rescue

The habits that prevent a stalled project are the same ones that fix it:

• Own your source code and every service account from the first commit
• Insist on documentation that lets a new developer set up the project
• Ask for a working demo on a staging link every week
• Keep scope fixed for each phase, and write deferred items down
• Talk directly to the person building the product

These are built into how we run new work. Our post on what a 4-week AI MVP includes shows them in a fixed sprint, ending with handover of the code, documentation and admin access.

If you have a project that has stalled, tell us where it stands. We will start by getting it running, and tell you plainly what we find. You can also see the kind of products we have built and supported, such as a clinic management system that replaced three legacy systems, or how our ready-made ERP starts on the standard flow and is extended only where it falls short.