Custom software or off‑the‑shelf? How to decide

Choose off-the-shelf software when your process is similar to everyone else’s and a mature product already covers it. Choose custom software when the process is part of what sets your business apart, or when no product fits without heavy workarounds. For many companies the best answer is a hybrid: buy the standard core and build only the part that differentiates.

The build vs buy decision is rarely about technology. It is about how your business works, what the choice will cost over several years and how much control you need. The questions below give you a structured way to decide.

Start with the process: how unique is it really?

Accounting, payroll, e-mail and basic customer management work much the same way in most companies. Products for these have been refined over many years and across many customers. Building your own would mean paying to reinvent something that already exists.

Other processes are specific to you: the way you quote complex orders, plan field staff, price for different customer groups or handle a regulated workflow. Here a standard product forces a choice. Either you change the process to fit the software, or you bend the software with workarounds, spreadsheets and manual steps.

Three questions help:

• Would a competitor describe this process the same way we do?
• Does the way we do it give customers a reason to choose us?
• How many spreadsheets and manual steps sit around the tool we use now?

If the honest answer is “we do this like everyone else”, buy. If the process is the reason customers choose you, it deserves software that fits it.

Compare total cost of ownership, not the first invoice

Off-the-shelf software looks inexpensive because the cost is spread out. Custom software looks expensive because much of the cost arrives at the start. Neither impression tells you what you will have paid after several years.

What off-the-shelf software costs over time

• Licences per user or per transaction, which grow as the company grows
• A higher plan needed for a single feature
• Configuration, data migration and training
• Add-ons and connectors to other systems
• Staff time spent on workarounds

What custom software costs over time

• Analysis, design and development of the first release
• Hosting and infrastructure
• Maintenance, security updates and support
• Further development as the business changes
• Time from your own team to specify, test and decide

Put both lists in one sheet and calculate over the same period, using the number of users you expect at the end of that period rather than today. Ask suppliers on both sides for written figures. The cheaper option on day one is not always the cheaper option over the life of the system.

Integration needs: how well will the software connect?

Software rarely stands alone. Orders have to reach accounting, leads have to reach sales and stock has to match the online store. When systems do not connect, people copy data by hand, and errors follow.

Check what a standard product offers in practice: a documented interface, ready-made connectors for the systems you use, and any limits on how much data can be exchanged. Some products reserve integration features for their higher plans. Custom software can be designed around your existing systems from the start, but each connection still has to be built and maintained.

Data ownership and vendor lock-in

With a purchased product, the supplier decides the roadmap, the pricing and the terms. Features can change, and prices can rise at renewal. That is the normal trade-off for not having to build and run the product yourself, but you should enter it knowingly.

Before you sign, ask:

• Can we export all our data, in a usable format, at any time?
• Where is the data stored, and does that meet our legal obligations?
• What happens to our data if we cancel, or if the supplier closes the product?
• How have prices and terms changed for existing customers in the past?

Custom software is not free of lock-in either. You can become dependent on the team that built it. Reduce that risk by agreeing that you own the code, by insisting on widely used technology and proper documentation, and by keeping accounts and infrastructure in your own name.

Speed to start, and the risk of getting it wrong

A standard product can be in use quickly. That matters when the need is urgent or the process is still new. Using a purchased tool for a while is also a good way to learn what you need: requirements written after real use are better than requirements written from imagination.

Custom software takes longer to reach its first release. The risk is lowered by starting small — one focused release that solves a specific problem, tested with the people who will use it, then extended. A large specification delivered in one piece is the riskiest way to build.

The hybrid route: buy the core, build what differentiates

In practice the choice is seldom all or nothing. Many companies keep a standard system for the common core — accounting, CRM, a shop platform — and add a smaller piece of custom software for the part that is specific to them.

Typical examples are a customer portal on top of a standard ERP, a quoting tool that feeds the CRM, or a mobile app for field staff that reads from and writes to the existing system. The core stays maintained by its supplier. Your investment goes into the part customers and staff notice.

The hybrid route depends on one thing: the core product must have a good, documented interface. Check this before you choose the core, not after.

Build vs buy: comparison and decision checklist

The table summarises the trade-offs between the three routes.

To reach a decision:

1. 01Describe the process as it runs now, including the workarounds.
2. 02Mark which parts are standard and which are specific to you.
3. 03Shortlist a few products and test them against the specific parts.
4. 04Compare the total cost over several years for buying, building and the hybrid.
5. 05Check data export, integration and ownership terms in writing.

If the answer is still unclear after that, a short analysis phase is usually worth more than a long debate. You can read how we work through questions like this in our approach, or start a conversation.