Before You Rebuild, Find Out What You Already Have

When a project stalls, starting again can feel cleaner than inheriting someone else's decisions. Sometimes that is right. Often, you cannot know until the existing system has been examined properly.

Your developer may have stopped responding. The product may work in testing but fail under real use. Or months of work may have produced something that is still not ready to launch.

Software projects can stall through missed requirements, technical problems, changing scope, poor handover or simply an incomplete delivery.

Do not assume that everything built so far is worthless. Existing code, data, integrations, designs and business logic may still be usable even when the overall project has failed to reach production.

First, Preserve What You Have

Before appointing someone new to continue the build, understand the condition of what they would inherit.

Without that assessment, a new supplier is being asked to make decisions before the underlying problems are understood.

What to do right now: Secure access to all code repositories, servers, and accounts. Document what works and what doesn't. Collect all project documentation, designs, and communications. Don't delete anything, even code that seems broken.

Establish the Technical Reality

A technical assessment should establish what is usable, what is risky, what is missing and what each realistic recovery option involves.

The time and cost of an assessment depend on the size, complexity and condition of the system. Its purpose is to replace assumptions with evidence before further budget is committed.

A useful assessment should cover architecture, maintainability, security, deployment, testing, major risks and the work required under each viable route forward.

Work Out Why the Project Stalled

Failed projects fail for reasons. Understanding the reason determines the fix.

The Disappearing Developer

Freelancer or small agency went silent. Code exists but nobody knows how it works. Usually the fix is: audit the code, document it, and bring in a new team to finish.

The Scope Creep Spiral

Project started small, grew constantly, and the team couldn't keep up. Features were bolted on without architectural planning. The software works but is fragile and slow.

The Wrong Technology Choice

Someone chose a framework or platform that doesn't fit the requirements. A WordPress site trying to be a SaaS platform. A mobile app built with outdated tools. This sometimes requires a rebuild, but you can often port the business logic and data.

The Communication Breakdown

The agency built what was specified, but what was specified wasn't what was needed. The software works, just not for your actual use case. Typically fixable through a focused redesign of key workflows, not a full rebuild.

The Quality Gap

Everything looks right on the surface, but the code has no tests, no error handling, and falls apart under real-world conditions. Usually fixable: add testing, error handling, and monitoring.

Decide What to Keep, Change or Replace

Rescue or rebuild is a judgement, not a formula. Weigh how much of the existing functionality is genuinely useful, whether the architecture can support what you need next, how serious the security issues are, how hard the data will be to migrate, how much effort a replacement would take, and how maintainable each route will be. Then compare the total cost and risk of both routes, not just the build estimate.

Plan the Next Stage Around What You Found

Not every developer can rescue someone else's code. It requires patience to read unfamiliar architecture, diagnostic ability, pragmatism, and strong communication.

Questions to ask: Have you rescued a failed project before? Will you do a paid code audit before committing to a timeline? Can I see working software every 2 weeks? What happens if the audit reveals the project should be rebuilt instead?

Keep Control of the Project This Time

Make sure access to repositories, hosting, credentials and production environments is agreed from the start. Define ownership, documentation, testing and payment milestones before work resumes.

You Do Not Always Need to Begin Again

A failed software project feels catastrophic in the moment. But it's rarely as bad as it seems. Most projects can be saved. The most expensive mistake isn't the first failure. It's panicking and making the same mistake twice with a new team.

Secure what you have. Establish what works, what does not and what the realistic options cost. Then decide whether to improve it, rebuild part of it or replace it.