Skip to content

How to Rescue a Half-Finished or Abandoned Software Project

A stalled or abandoned software project is not a dead end. Here is the step-by-step way to assess what you have and get it delivered.

By Karani Geoffrey, Founder & CEO, Upeosoft
In short

To rescue an unfinished software project, start with an honest technical audit of what actually exists, secure your code and credentials, then decide whether to continue, refactor, or rebuild based on evidence. Bring in a capable team to stabilise the system before adding features. Most stalled projects can be saved when handled in the right order.

Key takeaways
  • Secure your code, credentials, and accounts before anything else.
  • Get an independent audit; "90 percent done" is often closer to half.
  • Decide to continue, refactor, or rebuild based on evidence, not sunk cost.
  • Stabilise what exists before piling on new features.
  • A capable team can take over unfamiliar code, but a clean handover speeds it up.
  • Lock in code ownership and demos so the next phase cannot stall the same way.

A stalled project is not a lost cause

When a software project grinds to a halt, it is easy to feel that the time and money are simply gone. In reality, most stalled and abandoned projects can be rescued when they are approached methodically rather than in panic.

The difference between recovery and further loss is order. Rushing to add features or begging an absent developer to return wastes energy. A calm, structured sequence turns a scary unknown into a concrete plan you can act on.

Step one: secure your assets

Before anything else, take control of everything the project depends on. If access is lost later, recovery gets far harder, so this comes first.

  • Source code in whatever repository holds it.
  • Domain registration, ideally confirmed in your name.
  • Hosting and server or cloud account credentials.
  • Databases and any data exports you can obtain.
  • Third-party keys for M-Pesa, payment gateways, SMS, and WhatsApp.
  • The paper trail: contracts, invoices, and chat history with specifications.

Step two: get an honest audit

Do not take anyone's word on how complete the work is. "Ninety percent done" is one of the most misleading phrases in software, and the last ten percent is frequently where the hardest work hides.

Have an independent, capable team examine the code, run the system, and test the integrations. A proper audit tells you what genuinely works, what is missing, how sound the foundation is, and what finishing will realistically take. This clear picture is the foundation for every decision that follows.

Step three: decide to continue, refactor, or rebuild

With the audit in hand, choose deliberately. If the foundation is solid, continuing from it preserves the most value. If the code works but is fragile, targeted refactoring of the weak parts may be the right balance. If it is fundamentally unsound, an honest rebuild avoids throwing good money after bad.

Resist the pull of sunk cost. What you already spent is gone regardless; the only question that matters now is which path gets you to working software for the least additional time and money.

Step four: stabilise before you build

Whichever path you choose, resist the urge to immediately pile on the features you have been waiting for. Inherited software needs to be understood and stabilised first. That means getting it running reliably, fixing the foundation where needed, and documenting how it works.

Building new features on an unstable base just multiplies the problems. A short investment in stability now makes everything that follows faster, safer, and cheaper.

Step five: protect the next phase

As you restart, put in place the disciplines that were probably missing the first time. Own your code, domain, and credentials outright. Insist on regular working demos so progress is always visible, and tie payments to milestones rather than promises.

Make sure more than one person understands the system and that documentation stays current. These habits cost nothing and are what stop a rescued project from stalling all over again.

The local advantage in a rescue

Taking over unfinished work benefits enormously from proximity. A local team can move quickly on the audit, meet you to talk through options, and give you a realistic plan without the delays of a time-zone gap. Accountability is real because you can hold them to it.

For Kenyan projects, local knowledge also matters at the technical level. M-Pesa, eTIMS, and statutory integrations are often exactly where the previous work stalled, and a team that handles these routinely can get past the blockage that stopped the last developer.

How Upeosoft rescues stalled projects

Upeosoft regularly takes on half-finished and abandoned software for Kenyan businesses. We begin with a clear-eyed audit so you know exactly what you have, then give you an honest recommendation to continue, refactor, or rebuild, with a realistic timeline and cost.

We stabilise the system, handle the local integrations that so often cause the stall, and get momentum back. Because we are local, you can meet us and hold us accountable. If your project has stalled, reach out and we will help you turn it back into working software.

Frequently asked questions

How do I know if my project is worth saving?

An honest audit answers this. If the foundation is sound and much of the work functions, continuing is usually cheaper than starting over. If the code is fragile, undocumented, or built on poor choices, a partial or full rebuild may cost less over time. The decision should rest on evidence, not on how much you have already spent.

What does a project audit actually involve?

A capable team reviews the source code, runs the system, checks the integrations, and reads whatever documentation exists. They report what works, what is missing, how sound the foundation is, and what it will take to finish. You come away with a realistic plan, timeline, and cost instead of guesses.

Is rebuilding always more expensive than continuing?

Not always. Continuing looks cheaper but can cost more if the existing code is so poor that every change is slow and risky. Sometimes a clean rebuild of the worst parts, while keeping the good, is the most economical path. The audit is what tells you which is true for your project.

Can a new team really take over someone else's code?

Yes, this is a specific and common skill. Experienced teams regularly inherit unfamiliar codebases, map how they work, stabilise them, and continue. It goes faster when you have secured the code, credentials, and any documentation, which is why protecting those assets early matters so much.

Karani Geoffrey
Karani Geoffrey
Founder & CEO, Upeosoft

Karani Geoffrey is the Founder & CEO of Upeosoft, a software and automation company rooted in Kenya. He builds custom software, AI systems, and production-grade ERPNext for businesses across East Africa, and writes about the Kenyan realities - eTIMS, M-Pesa, SHIF, unreliable internet and power - that make or break real systems.

Next step

Want this working in your business?

Upeosoft builds and hardens the systems behind this article - for real Kenyan operations, with eTIMS, M-Pesa and offline realities handled.

Keep reading

Build, Buy or OutsourceBuyer's guide

Custom Software vs Off-the-Shelf: Which Do You Actually Need?

Custom is not automatically better, and ready-made is not automatically cheaper. Here is how Kenyan businesses can decide which one they actually need.

5 min readRead article →
Build, Buy or Outsource

What Digital Transformation Really Means for a Kenyan SME

Digital transformation is not about buzzwords or big budgets. For a Kenyan SME it means using technology to remove friction, one real problem at a time.

5 min readRead article →
Build, Buy or Outsource

Signs Your Business Has Outgrown Spreadsheets and WhatsApp

Spreadsheets and WhatsApp carry most Kenyan businesses at the start. Here are the signs they are now costing you more than they save.

5 min readRead article →