Why software projects go off the rails, and how to prevent it
An application project meant to take three months takes twelve, and the team won't use it. The five causes that keep coming back, and the safeguards to set before you sign.
By Jérôme Knops
Published September 29, 2026 · 5 min read
The project was supposed to take three months. A year later, the application still isn't live, the bill has doubled, and the team is still working in the spreadsheet. If this has happened to you, you are not alone, and it probably wasn't a question of technical skill.
Software projects go off the rails for the same few reasons, almost every time. You can spot them before you sign, as long as you know what to look for.
Cause 1: describing everything before seeing anything
The instinct makes sense: you want to control the budget, so you write everything down in advance. Three months of specifications, a hundred pages, every screen described. Then the provider builds exactly what was written.
The trouble is that nobody can describe a tool they have never used. At delivery, the site manager finds that the screen asks for six fields where he fills in two on site. Every fix becomes a change order.
The safeguard: describe the first problem to solve and the people who will use the tool, not the whole application. The rest becomes clear once the first part is running.
Cause 2: a first version that comes too late
The longer you wait to show something, the more gaps pile up unseen. If nothing is running after four months, you can't judge progress: you are judging a schedule, not a tool.
The safeguard: require a working version on a real case within the first few weeks. With us, a first version goes live in four to six weeks on an initial scope. The exact figure matters less than having a real user on it early.
Cause 3: building for the office, not the field
Many projects are defined by management and the back office. Screens are designed at a desk, with time to spare. Then the crew lead has to use them standing up, on a phone, between two deliveries. He goes back to texts and paper, and the application stays empty.
The safeguard: make sure the provider spends time with the people who enter the data, not only with those who read the figures. A field screen gets tested in the field.
Cause 4: a quote that doesn't say what it leaves out
Two quotes for the same amount can describe two very different projects. The number of roles, approval paths and systems to connect moves the price far more than the number of screens. When these points aren't written down, they come back mid-project as extras.
The safeguard: get it in writing what is included, what isn't, and what a change costs after go-live. We break down what moves the budget in our article on the price of a business application.
Cause 5: no view of the work in progress
The owner receives progress reports, not the tool. He doesn't know how many people are really working on his project, or where the code stands. It is often the first question we get, and a fair one.
I don't know how many of you are behind this, or how long it's going to take.
The safeguard: access to the code from day one, a repository in your name, and a live version you can open whenever you like. The legal side is explained in our article on who owns the code.
The checklist to fill in before you sign
Ask these questions of any provider, us included. A vague answer to any of them is a warning sign.
| Question | Reassuring answer | Answer that should worry you |
|---|---|---|
| When will I see a first working version? | A date in weeks, on a specific case | "At the end of the project" |
| Who on our side will you meet? | The people who will enter data, in the field | Management only |
| What isn't in the quote? | A written list | "We'll see as we go" |
| Who owns the code, and when do I get access? | You, from the start | At delivery, or no answer |
| What does a change cost after go-live? | A known way of pricing it | A quote each time, with no benchmark |
What changes with an application built block by block
Instead of one big project delivered all at once, the application is built in blocks, starting with the one that pays off most. For a renovation contractor, that is often quote tracking. For a distributor, goods receiving.
In practice:
- the first block is live while the next one is being prepared, and it is already useful;
- feedback from the team comes from a tool they use, not from a document;
- each block replaces an existing tool, a spreadsheet or a messaging group, instead of adding to it;
- you can see the application and the code at any time, without waiting for a report.
You can see an example of this approach in our demo for a renovation contractor, and the process is described on the your application page.
Software projects off the rails: the key takeaways
A project rarely goes wrong because of the code. It goes wrong because everything was described too early, shown too late, designed for the office, left vague in the quote, or run without the client seeing anything.
Each of these causes has a simple safeguard you can set before signing. If a project has already gone wrong for you, start by recovering the code and the access rights, then bring the scope down to a single block that runs.
Frequently asked questions
Why do custom software projects run late?
Most often because the whole scope was written down up front, on paper, and the real questions only surface when the team sees the tool. The later that moment comes, the more each correction costs.
How can you tell early that a software project is going off track?
Ask to see a working version on a real case within the first few weeks, and get access to the code during the project. If nothing is running after two months, you have no way to judge progress.
Do you need a full specification before starting?
You need a clear description of the first problem to solve and of who will use the tool. A hundred-page document describing everything in advance locks in choices made before anyone has touched the software, and that is often where the drift begins.
What should I do if my current project has already gone wrong?
First recover the code and the access rights, then cut the scope down to the part that pays off most and put it into service. One small block that runs beats a large project waiting to be finished.
Founder and CTO of Edenio
Jérôme Knops is the founder of Edenio, where he designs and builds custom business applications for construction, supply chain and distribution companies. He runs the scoping meetings, writes the code, and stays the person you talk to once the tool is in production.
See all their articles
Jérôme Knops
