The launch date has moved three times. The freelancer who built most of the app has stopped replying. The agency's latest invoice was bigger than the last, but the product isn't noticeably closer to done. Your CTO is spending nights fixing bugs instead of planning the roadmap. And customers, investors or your board are asking when it will be ready.

If that sounds familiar, you're not alone, and you're not stuck. In our experience, most stalled software projects can be recovered, often without starting again. This guide shows how to tell how much trouble you're in, what it's really costing you, and the five steps to get your project shipping again.

The short answer

To rescue a stalled software project: secure your code and accounts, get an independent review of what's actually been built, decide whether to fix or rebuild, ship one small win fast, and put a stable team behind it. In our experience, most projects need a fix, not a rebuild. The biggest mistake is waiting: every month a project drifts costs you in salaries, fees and lost revenue.

Project stuck right now? Black Vault takes over stalled projects and gets them moving again. We'll review where you are and deliver the first portion of the work free, so you see progress before you commit.

Get your project back on track →

Seven signs your project is in trouble

If three or more of these apply, it's time to act:

  1. Deadlines keep moving and nobody can give you a confident new date.
  2. The developer or agency has gone quiet, left, or only one person understands the code.
  3. Every new feature breaks something else.
  4. You don't have admin access to your own code repository, hosting or domain.
  5. Costs keep rising with no clear link to delivered features.
  6. There's no documentation, and no one can explain how the system fits together.
  7. Your best people are firefighting instead of building.

Why projects stall

In our experience, the cause is rarely one bad developer. It's usually how the project was set up:

  • A revolving door of freelancers. Different people with different standards, each leaving with knowledge you never captured.
  • An agency that's too expensive to keep and too embedded to leave. Every change costs more, and switching feels impossible.
  • A stretched CTO. One technical leader trying to manage contractors, write code and plan the product, with no support.
  • Unclear ownership. No one on your side has the time or authority to make quick decisions, so work stalls waiting for answers.
  • Scope that kept growing while the budget and timeline didn't.

The good news: every one of these is fixable with the right team and structure.

What waiting is really costing you

A stalled project is rarely free. Add up what each month of delay costs your business:

Cost of a stalled month What to count
Fees and salaries What you're paying developers, agencies or staff for little visible progress
Your team's time Hours your CTO, product lead and managers spend chasing and firefighting
Lost revenue Sales, subscriptions or savings the finished product should already be delivering
Customer and investor confidence Missed launch dates erode trust and can delay funding or contracts
Competitive ground Every month you're not live is a month a competitor can be

Put real numbers against each line. For most businesses, the monthly cost of doing nothing is far higher than the cost of fixing the problem properly.

The five-step rescue plan

Step 1: Secure your code, accounts and IP

Before anything else, make sure you control what you've paid for. Get admin access to the code repository, hosting, cloud accounts, domains, app store listings and any third-party services. Collect every password, API key and document.

Check your contracts too. In Australia, a contractor owns the copyright in code they write unless a signed agreement assigns it to you. If your freelancer or agency contract doesn't include a clear IP assignment, fix that now, while the relationship is still workable.

Step 2: Get an independent review of what's been built

You can't plan a rescue without knowing what you have. An experienced engineering team should review the codebase, architecture, security and test coverage, and tell you in plain business terms:

  • what works and can be kept,
  • what's fragile or risky,
  • what's missing compared with what you were promised,
  • and roughly how much work remains.

In our experience, this takes days to a couple of weeks, not months, and it replaces guesswork with a clear picture you can make decisions on.

Step 3: Decide whether to fix or rebuild

In our experience, most stalled projects can be fixed. A rebuild is the exception, and it should be justified by evidence from the review, not frustration.

Fix and continue when… Consider a rebuild when…
The core architecture is sound The architecture can't support what the business needs
Problems are concentrated in specific areas Problems are everywhere and every fix creates new ones
The technology is current and supportable The technology is outdated or hard to hire for
Most features work, even if roughly Little of the existing work is usable
You need to get to market quickly You have time, and a rebuild is cheaper over three years

A middle path is common: keep what works, and rebuild the weakest parts one at a time while the product keeps running.

Step 4: Ship one small win, fast

A rescue needs momentum. Pick a small, visible piece of work, such as a critical bug, a stalled feature or a performance problem, and get it delivered in the first few weeks. It proves the new team can deliver, rebuilds confidence with your stakeholders, and shows you how the team works before you commit to more.

