- Buy where the process is standard and the vendor knows it better than you do.
- Integrate where your existing systems already do the job and the gap is the data between them.
- Build only where the process is how you win work or deliver differently.
- Keep the ERP close to standard, and put differences around it, not inside it.
Every industrial company eventually hits the same moment. A process is not working. Someone says "we need software for this." And then the real argument starts: do we buy something, build something, or connect what we already have?
Getting this wrong is expensive in both directions. Build what you should have bought and you carry maintenance for a product nobody else has to carry. Buy what you should have built and you spend years bending a standard tool around a process it was never designed for. A software gap is simply a business need that your current systems do not meet. This article gives you a way to decide how to close it.
Infomaze builds custom software for a living. So you should know our bias: in most cases we would tell you not to build. Custom software is worth it in a narrower set of situations than most vendors will admit, and we would rather say so up front.
9 Ways to Choose Between Building, Buying, or Integrating Software
The three choices
Adopt a product
A SaaS or packaged product built for a standard need. You configure it and run it on the vendor's roadmap.
Connect what you have
Link existing systems through APIs, webhooks or data feeds so information moves without being retyped.
Create it yourself
Design custom software around your exact process. You own it, and you maintain it.
They are not rivals. The best answer for a given gap is often one of them, and the best architecture for the whole business usually uses all three.
When buying SaaS is best
Buy when the process is the same in most companies, when the vendor has more domain expertise than you could build, and when speed matters. Payroll, expenses, HR, standard accounting, e-signature and general project tracking are typical examples. The vendor also handles regulatory updates and security patches, which is a real advantage in anything tax-related or compliance-heavy.
But buying is not free of effort. Each product adds another system to connect, secure and pay for. Zylo's 2026 SaaS Management Index, as widely reported, puts the average organisation at around 305 SaaS applications, with roughly a third of licences going unused. Before you buy, check four things:
- Fit. Does it meet at least 80% of the need without workarounds?
- Integration. Does it have a usable API, and who will connect it to your ERP?
- Data. Can you export everything, in a usable format, if you leave?
- Price creep. How do per-user, per-module and per-transaction fees grow as you do?
When custom software makes sense
Build when the process is part of how you compete. If a competitor could buy the same tool on Monday and match you by Friday, it is not a differentiator, and you should buy it. If the process encodes your pricing logic, your engineering know-how or your delivery method, it probably is one.
Custom software earns its place when all of these are true:
- The workflow is specific to your business and no product fits without heavy compromise.
- The volume or value of the process justifies the investment.
- You can name an owner in the business who will decide what it should do.
- You are ready to maintain it for years, or to work with a partner who will.
Typical industrial candidates are estimating and quoting systems, project and job tracking, production applications, procurement workflows and customer or supplier portals. Start with the smallest useful release, not a grand platform. See our custom application development and manufacturing software work.
When integration solves the problem
Often the software is fine and the gap is the handover. The ERP works. The CRM works. But someone exports from one and retypes into the other. That is an integration problem, and it is usually the cheapest and fastest to fix.
- Quotes and orders moving between CRM and ERP
- Job status from the field reaching the office system
- Machine or MES data feeding reports and ERP records
- Supplier confirmations updating purchase orders
Integration has its own trap: a web of point-to-point connections that nobody documents. Plan it deliberately, with monitoring and a clear owner. Our ERP workflow automation article explains the manual layer this removes, and our API integration services cover the technical side.
Common mistake: customising ERP too heavily
This is the most expensive version of "build" because it hides inside something you bought. Someone needs a different approval, a special pricing rule or a custom report, and the quickest route is to modify the ERP. It works. And then every upgrade has to carry that change forward.
PwC's June 2026 analysis of over-customising ERP systems describes the pattern: recurring maintenance costs that rarely appear in the original business case, and migration projects that become far more complex as customisations accumulate. Gartner went further a decade ago, noting that businesses had spent up to ten times their licence fees on customisations and described long-customised ERP systems as "arthritic". IDC has made the lock-in point as well: heavily customised systems tend to stay on old versions because upgrading costs so much.
A simple rule works well:
- Configure first. Use the settings the vendor built to be changed.
- Extend outside the core second. Build the difference as a separate application or workflow, connected by API.
- Modify the core last, and only for a genuine need nothing else can meet, with the cost counted across every future upgrade.
The hybrid approach
In practice, most industrial companies end up with a mix, and that is healthy. A sensible architecture looks like this:
Core
ERP and other standard systems, kept close to vendor standard so upgrades stay routine.
Connection
APIs and automation that move data and approvals between systems without re-entry.
Differentiation
Custom applications for the processes that set you apart, reading from and writing to the core.
The benefit is that each layer can change at its own pace. You can swap a SaaS tool without rebuilding your estimating system, and upgrade the ERP without breaking your portal. Our industrial software, automation and AI page describes this operations layer in more detail.
Decision framework
Six questions, asked in this order, settle most decisions. They are a way to structure the conversation, not a scoring formula.
Is the process standard across your industry?
Yes: lean toward buy. No: keep going.
Does the process help you win work or deliver better than competitors?
Yes: lean toward build, or buy and extend. No: lean toward buy.
Is there already a system that holds the data or does most of the job?
Yes: lean toward integrate. No: buy or build.
How fast do you need it?
Fast: buy or integrate. A staged build can still deliver a first module quickly.
Who will own and maintain it for the next five years?
If nobody can answer, do not build.
What does it cost to leave?
Check data export, contract terms and code ownership before you commit to any option.
Example scenarios
Payroll, expenses and HRBuy
Standard process, strict regulation, and the vendor ships the updates. Building this would be spending effort to reproduce what thousands of companies already get from a product.
Approved CRM quotes retyped into the ERPIntegrate
Both systems work. The gap is the handover. An API-based integration with an approval step removes the re-entry without touching either system.
Estimating tool with your own pricing rules for engineer-to-order workBuild
The pricing logic is how you win bids. A packaged tool would force you to bend it to fit, or hand a competitor the same capability. Build it, and integrate it with your ERP.
Customer and supplier portal showing order and job statusBuild, on top of the ERP
Do not customise the ERP to expose data. Build a thin portal that reads from the ERP through APIs, so the ERP stays close to standard.
Shop-floor data capture where an MES or machine system already existsIntegrate
The data exists already. Connect it to the ERP and reporting rather than buying a second capture system.
Maintenance and asset tracking for a standard fleet of equipmentBuy first
Mature products exist and the process is largely standard. Buy, then integrate with the ERP and purchasing. Build only if your maintenance process turns out to be genuinely unusual.
Decision matrix
How each option rates against common requirements. Read across a row to see which option is strongest for that need, then read down the column for the one that fits most of your priorities.
| Requirement | Buy | Integrate | Build |
|---|---|---|---|
| Standard process | Strong | Medium | Weak |
| Unique operational workflow | Weak | Medium | Strong |
| Fast implementation | Strong | Medium | Weak |
| Existing core system | Weak | Strong | Medium |
| Competitive process | Medium | Medium | Strong |
No option wins every row, which is the point. A real project usually has two or three of these requirements pulling in different directions, and the matrix shows why a hybrid answer is so common.
Looking at a software gap and unsure whether to build, buy or integrate?
Describe the process and the systems involved. We will give you an honest recommendation, even if the answer is to buy a product and not build anything.
Talk to our team →Related reading: SaaS vs custom application: when to buy and when to build and how to modernise legacy manufacturing software without disrupting operations.
Frequently Asked Questions
Sources: PwC Malta, "The hidden costs of over-customising an ERP system", 16 June 2026. Gartner analysis on customised ERP, as reported by Computerworld. IDC commentary on ERP customisation lock-in, as reported by Formtek. Zylo 2026 SaaS Management Index, as reported by secondary sources (figures vary slightly between reports; check Zylo for the original).