If you already pay for off-the-shelf software and something is missing, you have three ways out, in this order of cost: switch on what the software already offers, integrate around it or build a module alongside it, and build your own system. In one audit we ran, three of a client's four requests already existed in the software they were paying for, switched off. Your own system pays off when the process is what your customers buy from you, and even then it can live alongside the off-the-shelf software instead of replacing it.
Where to start when the off-the-shelf software does not do everything#
If you already pay for off-the-shelf software and something is missing, you have three ways out, and they cost more in this order: switch on or configure what the software already offers, integrate around it or build a module alongside it, and build your own system. It is worth testing them in that sequence, because most gaps are closed by the first two.
The conversation usually arrives like this: the company uses a SaaS product or an off-the-shelf ERP, likes it for the most part and has a list of three or four things it "does not do". From there the question becomes whether it is time to commission a custom system, and it is still too early for that question.
First, each item on the list goes through three questions, one for each way out. Does the software already do this, with the feature switched off? Is the data already inside it, with only a screen or a workflow missing around it? Or does the missing piece have no place at all in the software you have? Each item can land on a different path, and it is common for three to be solved by configuration and only one to need software.
| Situation | Configure what exists | Integrate or build alongside | Build your own |
|---|---|---|---|
| The feature is in the menu, but switched off or set to zero | solves it, with hours of setup | not needed | paying again for what you already pay for |
| The feature exists in a more expensive plan from the same vendor | solves it, if the price difference fits | only if the plan is too expensive for the use | rarely pays off |
| The data is in the software and the reading is missing: targets, dashboard, cross-report | sometimes, through the software's own reports | solves it: read the data and build the screen outside | an unnecessary replacement |
| A whole process is missing, and it uses data from the off-the-shelf software | out of reach | solves it: a module alongside that reads from the software that stays | only if the rest of the software does not work either |
| The data a decision needs has no field in the records | out of reach | solves it, if those records can live outside the off-the-shelf software | solves it, when that data sits at the center of the operation |
| The process is what your customers buy from you | out of reach | reaches only the edges | this is where your own system pays off |
| The vendor will not let the data out | does not apply | limited reach, through exports | goes into the math, because the vendor's limit becomes yours |
How to find out whether the missing piece is already in the software, switched off#
The safest way is to go into the software from the inside, logged in, with someone who operates it next to you, and check each item on the list against the whole menu, the records and the settings. In an audit we ran in August 2026, three of a client's four requests already existed in the software they were paying for, switched off or set to zero.
This is more common than it sounds. According to Pendo's 2019 Feature Adoption Report (Pendo is a US company that measures software usage), 80% of the features in the average software product are rarely or never used, in a sample of 615 of its customers' accounts.
The August case was a management SaaS product that had been in use for five months and that, in the client's own words, worked very well. The request was for a system of their own with four improvements. We went in with the access the client gave us and found three of them in the current software: one was switched on, with 1 of 120 services published; another existed under a different name and was set to zero for all 120; the third was a module that had never been activated. We tell that story, with the audit checklist, in the article on when a legacy system needs to be replaced.
The same session showed something no brief shows. One of the requests was a paid monthly loyalty program aimed at individual consumers, and when we sorted the customer base by how much each customer had spent, the top of the list was other businesses that bought in volume. The question became who the program was for, and that answer belongs to the business owner.
You can do much of this check on your own, before asking anyone for a quote:
- Go through the whole menu, item by item, and not just the everyday screens.
- Open the settings of each record type. A feature that depends on a per-item field, such as a deadline, a reminder or a publish flag, often comes set to zero.
- Look for modules that ask you to accept terms before they turn on. They stay idle until someone accepts.
- Ask the vendor, in writing, what exists in the plans above yours.
- Look at the records behind each request. If the feature depends on data that has no field at all to exist in, that is the part that calls for software. That was the case with the fourth request in August: the filter the client asked for depended on data the records did not have.
When to integrate around the software that stays#
Integration makes sense when the data you need is already in the off-the-shelf software and what is missing is the reading, the screen or the workflow around it. The off-the-shelf software remains the owner of the data, and whatever gets built reads from it, so nothing that already works has to be rebuilt.
Fitness Academia, a network of five gyms in southern Brazil, already had every sale in NextFit, the off-the-shelf ERP it uses. What was missing was the sales target, rebuilt by hand in a spreadsheet with different criteria at each location. The platform we built reads NextFit every five minutes and never accepts a sale typed in by hand, so the target number now comes from the same place as the sale. NextFit lost no feature, and the team kept selling through the system it already knew.
At Epicora itself the logic is the same. Controlle remains our financial system, and the partners' dashboard reads entries and balances from it.
Two things weigh in before you close the scope: what the vendor lets out, whether an API, an export or nothing, and how fresh each piece of data needs to be. What the system on the other side decides for you is covered in integrating with the ERP your operation already uses. And if a spreadsheet survives next to the off-the-shelf software, only rearranging its data, it is the best map of what still needs to be read, as we show in spreadsheet, off-the-shelf ERP or custom software.
When to build a module alongside the off-the-shelf software#
A module alongside makes sense when a whole process is missing that the off-the-shelf software does not cover, but that depends on data already living in it. The off-the-shelf software keeps doing what it does well, and the new module is born reading from it.
Ideal Veículos, a car dealership group with 11 stores in Brazil, manages its inventory in Altimus. Financing each sale, which means choosing among dozens of lenders the one that approves that customer for that vehicle, lived in Excel spreadsheets, and no software on the market handled the process the way Ideal works. The decision was to build only what was missing.
The financing platform is custom-built and holds the rules of each of the 19 lenders the group works with. Inventory stays in Altimus, and more than 3,000 vehicles arrive synchronized from it. Whoever puts together a financing deal types the license plate or the chassis number, and the rest of the vehicle's data comes filled in, with nobody copying from one system to the other. The details are in the Ideal case study.
The module alongside depends on what the off-the-shelf software delivers. Altimus offers no API, and the integration was built on an inventory export, which is why it stayed with inventory and never reached the customer base, which was also in the plans. And each piece of data has a single owner: the vehicle belongs to the inventory system and arrives by reading, and the financing belongs to the new platform.
When your own system is the answer, even with hundreds of ready-made options#
Your own system pays off when the process is what your customers buy from you, or when the knowledge that decides the service belongs to your company and does not fit in a product built for the whole market. In those cases, configuring and integrating do not reach far enough, because what is missing is the center of the operation.
A consultant who wants to sell her own method as a product told us, in a discovery meeting, that there are "300,000 recruiting and selection platforms, but these questions follow the format of my methodology". The obvious question, why not use one of the ready-made ones, she answered in the same sentence. Her customers buy the method, and a ready-made platform was designed to serve any consultancy. In the product we are modeling with her, the core is exactly the part none of the ready-made ones have.
At Beckers, which services industrial fans for meat processors and agricultural cooperatives in Brazil, the inspection report lived in a Word document, and the price of each repair lived in the experience of whoever put the quote together. We built a diagnostic catalog that Beckers maintains itself, with the possible defects of each part of the equipment and the price of each repair level, and an app in which the technician fills in the report at the workbench. That catalog is the in-house engineering knowledge, which no software on the market would ship with. The system has been live since April 2025 and has issued 428 reports.
There are three signs that the answer is to build your own:
- The process is the reason customers choose your company, and a ready-made product follows the average way of the sector.
- The rule that decides the service is in-house knowledge and has to be maintained by the people who understand it.
- The data the operation depends on has nowhere to live in the off-the-shelf software, and it sits at the center of the work.
Even then, your own system can leave to the off-the-shelf software what is the same for everyone, such as tax invoicing, payroll and accounting.
Why replacing off-the-shelf software is almost never the first answer#
Replacing it forces the new system to redo everything the off-the-shelf software already does well before delivering the first improvement. And an operation that never configured its current software tends to leave the new one switched off in the same way. That is why the first answer is almost always to switch on what exists and build only what is missing.
When a client says the current software works very well, that sentence becomes the yardstick of the project. In an audit we ran in August 2026, the off-the-shelf software's menu had more than thirty items, and every one of them would be compared with a new system on its first day of use. Replacing means migrating records and history, retraining the team and rebuilding features nobody listed because they work, and the improvement that motivated the change only arrives after all of that.
The second reason is less obvious. That software had been in use for five months with 119 of its 120 services missing from the public booking page. A new system handed to the same operation would arrive switched off in the same way, so when a project like this goes ahead, configuration and adoption need to be in the scope as deliverables, with an owner and a deadline.
Replacement starts to make sense when the data is locked in by the vendor and the process depends on it, when nobody can change the software to keep up with the operation, or when the team already works around it, in spreadsheets and messages.
And your own system does not mean a system built from scratch. In the projects where the operation already had off-the-shelf software, ours included, it stayed in place: NextFit, Altimus and Controlle remain where they were, and what we built reads from them.
Frequently asked questions#
Is it worth replacing off-the-shelf software that works well with a system of your own?#
Almost never as the first answer. If the software works well for the most part and a short list of things is missing, each item usually gets solved by configuring what already exists or by building a small piece alongside it. Replacement belongs in the conversation when the data is locked in by the vendor, when the software will not let the operation change, or when the team already works around it.
How do I know whether the missing feature already exists in the software I use?#
By going through the software from the inside, with someone who operates it next to you: the whole menu, the settings of each record type, the modules that ask you to accept terms before they turn on, and what exists in the plans above yours. A feature that depends on a per-item field, such as a deadline or a publish flag, is often there and set to zero. If it depends on data that has no field at all in the records, that is the part that calls for software.
Does a system of your own have to replace the off-the-shelf software?#
No. Your own system does not mean a system built from scratch. In our projects where the client already had off-the-shelf software, it stayed in place: NextFit still holds the sales of the gym network, Altimus still holds the dealership's inventory, and what we built reads from them and covers only what was missing.
What if the off-the-shelf vendor will not let the data out?#
You can still integrate, with less reach. Many systems without an API offer some kind of export, such as a file or an address that returns the whole database, and that is enough for data that changes slowly, like inventory. Whatever the export does not include becomes a limit on what you can build around it. If the whole process depends on data the vendor will not release, replacing the software starts to make sense.
Why have your own system when there are so many ready-made platforms?#
Because a ready-made platform is built to serve any company in the sector, and sometimes what your customers buy is precisely the way your company does things. A consultant who wants to sell her own method as a product told us there are 300,000 recruiting and selection platforms, but that her questions follow the format of her methodology. When the process is the product, your own system pays off.
Sources#
- Pendo, The 2019 Feature Adoption Report, on the share of features that are rarely or never used, in a sample of 615 accounts: https://www.pendo.io/resources/the-2019-feature-adoption-report/
Next step#
Before asking for a quote on a new system, write down the list of what is missing in the software you already pay for and run each item through the three questions: is it switched off, is only the reading missing, or does it have no place in the software? If the answer is to integrate or build a piece alongside, that is the work we do in integrations and APIs, as with the Fitness Academia sales-target platform. If what is missing is the center of the operation, it is the work of custom systems.