See the rescue working before you pay for it. Black Vault will deliver the first portion of your project free of charge: we take over the code, fix something that matters, and show you the result.

Start with a free first deliverable →

Step 5: Put a stable team behind it

The fastest way back into trouble is to repeat the setup that caused it. Replace the revolving door with a team that stays: ideally a dedicated team with its own technical lead, shared coding standards, documentation as part of the work, and regular demos so you always know where things stand.

That doesn't have to mean expensive local hiring. Australia needs an extra 259,000 tech workers over the next decade, so finding and keeping local developers is slow and costly. An offshore dedicated team gives you continuity at a fraction of the cost. Our breakdown of what an offshore developer really costs compares the numbers by role, and our guide to staff augmentation, dedicated team or project outsourcing explains which setup fits.

How Black Vault rescues stalled projects

We regularly step into projects that other teams started: apps built by a rotating cast of freelancers, platforms an agency became too expensive to maintain, and products where a single overworked CTO has been holding everything together. Our approach follows the five steps above: secure, review, decide, deliver a quick win, then provide a stable end-to-end team that takes the product forward.

Because our engineers are based in Sri Lanka, you get senior engineering capacity at a fraction of Australian costs, with a shared working afternoon with the east coast.

Talk to us about your project. Tell us where things stand and we'll tell you honestly whether it needs a fix, a takeover or a rebuild, and deliver the first piece of work free.

Book a project review →

Frequently asked questions

Click a question to see the answer.

Act quickly to protect what you've paid for. First, secure admin access to your code repository, hosting, cloud accounts, domains and any third-party services, and collect all passwords, keys and documentation while you can still reach the developer. Check that your contract assigns the IP to you; in Australia a contractor owns the copyright in code they write unless a signed agreement transfers it. Then have an experienced team review the codebase so you know what's been built and what remains. From there you can decide whether a new team should continue the work, fix parts of it, or rebuild. Waiting usually makes the handover harder and more expensive.

Yes. Taking over an existing codebase is common, and it's usually faster and cheaper than starting again. A good takeover starts with securing access to your code and accounts, then a review of the code, architecture and security so the new team understands what they're inheriting. They should then agree a short plan with you, deliver a small, visible improvement early, and document the system as they go. Look for a company that has worked with inherited code before, gives you an honest assessment of what's there, and will prove itself on a small piece of work before you commit to a long engagement.

In our experience, most projects should be fixed rather than rebuilt. If the core architecture is sound and the problems are concentrated in specific areas, fixing and continuing gets you to market faster and costs less. A rebuild makes sense only when the review shows the architecture can't support your business needs, problems are spread throughout the system, the technology is outdated or hard to support, or little of the existing work is usable. Many businesses take a middle path: keep what works and rebuild the weakest components one at a time while the product stays live. The decision should come from an independent technical review, not frustration with the previous team.

The cost depends on the size and condition of the codebase and how much work remains, which is why the first step is a review. In our experience, that review takes days to a couple of weeks and gives you a clear estimate for fixing, continuing or rebuilding. Rescue work is often cheaper than expected because, in our experience, most of the existing code can be kept. Using an offshore team can reduce the cost further, since developer salaries in markets such as Sri Lanka are a fraction of Australian rates. Compare the rescue cost with what each stalled month is already costing you in fees, staff time and lost revenue.

You should see meaningful progress within weeks, not months. In our experience, securing access and reviewing the code takes days to a couple of weeks. A good team will then deliver a small, visible win, such as fixing a critical bug or finishing a stalled feature, within the first few weeks of taking over. How long it takes to reach a full launch depends on how much work remains and whether parts need rebuilding, but a clear plan with regular demos lets you track progress from the start. If a new team can't show you progress early, that's a warning sign.

Fix the setup, not just the code. Replace rotating freelancers with a stable team, ideally a dedicated team with its own technical lead, so knowledge stays with your product. Make sure someone on your side owns decisions and has time to make them quickly. Insist on shared coding standards, automated testing, documentation as part of every piece of work, and code held in repositories you control. Agree a regular rhythm of planning and demos so problems surface early. And make sure every contract assigns all IP to your business. Black Vault provides end-to-end teams set up this way, so the product keeps moving after the rescue.

Your project doesn't have to stay stuck. Black Vault will review where you are and deliver the first portion of the work free, so you see real progress before you commit.

Get your project moving again →