Custom software or off-the-shelf: how to actually decide

The usual way this decision gets made is backwards. A business feels held back by its software, someone suggests building something custom, and the conversation becomes about cost and timeline before anyone has established whether custom is the right category of answer.

There is a better order, and it starts with a question that has nothing to do with software.

Start with: is this how you actually compete?

The useful distinction is not between custom and off-the-shelf. It is between the parts of your business that are the same as everyone else's and the parts that are specifically yours.

Payroll is the same as everyone else's. So is accounting, email, and storing files. Nobody wins customers by having unusual payroll. Buy these. Buying is cheaper, faster, better supported, and someone else handles the compliance changes.

But most businesses have one or two things they do differently, and that difference is why customers choose them. A property business with an unusual viewing-to-offer process. A wholesaler whose pricing depends on relationships that no standard system models. A hotel whose operations are shaped around a building that does not fit the template.

That is where custom software earns its place — not because off-the-shelf cannot do it, but because making off-the-shelf do it means either distorting the product with configuration until it is fragile, or distorting your business to fit the software.

So the first question is: is the thing you are trying to support how you actually compete, or is it just admin you are tired of?

If it is admin, buy something. If it is how you compete, custom deserves consideration.

The honest case for off-the-shelf

It is the right answer most of the time, and it is worth being clear-eyed about why.

Somebody else pays for maintenance. Security patches, browser changes, API deprecations, tax rule updates. This is a permanent cost that custom software transfers to you, and it is the one businesses consistently underestimate.

It works on day one. No build period, no discovery, no delay.

It has been tested by thousands of businesses. Your edge cases have probably been hit by someone else already.

Integrations already exist. Popular tools connect to each other. A custom system connects to nothing until you build each connection.

You can leave. A subscription you cancel is a smaller commitment than a system you own and must now maintain or replace.

Its limits are known upfront. You can evaluate it against your process before spending anything, which is not true of something that does not exist yet.

If a product does eighty percent of what you need and the missing twenty percent is not how you compete, the right answer is usually to buy it and adapt.

The honest case for custom

Your process does not fit, and changing the process would cost you something real. Not "it is different", but "the difference is why customers choose us".

You are paying for configuration that behaves like software anyway. Businesses often end up with a standard product bent into shape with dozens of custom fields, automations and workarounds that only one person understands. That is custom software with worse tooling, no version control, and no tests.

You need several systems to act as one. Sometimes the product is not an application but the connective tissue: one workspace over things that already exist.

The per-seat cost has outgrown the build cost. At a certain headcount, subscriptions become large enough that the arithmetic changes. Do the arithmetic honestly, including ongoing maintenance, before using this as the reason.

You need to own the data or the deployment, for genuine regulatory or contractual reasons rather than a general preference.

The option people skip

There is a third answer, and it is frequently the best one: buy the platform, build the part that is yours.

Keep the standard product for the standard work — accounting, storage, email, payments. Build a focused application for the specific workflow that is genuinely different, and connect it.

You get supported infrastructure for the parts everyone needs, and a fitted tool for the part that matters. The custom piece stays small, which means it stays affordable to maintain.

Most of the projects we build are this shape. Not a system to replace everything — a specific application for a specific workflow, connected to what the business already runs. A booking and client platform alongside the existing accounting. A room management app alongside the property management system.

The costs nobody puts in the comparison

When businesses compare, they compare subscription cost to build cost. Both sides of that comparison are incomplete.

Off-the-shelf also costs:

• Configuration and setup, often with a consultant.
• Training, and retraining when they redesign the interface.
• Integration work to connect it to your other tools.
• Data migration, in and eventually out.
• The workarounds your team invents for what it cannot do — which is a real, recurring cost that never appears on an invoice.
• Price rises, which you do not control.

Custom also costs, after launch:

• Hosting and third-party services.
• Maintenance: dependency updates, security patches, breaking changes in APIs you depend on.
• Changes as the business changes. This is the big one and it is permanent.
• Someone to call when it breaks.
• Documentation, so it is not one person's private knowledge.

That maintenance line is where custom software projects disappoint. The build is a known number. The next five years are not, and a system with no maintenance arrangement degrades until it is replaced — usually with an off-the-shelf product, at which point you have paid for both.

If you cannot answer "who maintains this in two years?", you are not ready to commission custom software. That is the single most reliable predictor of how these projects end.

A decision sequence that works

1. Write down the process. The real one, with its exceptions. You need this regardless of the answer, and it frequently resolves the question by itself.
2. Separate "how we compete" from "admin we dislike". Be honest; most of it is the second.
3. Evaluate two or three products against the real process. Not a demo — your actual steps, including the awkward ones.
4. Count the gaps, and ask what each one costs. Not "does it do X", but "what happens if it does not". Some gaps are irritations. Some are why you are losing.
5. Consider the hybrid. Can you buy the platform and build only the gap?
6. Price both properly, over three years, including everything above.
7. Decide who maintains whatever you choose, before you commit.

Most businesses that do this land on "buy, with one small custom piece", which is a good place to land and considerably cheaper than where they started.

Signals you are about to make the expensive mistake

Building because evaluating was tedious. Custom looks appealing when you have sat through four demos. It is not less work; it is different work, spread over years.

Building to avoid a subscription, without counting maintenance. The subscription is often cheaper than owning it.

Buying and then bending it beyond recognition. If you are twenty custom fields and nine automations deep, you have built software in a tool not designed for it.

Rebuilding what exists because it is not perfect. Eighty percent, today, supported, usually beats a hundred percent in nine months.

Deciding without writing the process down. This is the one that predicts failure best, whichever answer you pick.

If you go custom

Start smaller than feels right. One workflow, the one that hurts most. Get it in use, learn from how people actually work with it, then extend. The features you would have specified up front are frequently not the ones people need, and finding that out on a small build is much cheaper than on a large one.

We have built platforms for property, hospitality and wholesale businesses this way — starting with the workflow that was genuinely theirs, and connecting to what already existed rather than replacing it.

If you are weighing this up, bring the written-down process to a free consultation. If the honest answer is that a product on the market already does it, we will tell you which category to look in.