Stalled projects don't crash, they grind to a halt
You may recognize it. The project isn't dead. No one has pulled the plug, there has been no dramatic moment. It has just been “almost done” for months. Every update sounds reasonable, every delay has an explanation, and yet there is still no working software you can actually click on. The project isn't crashing — it's grinding to a halt.
That is exactly what makes it so insidious. A crash forces you to act. A slow grind doesn't. You keep waiting, hoping for the next sprint, and meanwhile the costs keep running and the trust keeps crumbling. The expensive mistake is almost never the rescue itself. The expensive mistake is the months you wait before you make the decision to intervene.
This article gives you an honest decision sequence: first spot the signs early, then diagnose fast, then choose honestly between rescuing and rebuilding, then reset the people and the governance, and finally make sure it sticks. No pointing fingers — a project doesn't get better from that. Instead, a level-headed route back to working software, made for a busy SME owner who has to keep the business running in the meantime. We think in terms of EU-hosted solutions with a human in the loop: technology you can trust, and people who take responsibility.
Why early intervention is the whole game
The first question every owner asks is: when do I step in? The honest answer: as soon as the warning signs start piling up, not only when the deadline has definitively been missed. By the time the end date falls through, you are usually already months too late.
It comes down to what we call decision latency: the time between “something isn't right” and “we're doing something about it.” Every week of doubt adds up. The costs accumulate, and perhaps most painfully: the share of reusable code declines the longer you keep building in a shaky direction. Waiting makes the eventual intervention not only more expensive, but also more drastic.
So apply a simple rule of thumb: two or more warning signs that persist for longer than two sprints are the trigger for a diagnosis. Not for panic, not for firing your team — for a diagnosis. That is cheap insurance. Research by McKinsey & Company together with the University of Oxford shows that the costs of large IT projects grow with their duration: every additional year pushes the overruns further up. Those figures concern large, often enterprise projects, but the lesson holds fully for SMEs: time is the enemy. Intervening early is cheaper than being proven right later.
The 7 warning signs of a stalling project
Below is a usable checklist. For each sign, one sentence explains what it really means.
One. The schedule keeps slipping. What it really means: not a single setback, but a pattern — the team no longer has a grip on the scope or the complexity.
Two. The scope grows without written agreements. What it really means: more and more is being promised in the hallway, and no one is keeping track of what “done” actually means anymore.
Three. The technical debt grows faster than the functionality. What it really means: more energy goes into patching up yesterday than into delivering the value of tomorrow.
Four. Key people leave. What it really means: with every departing developer, undocumented knowledge walks out the door — knowledge that exists in no one else's head.
Five. Communication becomes reactive and defensive. What it really means: updates are about explaining why something isn't finished, not about what does work.
Six. Demos keep showing the same features. What it really means: motion is being suggested, but there is no real progress under the hood.
Seven. There is no demonstrably working software you can click on yourself. What it really means: this is the most decisive sign — if after months you still can't touch it, it probably doesn't exist yet.
Take the self-test: how many of these seven do you recognize? With a single isolated sign, there is usually nothing wrong. But if you recognize two or more, and they persist for longer than two sprints, then it is no longer bad luck — then it is a pattern, and the moment for an honest diagnosis.
The diagnosis in 48 hours: what we really look at
A good diagnosis is tightly time-boxed. We do it in about 48 hours, and that is no accident: a diagnosis that itself grinds to a halt is part of the same problem. You don't need a six-week report to know that things aren't going well. You need an honest verdict before you spend another euro.
We look at four things. First, the code: how is it structured, are there tests, and is the knowledge documented or does it live only in people's heads? Code that no one dares to touch is a warning in its own right.
Second, the people. We speak with those involved separately — developers, project lead, and you as the client. Separately, because only then does the difference surface between the reported status and the actual status. That gap is often the real problem.
Third, the foundation: the architecture. Is this a house with a bad coat of paint, or is the crack in the foundation? That distinction will determine almost everything later.
Fourth, we estimate how much of the existing code is truly reusable. Not how much has been made, but how much of it is sound and stays usable.
The outcome is deliberately simple: one page with an honest verdict — proceed or not — plus a recovery plan with a price tag attached. No vagueness, no “let's look into it a bit more.” A diagnosis that doesn't cut the knot hasn't done its job.
Rescue or rebuild: why the rule of thumb is not a verdict
We apply a rule of thumb that provides a handhold: if less than roughly 30% of the code is reusable, it leans toward rebuilding; if more than roughly 50% is usable, it leans toward rescuing. Note the word leans. This rule is a starting signal, not a decision. It tells you where the conversation begins, not where it ends.
What weighs more heavily than the percentage is the architecture. Twenty percent of reusable code on a healthy foundation is often worth more than sixty percent on a rotten one. A poorly chosen foundation cannot be polished away with good modules on top of it.
Then there is the sunk-cost trap, the pitfall of sunk costs. “We've already put so much into it” is a feeling, not an argument. The money already spent you will never get back — whether you continue or stop. The only relevant question is what the cheapest path to working software is from here on out.
And don't underestimate the hidden costs of starting over. Joel Spolsky warned in his well-known essay “Things You Should Never Do” that when you rewrite from scratch you throw away something that is invisible but enormously valuable: years of built-in bug fixes and domain knowledge. Every odd “if” in old code is often a silent solution to a problem you would otherwise rediscover — damage and all.
Against that stands the modern, incremental view: don't keep everything, but don't throw everything away either. Between “rescue” and “rebuild” lies a third path, and most owners miss it.
The middle path most owners miss: replacing step by step
That third path is called the strangler pattern, named and described by Martin Fowler. The name comes from the strangler fig, a plant that slowly grows around a tree until it eventually replaces it. In plain business terms: you simply let the working parts keep running, rebuild the worst component first, and route traffic over to it piece by piece. Module by module the old system disappears, without there ever being a big “out with the old, on with the new” moment.
The big advantage: value lands continuously instead of after twelve months of silence. Every few weeks you see a genuinely improved component go live, and you can steer based on what works instead of based on a plan that is already months old.
This approach beats both a full rescue and a full rebuild when the foundation is largely sound but specific modules are rotten, and when you cannot shut down the business operations — which for SMEs is almost always the case. You simply cannot go for months without your systems. By replacing in small pieces, the risk and the budget stay manageable: if something goes wrong, it goes wrong in one module, not in the whole business.
Don't just reset the code, but the people too
This is the part that technical playbooks skip. A stalled project doesn't only have technical debt — it has a trust deficit that is just as real. The owner is disappointed, the team feels attacked, and everyone has become cautious about what they still dare to promise. Without repairing that, no technical intervention solves anything durably.
The reset begins with an honest acknowledgment without finger-pointing. Not “who did this,” but “here is where we stand, and this is the way forward.” Then you reset the expectations against a realistic new baseline — no more optimistic dates that fall through again anyway, but a baseline everyone can get behind.
There comes one accountable decision-maker. A stalled project often has too many helmsmen and too few captains; one person who cuts the knots keeps the latency low. And you, the owner, take an active place at the helm again. Not as a micromanager, but as an engaged client who guards the direction.
Finally, don't forget the sign of departed key people: capture the knowledge before more of it walks out the door. Get what lives in people's heads onto paper, into documentation and into shared agreements, so that the next departure doesn't cause a new standstill.
Governance that prevents relapse
A rescued project can grind to a halt again just as easily if you change nothing about how you steer it. You need governance — but tailored to an SME, not the heavy steering-committee structure of a multinational. Light, rhythmic and practical.
Start with a short, fixed steering rhythm with you present. A half-hour meeting every week or two weeks, in which progress is made demonstrable, is enough. It's not about the meeting, it's about the rhythm: regular visibility keeps everyone sharp.
Then redefine the scope down to a minimal MVP that trims the scope creep back to the core value. What is the smallest thing that truly delivers value? Build that first, and guard it firmly. Every wish beyond that goes on a list for later, not quietly into the sprint.
Keep the decision-making fast — low latency was the whole point and remains so. Build in QA gates so that bugs are fixed and not swept under the rug; a patched-over error always comes back. And put agreements about scope changes in writing, so that no one later remembers something different.
Finally, explicitly define what “recovered” means, so that you can recognize it: roughly four weeks or more of continuous, consistent delivery of what was agreed, every cycle demonstrably working software, and restored predictability and trust. Not an optimistic status report, but visible, clickable progress. Only then is a project truly back on the rails.
A worked example, at a high level
What does this look like in practice? Take our rescue at Andes Seguridad — at a high level, because the details belong to the client. The project showed the familiar signs: a path that kept staying “almost done,” while little that was demonstrably working ended up on the table.
We began with a quick, honest diagnosis: what works, what is unsound, and how much of the existing work is truly usable? On that basis we made a clear choice between rescuing and rebuilding — a decision grounded in the foundation and the reusable portion, not in what had already been spent.
Next, we brought the project step by step back to its original goals, with the right working agreements underneath: one accountable line, a realistic baseline and a rhythm that gave the owner a grip again. The sequence — spot the signs, diagnose, decide, reset, make it stick — was not theory but the actual route back. No miracle story, but a project that delivered again.
Conclusion: when you should bring in help
The decision sequence is easy to remember: spot the signs early, diagnose fast, decide honestly, reset both people and technology, and make it stick with light governance. The question you must keep asking yourself is never “is this perfect?” — but “are we still on course toward the original goal, and if not, when do we intervene?”
The honest answer to that “when” is almost always: earlier than you now think. Intervening early is cheaper than being proven right later.
Are two or more signs blinking at you at the same time, for longer than two sprints? Then a short, honest diagnosis is by far the cheapest next step. After that you'll know where you stand — and you can decide with figures instead of with gut feeling.