We build software for a living, so what follows runs against our own immediate interest. We are writing it anyway, because the project that should never have existed costs everyone more than the one that was never sold.
A meaningful share of the conversations we have end with the answer not being a tool. Not because the problem is not real, but because the problem sits somewhere else and software will amplify it rather than solve it.
These are the four patterns we see most, and how to tell them apart from the case where building genuinely is the answer.
The tool that was bought and nobody uses
The pattern is recognisable. A year ago a system was bought, implementation was paid for, there was a training session. Today one person uses it halfway and everyone else went back to spreadsheets.
The easy reading is that the tool was bad. It almost never was. What usually happened is one of two things: the tool required the team to work differently and nobody supported that change, or it solved a problem that hurt management rather than the people who had to use it every day.
How to tell if this is you. Ask why it stopped being used, but not the person who bought it: the person who used it. If the answer is "it is faster by hand", the tool was not the problem.
Buying a second tool here is repeating the experiment and expecting a different result.
The process that fails for lack of an owner
This is the most common and the one that looks least like a software problem.
Something always stalls at the same point. Quotes take too long, complaints go unanswered, the close does not come out on time. A system gets requested to "track it".
But if nobody is accountable for it moving, a system will not make it move. It will record in greater detail that it did not move. You will have a precise dashboard showing what you already knew, and now the dashboard needs maintaining too.
How to tell if this is you. Ask who answers if it does not happen this week. If the answer is a department rather than a person, or if it is three people, the problem is accountability rather than tooling.
That gets fixed with a decision, and the decision is free.
Three tools doing the same thing
A scheduling system, a group chat where people also schedule, and a notebook. A form, a shared sheet and an email thread. Nobody decided it would be this way: each piece arrived for a good reason, at a different moment, to solve something specific.
The cost is not the subscriptions. It is that each tool holds part of the truth and the real operation lives in the head of whoever reconciles them.
How to tell if this is you. Count how many different places could hold the answer to "where did this end up?". If it is more than two, it already is.
And the way out is usually not building. It is choosing which system is the record of truth, stating what role each other thing plays, and switching off what is left. It is an uncomfortable decision because somebody loses their favourite tool, and it is cheaper than any development.
Automating something that is broken
The most expensive of the four, because it costs real money before anyone notices.
A process with unnecessary steps, approvals that approve nothing and data requested twice does not improve by being automated. It becomes faster, harder to change, and depended on by more people. What used to be corrected by talking to somebody now requires modifying a system.
How to tell if this is you. Draw the current process on one page, step by step, and for each one ask what it is for. If there are steps whose only answer is "we have always done it this way", those do not get automated. They get removed first.
Automation should come after simplification, not instead of it.
What actually fixes these four
None of the four needs code. They need things that sound less interesting and work better.
An owner per process, with a name, not a department. An agreed place where each kind of information lives. A short, regular ritual where pending decisions get made, which is half of what methods like Scrum or Kanban genuinely contribute when applied without ceremony. And the process written on one page, which is where the redundant steps become visible.
That is weeks of work rather than months, and it carries no maintenance cost. When the problem is one of the four above, it is also the only thing that works.
If you are not sure whether your case is process or system, that distinction is exactly what a thirty minute call can settle, and it is one of the conversations we most enjoy having.
And the break point
Now the other half, because this article would be dishonest without it.
There is a moment when the process is healthy and the system genuinely is the constraint. You recognise it like this: the process is clear and written down, there is an owner, everyone follows it, and the team still spends hours doing by hand something purely mechanical. Nobody is arguing about how it is done; the problem is what it costs to do.
At that point building pays for itself, and the concrete signals that you have arrived are in six signs manual work is already costing you.
The difference between the two cases is one question: if you had the perfect system tomorrow, would your problem disappear? If the answer is yes, build. If the answer is "somebody would still have to decide", the system was not the problem.
How we work with this
When the diagnosis is process, we say so and do not sell a build. What we do offer there is support on the methodology side, and training for teams, which is on talks and workshops. Everything we do is on services, and how we structure a project when building genuinely is the answer is in from discovery to delivery.
The discovery call runs thirty minutes, it is free and carries no obligation. Its job is exactly to tell these two cases apart, and telling you not to build is as valid an outcome as the other one. You can book it here.
Does this apply at your company?
30 minutes, no obligation, to review your case and decide whether there's anything to build.