Custom software vs off-the-shelf: how to decide

Almost every company with field operations reaches this point. The ERP handles finance and invoicing, but what happens in the yard, on the quay or in the field still lives in spreadsheets. In the meeting, someone suggests buying another module from the vendor. Someone else suggests building a system of your own. Both are partly right, and the discussion tends to revolve around the price of the first proposal.

This article helps you decide with clear criteria. It separates the processes that call for off-the-shelf software from those that call for a custom system, shows what each path costs beyond the license and gives you a 16-question checklist to apply to one of your processes. It is the starting point for the other articles on this blog, such as digital permit to work, third-party access control and PWA vs. native app.

What is the difference between off-the-shelf and custom software?

Off-the-shelf software is a product built for many companies, which you configure within the limits the vendor allows. A custom system is built for your process, and your company decides what it does and when it changes.

Off-the-shelf arrives quickly and spreads the development cost across all customers. In return, you adapt your process to the product. Custom software goes the other way: the software follows the process, and one company carries the cost of building it.

When is off-the-shelf software the best choice?

Off-the-shelf software is the best choice when the process is the same as in any other company. Payroll, accounting, invoicing, email and video calls are good examples. Nobody wins a customer by running payroll differently.

Software engineer Martin Fowler calls this kind of system utility, as opposed to strategic. In his words, it comes down to "whether the underlying business function is a differentiator or not". For a utility function, his advice is to "buy the package and adjust your business process to match the software", with enough care to avoid a catastrophic failure and no more.

The UK government's Service Manual follows the same reasoning. It tells teams to map the components of a service to learn what to build and what to buy, and to minimise the total cost of ownership, including the chance of getting locked into long contracts with specific providers.

When is custom software worth building?

Custom software is worth building when the process is what sets your company apart and no product handles it without a side spreadsheet. In field operations, that is usually the service itself. Fowler puts the risk on this side differently: for strategic work, the biggest risk is a competitor doing it first, and cost matters much less.

Here is an example from our projects. An industrial tank cleaning company ran an ERP for finance, but what its customers paid for was the cleaning job, carried out and documented. Execution by shift, the photo report with before-and-after pairs, the cleaning certificate and the split of downtime hours in the billing sheet existed in no product. That became the system. The ERP kept handling finance.

The line between the two also moves. A process that is common today can become a differentiator when the company decides to compete on it, and the reverse happens too.

What are the signs that off-the-shelf software is not working?

The clearest signs are repeated work and information that lives outside the system. These come up often in the companies that contact us:

One sign on its own can be fixed with configuration or training. Three or more call for a different conversation, and the checklist in the next section helps organize it.

Checklist: off-the-shelf or custom software?

The checklist below turns the criteria in this article into 16 questions. Apply it to one process at a time: the same company usually has processes that call for off-the-shelf software and others that call for a custom system.

If the ticks are split, the most common answer is a mix: the off-the-shelf product stays where everything is standard, and a custom system covers the process that sets the operation apart, with integration between them. Take the completed checklist to conversations with vendors of both kinds. It quickly shows who understood your process.

What does each path cost?

With off-the-shelf software, the visible cost is the license. The hidden cost is the time the team spends working around what the product does not do, plus customizations billed separately and the risk that the vendor changes the product, the plan or the price. Per-user licenses also grow with the team.

With custom software, the visible cost is development. The hidden cost is support. A system needs fixes, security updates and adjustments for as long as it is in use, and anyone who budgets only for the build gets a surprise later. We cover this in support and modernization. If you already have an old system and the question is how to replace it, see legacy system modernization.

There is also the cost of complying with the law. Any system that stores data about employees, visitors or customers must meet the data protection rules that apply to you. In Brazil that is the LGPD, the general data protection law, comparable in scope to Europe's GDPR. Its article 46 requires technical and administrative security measures to protect personal data, and paragraph 2 says they must be observed from the design stage of the product. With off-the-shelf software, you depend on what the vendor offers. With custom software, access and retention rules are your decisions, made when the system is designed.

A fair comparison adds up several years on both paths. We do not publish a price list because the cost depends on the size of the first workflow, the integrations and the volume of use.

Can you combine both?

Yes, and it is the most common setup. The ERP keeps handling what is the same for everyone, and a custom system handles the field process. The two exchange data through integration, so nobody types anything twice.

In our port operations case study, the platform we built reads the customer's WMS data straight from its database and shows warehouse activity on dashboards, without replacing the WMS. In the tank cleaning case, the field ERP produces the billing sheet that finance uses.

How do you lower the risk of a custom software project?

Risk drops when the project starts small. Pick the process that hurts most and put only that into use. A first version that solves a real problem within a few weeks teaches more than months of specification.

1. Involve the people who run the process from the first interviews. The person who approves the purchase is rarely the person who uses the system.
2. Use today's paper forms and spreadsheets as requirements. They show the fields, rules and exceptions the process really has.
3. Ask for deliveries in short cycles, with your team testing on real data.
4. Require access to the code, infrastructure and data from day one.
5. Agree on support before the system goes live.

The stages from discovery to production are covered in custom software project.

That is how we run our custom web system projects. The oldest system we maintain has been in continuous development since 2019 and grew from a single process.

When does neither path solve the problem?

Neither path helps when the process is not defined yet. If each team does it differently and nobody can say which way is right, buying a product or building a system will only record the confusion. In that case the first job is to design the process with the people who run it, and a well-kept spreadsheet is a good tool for that.

It also makes sense to pause when the decision hinges on something software does not change, such as a contract, the team structure or a regulation under review. If you would like help applying the checklist to your case, the first conversation has no cost.