What to do when your software project has failed

To recover a failed software project, secure everything you own first, stop paying for promises, get an honest assessment of what actually exists, and restart delivery in small working slices instead of a second big promise. The answer is rarely a lawsuit, and rarely paying the same vendor to finish. Most founders in this position have already paid ₹5L or more. The goal from here is not to pay twice.

How do you know the project has actually failed?

Every project slips a little. Research by McKinsey and the University of Oxford found that large IT projects run 45 percent over budget on average. A failed one has a pattern, and it is worth naming honestly so you stop explaining it away:

• The timeline has slipped by multiples, not weeks. Promised in one month, and at month four there is still nothing your team uses daily.
• You have seen demos, but never software. Something always works on the vendor's laptop and never in your office.
• New charges appear for things you believed were included.
• The vendor's replies are slowing down while yours are speeding up. You are chasing them.
• Nobody can tell you, in plain words, what is finished and what is not.

Two or more of these, and you are not managing a delay. You are in a failed project, and the sooner you act like it, the more you save.

What does a recovery look like in practice?

That order of operations, assess honestly, then deliver in slices, is the whole recovery playbook. Here it is in detail.

Step 1: Secure what is yours, before anything else

This is the step most founders miss, and the one that decides how bad the worst case gets. While the relationship is still civil, before any hard conversation about money or endings, get copies and access for everything the project has produced:

• The code, in a repository you control, not just on the vendor's machines.
• The database and its data, exported where you can reach it.
• Every account in the project's orbit: domain, hosting, cloud services, API keys, app store accounts. Know the passwords, and know which email owns each.
• The paper trail: the original scope, quotes, and payment records, in one folder.

A vendor who feels a dispute coming has exactly one card to play: holding access hostage. Take that card off the table while things are still polite. If your contract says you own the work, this is simply collecting your property. Read that clause closely: under Indian copyright law the author is ordinarily the first owner of a work, and an assignment has to be in writing and signed, so with an outside vendor your ownership of the code rests on what the contract says. If the vendor resists giving you access to work you have paid for, you have learned something important, and you have learned it early.

Step 2: Stop paying for promises

The reason founders stay in failed projects is not stupidity. It is arithmetic that feels right and is not: "I have already paid ₹6L, if I leave now it is wasted." That money is spent whether you stay or leave. The only question that matters is what each rupee from today buys.

So change the rule of engagement, with this vendor or any next one: money moves when working software lands, not when promises are made. No more advances against end-to-end deliveries. If the current vendor can genuinely finish, they can prove it by shipping one working piece. If they cannot ship one piece, they were never going to ship the whole.

Step 3: Get an honest reading of what exists

Before deciding to salvage or rebuild, someone senior has to actually read the code and try to run the system. Not a sales call. An assessment. It usually lands in one of three places:

• Worth keeping. The foundations are sound and the fastest path is finishing on top of them.
• Partially worth keeping. Some pieces work, and the fastest path keeps those and rebuilds around them.
• Worth leaving. Finishing the existing work would cost more than starting clean. It happens more often than anyone likes, and finding out now is far cheaper than finding out after another ₹5L.

Be suspicious in both directions. A new vendor who says "throw it all away" without reading a line of code is selling you a rebuild, not giving you an assessment. And one who promises to salvage everything may just be telling your sunk-cost instinct what it wants to hear. The honest answer comes after the reading, not before it.

Step 4: Recover in slices, never in a second big bang

Here is the thing about the failed project: it usually failed because everything was promised at once. An end-to-end system, delivered at the end. Which meant month after month with nothing to use, no way to check progress, and trust draining on schedule.

The recovery must not repeat that shape. Whoever finishes the work, have them deliver the single most valuable piece first, as working software your team uses, within weeks. Then the next piece. Each slice is proof, and proof is the only thing that rebuilds trust after a burn, because after what you have been through, no promise will, and no promise should.

This is exactly how we run rescues at SAAR. When a founder comes to us with a half-built system, we audit what exists, in person, code and all. We break the remaining work into slices ordered by value to the business, and put the first slice live in two to three weeks, with a quote agreed upfront and everything in your name from day one. The construction founder above did not need a new grand promise. He needed something his team could use this month, and then the next thing. Trust came back the same way it left: through delivery.

How do you make sure it never happens again?

The habits that get you out are the same ones that keep you out: pay against working software, keep every account in your name, and demand something real early. Before you sign with anyone new, read our guide to choosing a software agency, the six red flags there are largely a description of the vendor you just left. And if the burn has you considering hiring your own team instead, read the honest arithmetic on in-house versus external teams first. Before you agree a new quote, check it against what custom software actually costs in India.

Frequently asked questions