Custom software or off the shelf? When building is worth it — and when it isn't

Every growing business eventually hits the same question. The tools that got you here are starting to creak, the workarounds are multiplying, and someone suggests building something bespoke. Someone else points out that there are a dozen products on the market that claim to do exactly what you need. Both of them might be right.

We build custom software for a living, so it may be surprising to hear that our default advice is to buy first. Off-the-shelf products carry years of other people's edge cases, security fixes and support. The case for building is real, but it is narrower than most sales conversations suggest, and it is worth being precise about where it applies.

Start with what makes you different

The most useful test is simple: does this process differentiate you from your competitors, or is it something every business does roughly the same way? Payroll, accounting, email, document storage and most HR processes are commodity functions. There is no advantage in doing them in a unique way, and very good products exist. Building your own is almost always a poor use of money.

The picture changes when the process is the business. A distribution company whose margin depends on how quickly it can quote, allocate stock and schedule deliveries across several warehouses may find that no product models its rules properly. A specialist services firm may have a way of pricing and delivering work that is the reason clients choose it. Forcing those processes into a generic tool means either changing how you operate to fit the software, or maintaining an ever-growing layer of spreadsheets around it.

Buy the things every business does. Build the things that make you worth choosing.

Signs that off-the-shelf is reaching its limits

Outgrowing a product rarely happens in one moment. It shows up as friction that accumulates quietly. The signals we look for are practical ones:

• Staff re-key the same data into two or three systems because they do not talk to each other.
• Critical logic lives in a spreadsheet that one person understands and everyone is nervous to touch.
• You pay for several seats or modules mainly to get around a missing feature.
• Reporting requires exporting from multiple tools and stitching the results together by hand.
• The vendor's roadmap has become your roadmap, and the feature you need is always next quarter.

None of these on their own means you need custom software. Several of them together, in a process that matters commercially, is a strong hint.

The costs people forget on both sides

Off-the-shelf pricing looks straightforward, but per-user licences grow with headcount, premium tiers tend to hold back the features larger teams need, and migrating away later can be painful if your data is hard to export. It is worth reading the contract for data ownership and export terms before you commit, not after.

Custom software has its own hidden costs, and they are larger than most buyers expect. The build is only the beginning. Someone has to host it, patch dependencies, monitor it, fix bugs, and adapt it as the business changes. A realistic budget treats ongoing maintenance as a permanent line item rather than an afterthought. If there is no appetite to own a piece of software for years, building one is the wrong decision, however elegant the first version is.

There is also an opportunity cost. A bespoke system takes months to reach the maturity a product already has on day one. If speed matters more than fit, buying and adapting your process is usually the better trade.

The middle ground is often the right answer

The choice is rarely binary. Many of the most successful projects we see keep proven products for the commodity parts and add a thin layer of custom software where it earns its keep. Common patterns include:

• Integration first. Connecting existing tools through their APIs so data flows automatically, removing re-keying without replacing anything.
• A custom front end on standard back ends. A focused internal application for one workflow that reads from and writes to your CRM, accounting and stock systems.
• Extending a platform. Building on the extension points of a product you already use, where its data model is broadly right but a few workflows are missing.

Well-built API integrations are frequently the cheapest way to remove most of the pain, and they leave your options open. If the integrated setup still falls short, you will have a much clearer specification for what a custom system needs to do.

Questions to answer before you decide

If you do decide to build, be wary of anyone who is keen to start writing code before understanding the process in detail. A good supplier will want to see the spreadsheets, sit with the people doing the work, and challenge whether every requirement is needed. Our guide to scoping a software project covers how to prepare for that conversation.

When not to hire anyone

Sometimes the right move is to change nothing technical at all. If the problem is that a product is configured badly, or that the team was never trained on features it already has, a few days with the vendor's documentation or support team may fix it. If the process itself is unclear or disputed internally, software will only encode the confusion. Settle how the work should happen first.

The short version

Buy for commodity functions. Integrate before you replace. Build only where the process is central to how you compete and you are prepared to own the result. When those conditions are met, custom software development can give a business something no competitor can buy off the shelf, and that is the only reason it is worth the investment.