How to Rescue a Failing Software Project (and When to Start Over)

Projects rarely fail in one day. They drift, and the signals are easy to explain away one at a time. Taken together, they are hard to ignore:

• Deadlines move again and again, each time with a new reason.
• Every fix breaks something else, and the same bugs come back.
• Nobody can give a straight answer about when the product will launch.
• The developer or agency is slow to reply, or has stopped replying.
• You do not have access to the code, the servers or the accounts.
• New developers say they cannot work with the code without "rewriting it first".

One of these is a warning. Three or more usually mean the project needs a rescue, not another deadline.

For example, a startup whose freelancer has stopped answering, and who holds the only server password, is in a rescue situation even if the code itself is fine.

The first week sets up everything that follows. Four steps come before any technical work:

• Pause new features. Building on an unstable base adds cost to every later fix.
• Secure access. Make sure you control the code, servers, domain and every service the product depends on.
• Write down what was promised and what exists. Collect the proposal, the contract, the designs and a list of what actually works today.
• Hold payments that are not tied to delivered work. If payments follow milestones, pause the next one until there is a clear plan.

Do not start the search for blame. Who left the project in this state, and why, matters much less than what can be done now, what it costs and when the product will work.

Access is the part founders most often discover they do not have. Check each item on this list and note who controls it today:

• The code repository, with full history, not a zip file of the latest version.
• Hosting and server accounts, including databases and backups.
• The domain registrar and DNS settings.
• App store developer accounts, if there is a mobile app.
• Third-party services: payments, email, analytics, maps, AI APIs.
• Design files and any documentation that exists.

If the repository sits in someone else's account, ask them to transfer it. GitHub's documentation explains how a transfer keeps the history, issues and pull requests intact.

If someone will not cooperate, recover what you can from your own side: domains and hosting are often registered with your card or email, and that gives you a way back in.

An audit is a structured look at the product as it actually is, not as the last vendor described it. A useful audit covers these areas:

• Architecture. How the parts fit together, and whether the structure can carry the features you need.
• Code quality. Readability, duplication and how risky it is to change things.
• Security. Common risks such as those in the OWASP Top 10, plus how secrets and personal data are stored.
• Infrastructure. Hosting, deployment, backups and monitoring.
• Tests and documentation. What exists, what is missing and what it would take to add them.

The result should be a plain verdict for each part of the product: keep, fix or rewrite, with the reasons. Only then can anyone give you a price that reflects the code as it is.

At Sakura we work in exactly this order: audit first, quote second. It is the only way to avoid pricing a rescue on promises the code does not keep.

Stuck with a project right now? Tell us what happened. We will start with access and an audit, and tell you honestly what can be saved.

Usually, fix it. Old code that runs in production carries years of small fixes for real-world problems, and a rewrite throws them away along with the bad parts.

Joel Spolsky made this case in his well-known essay Things You Should Never Do. He called rewriting code from scratch "the single worst strategic mistake that any software company can make", using Netscape as the example: its rewrite took nearly three years while competitors moved ahead.

There are cases where a rewrite is the honest answer. This table shows how we weigh them:

Even when a rewrite wins, it rarely has to happen all at once. Martin Fowler's Strangler Fig pattern describes replacing a system piece by piece, building new parts alongside the old ones until the old code can be switched off.

If the previous developer or agency is still reachable, a calm, short handover saves time and money. Ask for three things: access to everything, a list of known problems and a one-hour walkthrough of how the product is deployed.

Keep the conversation practical. People share more when they are not being blamed, and the details they remember about the code are worth more than any argument about who is at fault.

If the previous team is not cooperating, do not wait for them. Recover the accounts you control, start the audit with what you have, and keep a written record of what you requested and when.

Once the verdict is clear, work in a strict order. Launch first, improve second:

• Stabilise. Fix the critical bugs that crash the product, lose data or block payments.
• Finish the launch flows. Complete only what the product needs to go live; everything else waits.
• Set up deployment and monitoring. So releases are routine and problems are visible before users report them.
• Launch. Real users will show you which of the remaining issues actually matter.
• Improve. Work through the rest of the list in order of business impact.

Weekly builds you can click through keep the rescue honest. After a project has gone wrong once, you should see progress every week, not hear about it.

For example, a startup whose agency missed several deadlines may find that most of the product works and three broken flows block the launch. Fixing those three first gets the product live, and the rest of the backlog can be planned with real usage data.

It depends on what the audit finds, which is why an honest quote comes after the audit, not before. Anyone who prices a rescue without looking at the code is guessing.

Once the audit is done, the work to launch can usually be priced as a fixed scope. That gives you a clear number for getting the product live, separate from the improvements that come after.

If you are comparing offers for the rescue itself, the same rules apply as for any project. Our guide to fixed price vs. hourly development explains when each model fits.

A rescued project is a chance to put the safeguards in place that were missing the first time:

• Ownership. The repository, hosting, domain and app store accounts stay in your company's name.
• Documentation. Written as the work happens, so the product never depends on a single person.
• Milestones. Payments follow results you can check, such as a working build on a test link.
• A change process. New requests are estimated and approved before anyone starts on them.
• Support after launch. A clear plan for fixes and updates, such as a monthly support plan.

If you will choose a new team for the next phase, our guide on how to choose a development agency lists the questions that expose weak partners before you sign.

When you are ready to get your product moving again, send us a short brief. We will start with access and an audit, so you know where you stand before any larger commitment.