Failed software projects look like progress for a long time. The patterns behind them repeat, and you can spot them earlier than most people think.
A failed software project rarely looks like a crash. For a long time it looks like progress: meetings take place, concepts get thicker, the budget keeps running. There is just no software anyone can use.
Officially, a project only fails when it gets cancelled. In reality, it often failed months earlier. The decisions that tip it over are made at the start, not at the end.
We build software for cases where mistakes have real consequences. The patterns that tip projects over repeat with surprising reliability. Here are three of them, plus the early warning signs and what honestly helps.
Pattern 1: Nobody decided what the first version has to do
Unclear scope is the most common cause. Not because nobody thought about it. But because everyone wants everything at once and nobody decides what comes first.
A hundred-page concept doesn’t solve that. It just moves the decisions into a document nobody reads. Clarity doesn’t come from paper. It comes from a working version you can click.
The same goes for a fixed price on unknown scope. It feels safe, but it’s the illusion of safety: someone pays the difference between assumption and reality. Usually through cuts in exactly the places you cannot see.
Pattern 2: The prototype that is suddenly supposed to be a system
With AI, a prototype that looks like the finished product now takes days. That is real progress, and building something in-house is a good instinct.
But for processes where mistakes matter, a prompted tool isn’t a system yet. Real software engineering answers questions a prompted tool never asks:
Projects fail at this point when the prototype is expected to skip these questions. The difference isn’t AI versus no AI. The difference is the engineering behind it: architecture, security, tests, operations.
- Which technology is right for your project, and will it still hold up in three years?
- How do you make sure data is only seen by the people who are allowed to see it?
- How do you know the system does the right thing in edge cases too?
- When something breaks at 3 a.m.: does anyone notice, and do you know why?
Pattern 3: Architecture that only thinks as far as go-live
Launch isn’t the goal. It’s the start of the expensive part. A technology choice that only thinks as far as go-live becomes a mortgage afterwards: every extension gets more expensive, every integration becomes a risk.
The most critical spots are the seams: ERP, identity, legacy APIs, existing systems. Projects die at these integrations more often than at the software itself.
The most expensive version is the complete rebuild in one go. Big rewrites fail because grown systems contain rules and edge cases that live in no documentation, only in the code. A big bang throws that knowledge away and rebuilds it at a high price.
How to spot it early
No project announces its failure. But it sends signals, usually within the first weeks:
Every single signal is fixable. It gets dangerous when several come together and nobody says them out loud.
- There are documents and slides, but after weeks nothing that runs in a browser.
- Nobody can say in one sentence what the first version has to do.
- The fixed price was set before anyone understood the scope.
- Tests, monitoring and operations get postponed until “after the launch”.
- Your internal IT isn’t at the table.
What honestly helps
Build early instead of conceptualizing for months. A small slice that lives in a browser within a few weeks answers more questions than any concept. You see early whether the direction is right, and you can correct while it is still cheap.
Work with the internal IT, not around it. It knows the company, the systems and the edge cases. An external team adds speed and delivery power. Working against each other, you lose both.
Ask the uncomfortable questions first: What happens under load? Who sees which data? Who notices when something fails? A team that asks these questions on its own is a good sign. One that postpones them is the clearest early warning sign there is.
Software projects rarely fail because of a single wrong decision. They fail because for too long nobody asks whether the thing actually holds up. That question costs nothing. Asking it early is the cheapest part of the whole project.
N° 06 Contact
Tell me what you’re planning.
No form, no ticket system. Email me directly and you get me, not an inbox someone else manages.
Moritz Miedler · Founder, replies personally