Your last software project failed. Now what?

Plenty of businesses shopping for software aren’t starting a project. They’re recovering from one. Half-finished builds, developers who stopped replying, systems delivered and never adopted, budgets that doubled and then the relationship ended badly.

If that’s you: it’s common enough that there’s a playbook, and the failure probably says less about your business than you think. Here it is.

First, triage what exists

Before any talk of round two, three questions about the wreckage:

Do you own the code? Check the contract, then check practically: does anyone on your side have access to the source (a repository, a handover, an export)? If it only exists on the old developer’s machine or account, getting a copy is the first move, made politely and soon, while everyone’s still answering email.

Is your data trapped? Often the data matters more than the software. If customer records or job history live only inside the failed system, exporting them is urgent in a way the code isn’t. Data ages badly, and access has a way of disappearing along with goodwill.

Does any of it work? “Failed” often means 70% built and 0% usable, and those are very different from worthless. A salvage assessment by a third party is cheap and tells you whether round two starts from scratch or from 70%. Be suspicious of any new developer who declares everything garbage sight unseen. Rewriting from zero is more billable, and some companies reflexively prescribe it.

Then, an honest post-mortem

Failures cluster into a few patterns, and naming yours changes what you fix.

Sometimes the scope drifted: the “job tracker” grew a portal, then invoicing, then nobody could say what “done” meant. That failure gets fixed by scoping one workflow at a time. Sometimes the builder was wrong. The warning signs were probably visible early, and I keep a list of them, written from the paying side of my own bad experiences. And sometimes (this one’s hard to admit) custom was the wrong call from the start, and round two should be buying the off-the-shelf tool that was there all along. Walking away isn’t losing twice; it’s stopping the loss.

De-risking round two

If round two is still custom, structure it so this can’t happen again:

Own everything from day one: code in a repository you control, accounts in your name. Non-negotiable, and good developers won’t blink.

Pay for milestones you can see. The first should be small, working, and in your team’s hands within weeks. The fastest way to find out what a company is like is a small deliverable, not a big promise.

Insist on seeing progress regularly: working software, not status reports. The projects that die slowly are the ones nobody looks at for two months.

That structure is how I run projects, but the point is portable: demand it from whoever you hire, and you’ve eliminated most of the ways round one went wrong.

The awkward first call

One more thing, because it’s easy to feel embarrassed about: no reputable developer thinks less of you for a failed project. Bring the wreckage, and the whole messy story. A good one will tell you what’s salvageable, what happened, and what round two should look like, including “buy something instead.” If you want that assessment, I’m here. The story is never as embarrassing as you think it is.