Off-the-shelf or custom software for your business

The debate about off-the-shelf or custom software often starts after a demonstration. The tool seems to fit until someone asks about a special price, an approval or a report that combines data from three departments. The answer is that it can be done, although it is not yet clear who will do it or how much work it will take each month.

The reverse happens too: someone proposes building an application for a process that an existing tool could handle with reasonable configuration. It is easy to confuse a deeply established way of working with a requirement that genuinely sets the business apart.

Before choosing, separate those two things. Some habits are worth changing, while some rules must be respected because they affect service, commercial commitments or operational control.

The decision starts with the process

Choose a specific journey, from the moment a request arrives until it is completed. Describe who is involved, what information they need and what happens when everything goes well. Then add the exceptions the team actually handles: a correction, a pending approval, a return or late data.

This journey lets you assess a tool more meaningfully than a list of modules. “It has invoicing” says little if your business needs to review items before issuing an invoice, group transactions or maintain a precise link to completed work.

Not every difference justifies development. Changing the order of a screen or adopting shared terminology can simplify operations. Moving an essential check into a separate spreadsheet, however, may leave the original problem untouched.

The useful question is how much work remains outside the system and what consequences that has. An infrequent exception may be manageable by hand. A daily review that depends on one person deserves a closer look.

When an existing tool fits

An off-the-shelf solution is a good candidate when it covers the main process, allows relevant differences to be configured and can be used without maintaining a parallel system. Its value lies in using an existing foundation and focusing the effort on implementing it properly.

Implementation is work too. Data needs cleaning, permissions need decisions, the team needs training and reports need checking against actual operations. The subscription does not replace these tasks, even if the product works correctly from day one.

Ask for a demonstration using one of your examples. If a requirement depends on an extension, confirm which part the product handles, which part the extension provides and who maintains the combination. A specific answer can turn an apparent limitation into a perfectly reasonable solution.

It also helps to accept a scope boundary. If the first goal is to organise one team's requests, you do not need to resolve every connection with accounting, customers and suppliers immediately. The tool may fit that first phase even if it will not become the company's central system.

Integration can close the gap

Sometimes tools work well individually, but people act as the connection between them. They copy data, check statuses and re-enter information that already exists elsewhere. In that situation, replacing everything may add more risk than value.

An integration lets you retain systems that work and automate part of the exchange. To assess feasibility, you need to review the data each tool exposes, the operations it allows and its limitations. Having an API, an interface that lets two programs communicate, is the start of that review.

It is particularly important to decide which system owns each piece of data. If a price is maintained in two places, you need to determine which takes precedence and how discrepancies are detected. You also need to know what happens when a connection fails: whether it retries, whether someone is notified and whether a transaction could be duplicated.

This work is part of custom software development, even when the outcome is a small connection rather than a new application. Its scope deserves the same care.

What justifies building your own tool

Custom development becomes more compelling when important rules do not fit the alternatives you have assessed, when workarounds create manual work or when the process needs freedom to evolve that those tools do not offer.

The advantage is being able to design the system around operations. The responsibility is deciding what to build, validating that it solves the problem and supporting it afterwards. Delivering screens is not enough: someone must be able to understand the system, maintain it and support changes in the business.

The published Quiralis case describes a platform connecting medical procedures, authorisations and invoicing. An older system was replaced in phases, with previous processes retained alongside the new platform while each area was validated.

That case illustrates an adaptation and transition decision. It does not mean every centre needs the same platform or that building from scratch is always the best answer. The need depends on what already works, what is missing and the specific conditions of the operation.

Compare several years of work

The initial budget is not enough to assess the options. Consider implementation, licences or infrastructure, integrations, support, training and foreseeable changes. Include the manual work the team will still perform after delivery.

Custom software may require more initial investment and still suit a specific process. An off-the-shelf tool may remain the cheaper option despite a recurring subscription. Neither conclusion can be reached simply by reading the first invoice.

The comparison improves when all proposals cover the same scope. A quote including migration, testing and support is not directly comparable with one delivering only the initial configuration. Ask for exclusions to be explained, because they often account for a substantial part of the difference.

Avoid turning the analysis into an exact savings prediction. It is more useful to work with scenarios and visible assumptions: how many people perform the task, how often, how long it takes today and which parts will still need intervention.

Being able to change providers matters too

Before signing, check which data you can export, in what format and with which relationships intact. A download containing records but losing documents or links may be insufficient for a future migration.

For custom development, agree on code access, necessary documentation and management of infrastructure accounts. A copy of the repository helps, but a handover also requires knowing how to deploy the system, recover the data and identify the external services involved.

For an off-the-shelf product, check exit terms and integration restrictions. Dependence does not disappear when you choose one approach over another. It changes shape, and it is worth understanding before it becomes a problem.

A first phase that supports a better decision

If too much remains unknown, define an analysis phase with a concrete deliverable: the process and exceptions, required data, assessed alternatives and a proposed scope. A limited trial can test the most uncertain point, provided it is clear which decision the trial will support.

When a custom application already exists, also check whether improving one part would be enough. Choosing to refactor or rewrite answers a different question: how much of the current system is worth keeping. That decision should not be settled in advance by the preference of whoever presents the proposal.

Software that fits lets the team work with less friction and understand what happens when an exception arises. Reaching that outcome requires enough knowledge of the operation to distinguish what is worth changing from what needs to be preserved.