Custom Software or Off-the-Shelf? How to Decide

Here is an unusual thing for a software firm to say: most of the time, you should buy software, not build it.

Off-the-shelf tools are cheaper to start with, someone else maintains them, and the common problems, like invoicing, scheduling, CRM, and payroll, have been solved thousands of times by companies with far bigger teams than any custom project will ever have. If a tool does ninety percent of what you need, the last ten percent is usually cheaper to change in your process than in code.

But "usually" is doing real work in that sentence. There are cases where off-the-shelf stops fitting, and the cost of the mismatch quietly grows past the cost of building. This is how to tell which situation you are in.

Start by Assuming You Should Buy

Before talking to anyone about building, make an honest attempt to buy:

• List the three to five things the software absolutely has to do
• Trial the two or three leading tools against that list, with your real data rather than the demo data
• Ask the vendors directly about the gaps. Sometimes there is a setting, an add-on, or a workaround you did not know about
• Price each one over three years, including per-user fees as you grow

If one of them clears the list, buy it. Configure it well, train people on it, and move on. That is a good outcome, not a consolation prize.

Five Signs Off-the-Shelf Has Stopped Fitting

Building starts to make sense when you see some of these:

• The workarounds have their own workarounds. People export to a spreadsheet, fix things by hand, and paste them back, every day
• Your process is the product. The way you quote, schedule, or fulfil orders is a genuine advantage, and every tool forces you into the generic version
• You are paying for five tools to do one job, and most of the work is moving data between them
• Per-seat pricing is punishing growth. The cost scales with headcount while the value does not
• The data you need is trapped. The tool will not let you get at your own records in a form you can use

One of these on its own is usually a configuration or integration problem. Three or more, sustained over months, is when building deserves a real look.

The Middle Ground: Buy the Core, Build the Glue

The choice is rarely all or nothing. For many small businesses, the most cost-effective answer is to buy the standard parts and build only what connects them, or what sits on top of them.

That might be an integration that moves orders from your online store into your accounting system without anyone retyping them. It might be a small internal tool that gives your team one screen instead of four browser tabs. It might be a nightly job that cleans and combines data from three systems into one report people actually trust. Or it might be a simple customer portal that shows order status straight from the systems you already run, so your team stops answering the same email all day.

Glue is smaller than a full build, so it is faster and cheaper, and it leaves the heavy lifting, like security, billing, and compliance, to vendors who do it at scale. If most of your pain lives in the gaps between tools, start there. We wrote a whole post on connecting your CRM, ERP and accounting tools.

What Custom Software Really Costs to Own

The build is the visible cost. Owning it is the rest:

• Hosting and services: servers, databases, email delivery, and monitoring. Often modest, never zero
• Maintenance: security updates, dependency upgrades, and fixes as the systems around it change
• Changes: your business will keep changing, and the software will need to follow it
• Knowledge: someone has to understand how it works. If that is one person who might leave, that is a risk in its own right

Expect the yearly cost of keeping custom software healthy to be a meaningful share of what it cost to build, not a rounding error. Custom software is closer to owning equipment than to buying a product. It is worth it when it earns its keep, and a burden when it does not.

A Build-vs-Buy Scorecard

Score each row for your own situation. If most of your answers land in the right-hand column, building deserves serious consideration.

The last row is a tie-breaker. If nobody can be named to own a custom system, keep buying until somebody can.

When the Answer Is "Not Yet"

Sometimes the honest answer is neither buy nor build, but not yet. Three situations come up often.

The process itself is still changing. If the way you quote or schedule is being reinvented every few months, software will freeze a moving target. Settle the process on paper or in a spreadsheet first, and build once it has held steady for a while.

The tool you already have is misconfigured, not inadequate. A surprising number of "we need custom software" conversations end with a few hours of configuration in a system the business already pays for. Fields nobody set up, automations nobody switched on, and reports nobody built are cheaper than any custom build.

Nobody can say what better looks like. If you cannot describe how you would know the new system was working, such as fewer errors, faster quotes, or hours saved each week, it is too early to spend money on it. Write that down first. It will also make whatever you eventually buy or build much easier to judge. We wrote about this in Nobody Agreed What "Working" Meant Before It Shipped.

"Not yet" is not a failure. It is often the cheapest and most useful thing anyone can tell you.

If You Do Build, Keep It Small

When building is the right call, the safest way to do it is small and specific: one process, one group of users, and one clear measure of whether it worked. Ship that, use it for a while, and only then decide what comes next.

A good first version usually replaces one painful workflow from end to end: the quote that takes an hour, the schedule that lives in someone's head, or the report that needs three exports and an afternoon. It should be small enough to finish in weeks, and useful enough that people would complain if you took it away. Everything else can wait for version two, when you know far more than you do today.

The same goes for machine learning. It is worth reaching for only once simpler methods have run out, which we covered in When You Don't Need Machine Learning.

Big custom builds fail for the same reasons big projects of any kind fail: too many decisions made too early, too little feedback, and too long before anyone sees it working. Small builds are easier to scope, cheaper to change, and much easier to walk away from if they turn out not to help.

If you want a second pair of eyes on the decision, tell us what you are weighing. And if you do decide to hire someone, here is what a well-run project with a small software firm looks like.