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

> A practical guide to deciding between building a custom system and buying off-the-shelf software, with criteria, warning signs and examples from operations.

Author: José Carlos Maciel, Founder and developer. Published 2026-09-30, updated 2026-09-30.
Source: https://boosting.tech/en/blog/custom-software-vs-off-the-shelf/

**Quick answer:** Choose off-the-shelf software for processes that are the same in any company, such as payroll, accounting and email. Choose custom for the process that sets your operation apart and that no product handles without a side spreadsheet. In practice, most companies use both, connected by integration.

Almost every operations company reaches this point. The ERP takes care of finance, but what happens in the yard, on the quay or in the field still lives in spreadsheets. Someone suggests buying one more module. Someone else suggests building an in-house system. This article helps you decide with criteria.

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

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

Off-the-shelf arrives fast and spreads the development cost across all customers. In exchange, you adapt your process to it. Custom goes the other way, with the software following the process.

## When is off-the-shelf 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 having a different payroll.

Martin Fowler calls this kind of system utility, as opposed to strategic. For utility systems, the goal is to work well and cost little. Building from scratch something the market already solves is spending money where there is no return.

## When is it worth building custom?

It is worth it when the process is what sets your company apart and no product handles it without workarounds. In field operations, that is usually the service itself.

An example from our projects. An [industrial tank cleaning](/en/case-studies/industrial-tank-cleaning/) company used an ERP for finance, but what its client bought was the service carried out and documented. The report by shift, the photo report, the certificate and the apportioning of idle hours did not exist in any product. That is what became a system.

## Which signs show off-the-shelf software is not working?

Five signs come up often.

| Sign | What it indicates |
| --- | --- |
| A side spreadsheet "everyone uses" | The system does not cover the real process |
| Data retyped from one system into another | Integration is missing |
| Only one person knows how to operate it | The process depends on knowledge that is not in the system |
| Paper form filled in on site | The system does not reach where the work happens |
| A queue of requests to the vendor with no date | You do not control how the software evolves |

One sign on its own is solved with configuration or training. Three or more call for a different conversation.

## What goes into the cost of each path?

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 of the vendor changing the product or the price.

With custom, 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. Anyone who budgets only for the build gets a surprise later. We cover that in [support and modernization](/en/services/support-and-modernization/).

There is also the cost of complying with the law. Any system that stores data about employees, visitors or customers has to meet data protection rules, whether off-the-shelf or custom. In Brazil that is the LGPD. With off-the-shelf, you depend on what the vendor offers. With custom, access and retention rules are your decisions.

## Can you combine the two?

Yes, and that 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 retypes anything.

In the [port operations](/en/case-studies/port-operations/) case, the platform we built reads the client's warehouse management system straight from the database and shows the warehouse operation on dashboards.

## How do you reduce the risk of a custom project?

By starting small. Pick the process that hurts most and put only that into use. A first version that solves a real problem in a few weeks teaches more than months of specification.

Three precautions help.

1. Involve the people who operate from the start. Whoever decides the purchase is rarely the one who uses the system.
2. Ask for deliveries in short cycles, with your team testing with real data.
3. Agree on support before the system goes into production.

That is how we run [custom web system](/en/services/custom-web-systems/) projects.

## Frequently asked questions about custom and off-the-shelf software

### Is custom software always more expensive?

At the start, almost always. Over the years it depends on how much the company spends working around what the off-the-shelf product does not do and how much it pays in per-user licenses. A fair comparison adds up the cost of several years, and not just the first.

### How long does a custom system take?

It depends on the size of the first flow. The best indicator is when the first version goes into use, and not when the whole system is finished. Systems that work keep evolving for years.

### What happens if the company that built it closes?

The risk exists and is reduced with simple measures. Have access to the code and the infrastructure, and prefer well-known open source technologies. Ruby on Rails, for example, has a large community, which makes it easier to find someone to carry on the work.

### Can I start with a spreadsheet and migrate later?

Yes. A well-used spreadsheet is a great requirements document, because it shows the fields, rules and exceptions of the process. It becomes a problem when several people edit at once or when history matters.

### Does a custom system work on a phone?

Yes, if it is designed for it. The systems we build open in the phone's browser and can be installed as an app. See the comparison in [apps](/en/services/mobile-apps/).

## References

- [Martin Fowler: Utility vs Strategic Dichotomy](https://martinfowler.com/bliki/UtilityVsStrategicDichotomy.html)
- [Brazil's General Data Protection Law (Law 13,709/2018, in Portuguese)](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm)
- [The Ruby on Rails Doctrine](https://rubyonrails.org/doctrine)