The short answer
Choose off-the-shelf software when your process is standard in your industry and the tool covers the routine without side spreadsheets. Choose custom software when the process is what sets your operation apart, when the tool forces workarounds or when several systems need to talk to each other. Often the best answer is to combine the two.
The decision is not about technology, it is about the cost of each path over time: how much you pay to get in, how much manual work is left around the tool, who controls the data and the code, and what happens when the process changes. This guide lays out those points so you can decide with clear criteria.
Start with the process, not the tool
The question "buy or build" usually comes too early. Another one comes first: what the operation needs to happen, who does each step and where the work gets stuck today. Without that answer, any choice is a gamble.
That is why the first step of every project we take on is to understand the operation and its users before proposing technology. Sometimes the conclusion is that a well configured market system solves it, and we say so. When the case is not obvious, we look at five points:
- How specific the process is. If the way you operate is part of what you deliver to your customers or to citizens, forcing it into a generic tool has a cost.
- How many systems need to talk to each other. Many fragile integrations between scattered tools usually weigh more than a single system that brings the routine together.
- Who needs to be served. Very different profiles, such as citizens, front desk staff and management, call for screens and permissions that an off-the-shelf tool does not always offer.
- Data requirements. Healthcare, personal data and the public sector call for access control, compliance with Brazil's data protection law (LGPD) and a record of every change.
- The cost of keeping workarounds. Hours of rework and double checking are a cost too, even if they never show up on an invoice.
Off-the-shelf vs. custom software: a point by point comparison
The table sums up the differences that weigh most in the decision. Neither column wins on every row, which is why the answer depends on your case.
| Criterion | Off-the-shelf software | Custom software |
|---|---|---|
| Upfront cost | Low: subscription or license, setup and training. | Higher: discovery, design and development before use. A lean first version shortens that start. |
| Fit with the process | The process adapts to the system. It works well for routines that are standard in the industry. | The system adapts to the process, including the rules that set your operation apart. |
| Integration | Depends on what the vendor offers: an API, file exports or nothing at all. | Planned from the start with the systems you already use. See how to integrate systems. |
| Code ownership | The vendor. You have the right to use it while you keep the subscription or license. | Defined in the contract from the start. Learn who owns the code of custom software. |
| Evolution | Follows the vendor's roadmap. A specific request may never make it in. | Follows your priorities, cycle by cycle, based on what real use shows. |
| Vendor dependence | High: pricing, versions and the product's future are the vendor's decisions. | Lower when there is versioned code and documentation, because another team can take over. |
Two points are often left out of the math. With off-the-shelf software, the manual work around the tool (spreadsheets, double checking, retyping) is a cost, even if it never shows up on an invoice. With custom software, the system needs maintenance and evolution after it goes live, and that should be planned from the start.
Signs that off-the-shelf software is enough
A market system tends to be the right choice when most of these points are true:
- The process is standard in your industry. Payroll, accounting and email are classic examples: the way you do them is not what sets your operation apart.
- The tool covers the whole routine. There are no workarounds, side controls or support spreadsheets to fill the gaps.
- The integrations already exist or are simple. The system connects to what you use through an API or ready-made connectors.
- You need to start right away. And you accept adapting the process to the system in exchange for speed.
- Your data comes out whenever you want. The tool exports everything in an open format, which leaves you a way out if things change.
In these cases, building from scratch spends time rebuilding something that already exists. It is also worth looking at what the tool's vendor has planned: if what is missing is on the roadmap for the next versions, waiting may make more sense than building.
Signs that it is time for custom software
The problem shows up little by little. The signs pile up until the team spends more time working around the tool than doing the work.
- The team works around the tool. Shortcuts, side controls and rework to make the system accept a routine it was not designed for.
- The operation runs on spreadsheets. Each department has its own version and nobody knows which one is right.
- The same data is typed several times. On different screens, and the mismatches turn into checking work.
- Management decides without data. The report depends on someone building a spreadsheet at the end of the month. By the time it arrives, the problem has already happened.
- Very different profiles use the same process. Citizens, front desk staff and management need screens and permissions that an off-the-shelf tool does not always offer.
- The data requires strict control. Healthcare, personal data and the public sector call for access control, compliance with Brazil's data protection law (LGPD) and a record of every change.
That is what we found at an urgent care unit. The market system did not keep up with the operation: the integration with the National Health Card failed, the risk classification priority did not reach the consultation and the reports for the city government turned into spreadsheets. The answer was a custom patient management system, from reception to the management report.
The hybrid path: off-the-shelf software with integrations and automation
The decision is not always to replace everything. Often the best result comes from keeping the systems that already work and building custom only the missing part, connected by API to what exists. The data is entered once and reaches the other systems without retyping.
In our beacon monitoring at a healthcare unit, management wanted to see attendance numbers in the dashboards it already used, without one more system for the team to open in the middle of a shift. The data reaches those dashboards through an API instead of a new screen.
The hybrid path also works for the repetitive work around an off-the-shelf tool. Checking documents, copying data from an email into the system or putting together the same report every week are tasks that automation with artificial intelligence can take over, without replacing the main system. The most common forms:
- Integration by API. The off-the-shelf system remains the main record, and a custom module reads from it and writes to it.
- Add-on module. One specific part of the routine gets its own system, and the rest stays in the market tool.
- Automation around it. Manual tasks between systems start to happen on their own, with human review where needed.
The limit of the hybrid path shows up when the off-the-shelf system is itself the bottleneck: no API, no export, or rules that conflict with the process. At that point we show you the cost of keeping it and the cost of replacing it, so the decision is yours and well informed.
How to test the decision before you commit
When the doubt persists, a short study helps. It maps the routine with the people who run the process, shows what the current tool covers and what it leaves out, and defines the scope of a custom system if that makes sense. It is the first step of how we work: you decide with the map in hand, not with each department's impression.
If the answer is to build, you do not need to build everything at once either. A lean first version, the MVP, focused on the routine that suffers most, goes into use while the rest is built. If the answer is to buy, test the tool with concrete cases from your operation during the trial period, not just with the vendor's demo.
Ownership, continuity and exit: what to check in both cases
With off-the-shelf software, the question is how to get out. Check whether the data can be exported in an open format, whether there is a documented API and what the contract says about price adjustments and the end of the service. A system that locks in your data turns a future switch into a migration project.
With custom software, the question is who carries it on. Code ownership and knowledge transfer are defined in the contract from the start, and decisions, versions and risks are documented. The project's knowledge does not depend on anyone's memory, and another team can take over if needed.
If you are facing this question now, tell us what your current tool does not solve. The first conversation already helps separate what calls for custom software from what calls for an adjustment or an integration.