Why most custom software projects fail
and the three questions we ask before taking any project
Most custom software projects fail not because of bad engineering. They fail because of bad scoping.
We have seen it repeatedly. A business spends heavily on a custom platform, and six months later the team has gone back to a spreadsheet and a chat group. The software exists. Nobody uses it.
Here are the three questions we ask before we agree to take a project.
Question 1: Who specifically will use this, and what are they doing today?
Not “the sales team”. Not “our operations”. A specific person: our sales manager currently spends three hours a day copying data from a chat thread into a spreadsheet to track leads.
If you can describe the person and the manual process being replaced, we can build software that helps them. If you cannot, we are probably going to build something that demonstrates well and collects dust in production.
The goal is never digital transformation. The goal is turning that person’s three hours into twenty minutes.
Question 2: What does success look like in 90 days, in one sentence?
Not a list of features. One measurable sentence.
- Every lead gets a response within five minutes instead of four hours.
- The operations team processes 200 orders a day instead of 80.
- The clinic has zero double bookings.
If a client cannot answer this, we help them work it out before anything starts. Without a clear success measure the scope expands indefinitely and nobody ever agrees that it is finished.
Question 3: Who maintains this after we build it?
This one kills more projects than anything else.
Custom software is not a one-time purchase. It is a system that needs updates, fixes and new work as the business changes. If there is no plan for who maintains it — an internal team, a retainer with us, or another supplier — it will slowly break and eventually be abandoned.
We would rather have that conversation before a project starts than eight months in, when the client is frustrated and we are making emergency fixes.
Why we turn projects down
We turn projects down regularly. Usually the answers to these three questions show that the client is not ready to build software yet, and needs to fix a process problem first.
That is not a criticism. Software cannot fix a broken process. It automates the chaos and makes it go wrong faster.
The best projects we have worked on started with a client who knew exactly what pain they were solving, who would use the result, and how they would know it was working.