When a business actually needs custom software

Custom software is not a better version of off-the-shelf software. It is a different trade, and the thing you trade away is ongoing cost and responsibility. Every custom system has to be maintained, understood and eventually changed by someone. A subscription product carries that burden for you, and its price includes it.

So the question is never "is custom better?" It is whether the fit you gain is worth the ownership you take on.

The signals that genuinely justify it

Your process is your advantage. If the way you quote, schedule or fulfil is genuinely different from everyone else in your category, and that difference is why customers choose you, then standard software will file the difference down. It is built around the average of your industry and you are trying not to be the average.

You are paying people to be glue. Someone exports from one system, reformats it, and imports it into another — the clearest candidate for automation there is. Someone retypes the same order into three places. That work is invisible in the accounts because it shows up as salary rather than software, but it is a recurring cost with no ceiling.

The integration you need does not exist. You have chosen good tools and they will not talk to each other in the way your business requires. Sometimes the honest answer is a small piece of software whose only job is to sit between them.

You are paying per seat for a fraction you use. Ten users on a platform where you use four of its forty features is a common and expensive shape, and it gets worse as you grow.

The signals that mislead

"The software does not work the way we do." Sometimes that is a real mismatch. Often it means the tool encodes a more sensible process than the one you have, and the honest fix is to change the process. This is worth genuinely testing before you build, because building around a bad process makes it permanent.

"We want it to look like us." Branding is not a reason to rebuild functionality. It is a reason to configure, or to put a thin layer in front of something that already works.

"It will be cheaper than the subscription." Compare honestly. The build is the smaller number. Hosting, maintenance, the change you will want in six months, and the risk that the person who built it is unavailable — those are the real figure. A subscription is expensive precisely because it includes all of that.

Build when the fit is the point. Buy when the function is the point.

The shape that usually works

Most businesses do not need a custom system. They need a small custom piece connected to standard ones.

Buy the accounting. Buy the email. Buy the storage. Build the one thing that is genuinely yours — the quoting logic, the scheduling rules, the operational view nobody sells because nobody else needs it. Then connect them.

This keeps the surface you own small, which is what makes it affordable to maintain. The failure mode of custom software is not that it does not work. It is that it grows until nobody wants to touch it.

Questions worth answering before you commit

What happens to this system if the person who built it is unavailable for six months? If the answer is uncomfortable, the design is wrong regardless of how well it works today.

What does it cost to change? Not to build — to change. You will want a different field, a new rule, another report. If each of those is a project, the system will quietly stop reflecting the business.

What is the smallest version that would be genuinely useful? Not a demo. The smallest thing people would actually use every day. If that cannot be described in a paragraph, the problem is not understood well enough to build for yet.

What are you replacing? If the answer is "nothing, this is additional", be careful. Systems that sit alongside the existing way of working tend to get abandoned, because the old way still functions.

The order that keeps it small

Write down how the work is done now, honestly, including the parts that are embarrassing — the spreadsheets included. Find the step where information gets retyped, delayed or lost. Ask whether a standard tool already solves that step. If it does, use it. If it genuinely does not, build only that step and connect it to what you already have.

That sequence produces small systems that survive. The alternative — deciding to build a platform and then working out what goes in it — produces the large ones that get replaced in three years.