The short answer
There is no default right answer, and anyone who always recommends the same option (always build, always buy) is telling you about their business model rather than yours.
- Buy when the process is common across organizations (accounting, payroll, CRM, help desk) and a product supports it with configuration rather than code.
- Integrate when the systems you already have do their jobs well, but information has to be re-keyed or reconciled between them.
- Build when the process is what makes your organization different, the rules are specific to you, and no product fits without changes so deep that you would effectively be building anyway.
Decide per capability, not for the whole organization. A common and sensible result is: buy the ERP and CRM, integrate them, and build one small application for the part of the work that is truly yours.
What each option really involves
| Buy | Integrate | Build | |
|---|---|---|---|
| You get | A product used by many organizations, with its own roadmap | Existing systems that share data automatically | Software shaped around your process |
| Time to first value | Usually shortest, if the fit is good | Depends on API access and data quality | Usually longest |
| Ongoing costs | Subscriptions or hosting, administration, upgrades | Monitoring, fixing breaks when vendors change APIs | Hosting, maintenance, security updates, developers |
| You control | Configuration, not the roadmap | The flow of data between systems | Everything, including the maintenance burden |
| Main risk | Bending your process to the product, or paying for customization that complicates upgrades | Fragile connections, unclear source of truth | Scope growth, key-person dependency, underfunded maintenance |
A fourth path sits between buying and building: extending a platform. Open-source business systems such as ERPNext can be configured and extended with custom fields, workflows and applications. This can give a close fit without starting from nothing, but every customization still has to be maintained through upgrades.
Questions that usually decide it
Is the process a differentiator or a utility? If customers would never notice the difference, it is probably a utility. Buy it.
How often will the rules change, and who changes them? Products handle common changes (new tax rates, new users) well. Frequent, organization-specific rule changes favor building or extending.
Do the systems you already own have usable APIs? Integration depends on it. Vendors document their interfaces, for example NetSuite's REST web services, and many publish request limits that vary by plan. If API access requires a more expensive edition, include that in the comparison.
Who will maintain it in three years? A custom application needs developers, security updates and hosting for its whole life. If nobody is funded to do that, building is risky however good the first version is.
Can you get your data out? For every option, confirm you can export your data in a usable format if you change direction later.
A fair decision worksheet
This worksheet scores each option against the same criteria. Weight each criterion (1 to 5) by how much it matters to you, then score each option (1 to 5). Multiply and add. Fill it in with the people who will use and support the result, and write down the reason for each score.
Capability being decided: ______________________
| Criterion | Weight (1 to 5) | Buy score | Integrate score | Build score | Evidence or reason |
|---|---|---|---|---|---|
| Fit with the process as it should work | |||||
| Time until people can use it | |||||
| Five-year cost of ownership (estimates in US dollars (USD)) | |||||
| Effort to maintain and upgrade | |||||
| Control over changes and priorities | |||||
| Data ownership and ability to exit | |||||
| Security and privacy obligations met | |||||
| Skills available internally or through a provider | |||||
| Dependency on a single vendor or person | |||||
| Weighted total |
- Each score has a written reason, not just a number.
- Cost estimates cover at least five years: licenses or hosting, implementation, integration, training, support and eventual replacement.
- Someone who will maintain the result took part in scoring.
- The "buy" column was scored against a specific product, after a demonstration of your own scenarios.
- The "build" column includes ongoing maintenance, not only the first release.
Treat the total as a way to structure the discussion, not as the decision. If two options are close, prefer the one that is easier to reverse.
Signals that you are drifting into the wrong option
- Buying, but the list of customizations keeps growing and each upgrade needs rework. You may be building inside someone else's product.
- Integrating, but the same record is edited in three systems and nobody knows which is right. Settle the source of truth first; see the integration readiness checklist.
- Building, but most of the requirements are standard features of products you have not evaluated. Look at what exists before writing code.
Limitations
This framework assumes you can describe the process clearly. If you cannot, the first step is process mapping, not a technology choice. It also does not replace a proper product evaluation; for ERP decisions, use the ERP evaluation checklist. And whichever path you choose, the provider matters: see how to choose a technology implementation provider.
Next step
If building or extending looks right for part of your work, see custom software development. If the answer is to connect what you already have, see business system integration. We can also help you complete the worksheet with your team before any option is chosen.
Sources and further reading
Product capabilities and guidance change. These are the primary sources this article relies on, checked on the review date above.
- What is ERPNext?, ERPNext documentation (Frappe)
- API usage guidelines and limits, HubSpot Developers
- Overview of SuiteTalk REST Web Services, Oracle NetSuite Help Center
This article is general information, not legal, accounting or security advice for your specific situation. Examples are hypothetical unless stated otherwise.