What to do when your software project has failed

If your software project is months past its promised date, the demos never become something your team can use, and the vendor's answers are getting slower while the invoices are not, this guide is for you. The recovery path is not a lawsuit and it is not paying the same vendor to finish. It is three moves in order: quietly secure everything you own, get an honest assessment of what actually exists, and restart delivery in small working slices instead of a second big promise. Most founders in this situation have already paid ₹5L or more. The goal from here is simple: do not pay twice for the same system.

How to know it has actually failed

Every project slips a little. 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.

A story we know first-hand

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. 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.

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.

Frequently asked questions