I have an unfinished project no one wants to complete—now what?

Have you ever heard of the 99% syndrome? That’s when software development is already in its final stages, but problems keep popping up and the delivery date seems further away each time. This is a terrible situation—and more common than you’d think—that sometimes leads to an unfinished project, abandoned by the developers.

What leads an unfinished project to abandonment?

First, let’s make it clear: no one starts a project intending not to finish it! As a client, you’re looking for a provider who will deliver a finished, properly working software product. And the provider, in turn, also commits to developing it completely.

There are exceptions, of course, but assuming good faith on all sides, people don’t plan for a project to be left unfinished. So why are there so many stories like this? Simple: most providers develop software with only one real delivery planned, saving functionality testing for the end of the project.

That means the client (and even the provider) only sees the software actually working after months of development, when it’s almost fully built. So if bugs show up (as they often do during real use), the project is already too far along to accommodate changes. The team then starts looking for patchwork fixes, which create even more issues—and the project ends up stuck in a vicious cycle of incompletion!

Eventually, the developers realize it’s impossible to fix the flaws without rebuilding everything. They start dodging the client’s calls and… vanish! The project is abandoned. Awful, right?

How can you make sure the provider delivers what was promised?

The bigger the project, the greater the chances of problems arising, due to system complexity and coupling.

Complexity refers to how difficult the software is to code based on the amount of logic required to meet its goals. Coupling refers to how interconnected different parts of the software are—meaning a change in one area unexpectedly affects others.

Ideally, both complexity and coupling should be minimized, but that’s not always feasible. That’s why we recommend splitting the project into small, complete parts to reduce risks and simplify adjustments.

Instead of spending months approving static layouts and prototypes before seeing a working system, break the software into several smaller, functional parts. That way, the project’s intermediate deliveries will be “the real thing”—actual coded software for specific sections of your system. As a result, any bugs that arise will be detected early and can be fixed more easily and quickly.

Also, communication between the client and development team must be fluid and continuous throughout the project. Questions and insights will naturally come up from both sides, influencing decisions on how the software should be built. That’s why it’s essential to maintain direct contact between developers and the client, so doubts can be clarified and expectations aligned while there’s still time for structural changes.

Is it possible to salvage an unfinished project?

It depends! A project abandoned by its original developers likely reached a point of unmanageable problems—even for its creators. There may be so many bugs that fixing one triggers others, making it not even worth the effort.

On the other hand, there may be parts of the software that aren’t tied to the faulty ones and don’t require fixing. In that case, it’s worth analyzing the cost-benefit of repairing the broken parts to preserve your investment—or deciding if it’s better to start from scratch.

So, when hiring a new provider, be extra careful to avoid ending up with another unfinished project! Always choose providers with proven experience who prioritize code quality and automated testing, and who deliver the project in small, functional increments.

Need help? Reach out to our team!

By Joana Kerr