If you have already lived through a development project that failed, this page is for you.
A lot of the owners we meet have already paid for a system that never got used. They are not trying to find out whether we are good. They are trying to find out why this time would be different. Here is the answer, without the padding.
Three causes, and not one of them is technical.
-
Cause 01
A spec written without watching the real work
Someone asked the managers how the work gets done. They described the procedure. But on the floor, that procedure was quietly abandoned three years ago because it did not work — and nobody wrote that down anywhere. So the delivered system automates a process that no longer exists. It matches the document and it is useless in practice.
-
Cause 02
Hourly billing
It moves the entire risk onto you. An overrun becomes an extra invoice instead of a supplier’s problem, and the supplier has no reason to finish quickly. This is not about dishonesty — it is about incentives.
-
Cause 03
Three people between you and whoever writes the code
You explain it to the account manager, who writes it up for the project manager, who breaks it down for a team that has never set foot in your warehouse. Every handoff drops a detail — and the details are exactly what decides whether a management tool gets used or ignored.
A bad incentive wins in the end.
One answer per cause, and nothing more complicated than that.
-
01 — Understand
We go and watch the work happen
Before writing anything, we spend time where the work gets done, with the people doing it. We write down the workarounds instead of correcting them: they are what reveal where the official process breaks. It is the step others bill the least for.
-
02 — Scope
A fixed price, and a list of what we will not build
The scope is written in both directions. What is in, what is out, and why. The price is fixed: if we estimated badly, that is our problem. You know the cost before anything starts.
-
03 — Build
Something usable every week
Not a mockup, not a status report: a part of the system that runs, that you can open and try. A wrong direction surfaces in seven days instead of at final delivery.
-
04 — Stay
The same person, after delivery
Your operations change and your tool has to follow. There is no handoff to a support desk that has never seen the file: the person who built it is the person who answers.
What a supplier turns down tells you more than what they promise.
-
→
We don’t bill by the hour. The estimating risk is ours, not yours.
-
→
We don’t build what already exists. If something off the shelf does the job for a third of the price, we will say so — even when it costs us the work.
-
→
We don’t hold your system hostage. The code, the data and the access are yours. You can move to another supplier without rebuilding anything.
-
→
We don’t take on work in a trade we don’t understand. A system built on a rough understanding costs more than a polite no.
The first conversation costs nothing.
Describe your situation in a few lines. We answer with a first read of the problem — including, where it applies, that this one isn’t for us.