Why Software Projects Fail Six Months After Launch
The launch went fine. The problems start when the people who made the decisions are gone and nobody wrote down why.
Ask people about failed software projects and they describe launches: missed deadlines, budget overruns, a release that fell over on day one.
Those happen, and they are visible enough that everyone plans for them. The more common failure is quieter. The project launches, works, and then slowly becomes impossible to change.
The decision archaeology problem
Every codebase is a record of decisions. Why this database rather than that one. Why this odd exception for one customer. Why a function that looks redundant is load bearing.
While the original team is present, that knowledge lives in their heads and the system stays cheap to modify. When they leave, the code remains but the reasoning does not.
What follows is predictable. A new developer sees something that looks wrong, changes it, and breaks a case nobody remembered. After that happens twice, the team stops touching anything they do not fully understand. They add code alongside the old code instead of changing it.
That is the moment a project starts dying, and it usually happens without anyone raising an alarm.
Why documentation does not fix it
The standard answer is "write documentation", and it mostly does not work, because the documentation people write describes what the system does. You can get that from the code.
What disappears is why. Why this approach was chosen over the two alternatives that were considered. What constraint existed at the time. What was tried and abandoned.
A short note capturing a decision and its reasoning is worth more than fifty pages describing endpoints. It also takes about ten minutes to write, at the moment the decision is made, and is nearly impossible to reconstruct a year later.
The compounding cost
The expensive part is not any single unclear decision. It is the compounding.
Each thing nobody understands makes the next change slightly more cautious. Cautious changes take longer. Longer changes mean fewer of them fit in a quarter. Fewer changes mean the system drifts further from what the business now needs.
Eventually someone proposes a rewrite, which is expensive, risky, and tends to reproduce the same situation three years later, because the underlying habit has not changed.
What actually helps
Write down decisions, not descriptions. A dated note per significant decision: what we chose, what we rejected, why. Kept in the repository, next to the code.
Make sure two people understand every critical area. Not through documentation. Through one of them actually working on it.
Treat the local setup as a feature. If a new developer cannot get the project running quickly, you pay that cost at every handover, forever.
Budget for maintenance explicitly. A system that gets zero engineering attention between features is accumulating a debt that will be paid later, at a worse exchange rate.
The uncomfortable version
Most of this is not a technical problem. It is a question of whether the people building the system expect to be around to live with it.
Teams that expect to maintain what they build make different decisions than teams that expect to hand it over and leave. You can usually see which kind you hired within about three months, and the difference shows up in the budget about a year later.
Writing for the version of the business that exists in two years, rather than for the demo, is the difference we try to hold to in software development. Where a system has already drifted past the point of safe change, modernising it and keeping it under managed IT is usually cheaper than the rewrite that gets proposed instead.