Somebody who builds custom software telling you when not to buy custom software is an odd read, so here is the reasoning: the projects that go badly are almost always the ones that should never have started, and they are identifiable in advance.
Off-the-shelf already does it
The most common case, and the most expensive to get wrong.
If your requirement is broadly what other businesses in your sector need, someone has already built it, sold it to hundreds of companies, and spent years fixing the problems you have not encountered yet. That accumulated refinement is worth more than anything a fresh build gives you.
The usual objection is that the product does not quite fit. Worth testing honestly: is the misfit because your process is genuinely different, or because it is merely familiar? Adapting how you work to fit good software is frequently cheaper than building software to fit how you happen to work.
Custom earns its place where the process is genuinely yours and part of why customers choose you. Not where it is simply what you are used to.
Nobody can describe what it should do
If three people describe the process three different ways and each is confident theirs is correct, that is not a software requirement. It is a disagreement, and building will not settle it.
What happens instead is that the build encodes one person’s version, the others find it wrong, and changes get requested until the budget is gone and nobody is satisfied.
The process has to be agreed before it can be automated. That is organisational work, it is often uncomfortable, and no amount of technology substitutes for it.
The pain is real but rare
Something takes half a day and everybody hates it. Genuinely awful. It happens twice a year.
Custom software has a build cost and then a permanent maintenance cost: it needs updating, it breaks when something it connects to changes, and it needs an owner. Set that ongoing cost against one day a year and the arithmetic answers itself.
Frequency matters far more than intensity. A mildly irritating task done forty times a week is a much better candidate than an agonising one done twice a year.
There is no owner
Software is not a purchase, it is a commitment. Something has to be maintained, updated, and adjusted as the business changes.
If nobody internally will own it, it decays. Two years on it is running an old version, nobody remembers how it works, and the person who understood it has left. That is worse than the spreadsheet it replaced, because at least everyone understood the spreadsheet.
The owner does not need technical skill. They need to be the person who notices when it stops fitting and has authority to get it changed.
It is being bought to fix a people problem
Sometimes the stated problem is that information is not being recorded, or work is not being handed over properly, or nobody knows what state things are in.
Occasionally that is a tooling gap. Frequently it is that the process was never agreed, or nobody has time, or a role is unclear. A system built on top of that produces the same problem with better reporting on it.
Worth asking directly: if everyone did exactly what they are meant to do, using what exists today, would the problem persist? A no is a signal to fix the process first.
When it is genuinely right
To be fair to the other side, the conditions are specific and recognisable.
- The process is genuinely particular to your business and part of why people choose you.
- It happens often enough that time saved is real money.
- Everyone agrees on what it should do.
- Someone will own it.
- You have tried the cheap options and hit a real wall, not an inconvenience.
The last one matters most. Businesses that have pushed a spreadsheet as far as it goes make excellent clients, because they know exactly what they need and why the alternatives failed.
If you do proceed, settle the running cost before the build cost. What a tool is allowed to connect to decides the per-person fee, and that decision is made early by someone who may not realise they are pricing it.
The honest summary
Most businesses asking about a custom app need a configured off-the-shelf product, a tidier version of what they have, or an agreement about how the process actually works.
A smaller number genuinely need something built, and for those it is transformative.
Telling the two apart takes one conversation, not a proposal. If you are weighing this up, describe the process and how often it happens, and you will get an honest answer including when that answer is that you do not need this.
Common questions
How do I know if we actually need custom software?
Five conditions: the process is genuinely yours, it happens often enough that time saved is real money, everyone agrees what it should do, someone will own it, and you have hit a real wall rather than an inconvenience.
Is off-the-shelf always cheaper?
Not always cheaper, but usually better value, because you are buying years of refinement for problems you have not encountered yet. Adapting how you work to fit good software is frequently cheaper than the reverse.
What if three people describe the process differently?
Then it is not a software requirement, it is a disagreement. Building encodes one person’s version and the others find it wrong. The process has to be agreed before it can be automated.