I am going to tell the story of the worst project I took on, unvarnished, because the lessons it left me are the ones that protect my clients today. It was not about the code. It was about everything I failed to say no to in time.
How it started (and the signs I ignored)
The client arrived in a hurry, with a fixed budget in mind that did not match what they were asking for, and the phrase that should have been an alarm: "it is very simple, just a little thing". I took it because I needed the work and because I convinced myself I could sort it out as I went. The first lesson is that it is almost never a little thing, and that when the scope is unclear and the deadline is already fixed, the one who loses is always the one who builds.
There were more signs. There was not a single person who could decide; every week the criteria changed depending on who I spoke to. And the project depended on an old system nobody had documentation for. Each of those signs, on its own, is manageable. Together, they are a storm.
What went wrong
I massaged the estimate to fit the client's budget instead of telling them the truth: that with that scope and that deadline it did not add up. Halfway through, the real cost ate the margin and part of my personal time. I delivered something that half worked, the client was rightly unhappy, and I learned the most expensive lesson of my career: a sale closed by breaking your honesty about scope is not a sale, it is a debt.
What I changed for good
Since then, a fixed price agreed before starting, and if I get the estimate wrong, the loss is mine, not the client's. That forces me to scope properly before giving a number, which is exactly what protects the client. If a project does not fit, I say so before charging anything. And if I am not clear on the state of a legacy system, I propose a 190 € technical audit before committing a whole project blind.
I also learned to say no. Not to every project, but to the ones with the signs that one had: fuzzy scope with a fixed deadline, no single decision-maker, and dependencies nobody controls. Saying no in time is the most honest way to look after both the client and your own work.
What you should take from this if you are hiring
If you are about to hire software, be wary of anyone who gives you a number without having understood your problem, and even more wary of anyone who accepts your deadline and budget without qualifying anything. The provider who tells you "this does not fit that budget, but this does" is looking after you. The one who says yes to everything is selling you a debt. See also our guide on how to choose a software development company.
Frequently asked questions
Why tell the story of a project that went wrong?
Because the lessons from a failed project protect a client better than any sales pitch. Being honest about your own mistakes is part of how we work.
What matters most for a project not to fail?
Scoping before fixing price and deadline, having a decision-maker, and knowing the real state of the systems the project depends on. When those three things are clear, almost everything else is manageable.
How do you avoid this kind of project?
With a fixed price agreed before starting (if we get it wrong, the loss is ours), saying no when a project does not fit, and proposing a prior technical audit when there are undocumented legacy systems.
