Most build-versus-buy discussions start too late. A vendor has already impressed the team with a polished demo, or an internal sponsor has already decided that custom software will solve everything. At that point, the exercise becomes justification rather than evaluation.
The right question is not simply whether to build vs buy enterprise software. It is which operating model—buy, configure, extend or build—will deliver the required outcomes with acceptable cost, risk and change over the system’s useful life.
My default position is straightforward: buy commodity capability, extend a proven platform when the differentiating workflow is limited, and build only where the workflow creates real strategic advantage or no viable product can meet the non-negotiable requirements. That principle is useful, but it is not enough for a board-level decision. You need evidence.
Build vs buy enterprise software: the short answer
| Option | Best fit | Main risk |
|---|---|---|
| Buy | The process is standard, mature products cover it, and rapid deployment matters. | Licence growth, process compromise, vendor dependency and difficult data exit. |
| Configure | A platform covers the process through supported settings, workflows and roles. | Configuration becomes complex and poorly governed. |
| Extend | A platform covers the stable core, while a small custom layer handles differentiation. | Custom code crosses unsupported boundaries or makes upgrades expensive. |
| Build | The workflow is genuinely differentiating, commercially important and poorly served by the market. | The business becomes the software vendor and must fund ownership, security and support. |
For many mid-market organisations, the strongest answer is not a pure build or buy. It is a controlled extension of an ERP, CRM, workflow platform or integration layer. This keeps commodity functions on a maintained foundation while preserving the workflows that make the business different.
Start with outcomes, not a feature list
A long requirements spreadsheet often creates false confidence. Two products may both tick “purchase approvals”, yet one may support only a simple manager approval while the business needs thresholds, project budgets, delegated authority, supplier risk checks and exception handling.
Define the decision around five items before looking at products:
- Business outcome: What measurable operating result must improve?
- Actors: Who performs, approves, audits and supports the process?
- Critical workflows: What happens in the normal path and in the exceptions?
- Non-functional requirements: What are the security, privacy, availability, performance, accessibility, audit and data-residency constraints?
- Exit requirement: What data, configuration and process history must remain usable if the product or supplier changes?
If your team is still debating whether the current system is genuinely broken, use the symptoms in 10 Signs Your Business Has Outgrown Spreadsheets to separate inconvenience from an operational control problem.
Apply hard gates before weighted scoring
Do not allow a high total score to hide a disqualifying weakness. A solution that cannot meet a mandatory regulatory, security or data-exit requirement should not survive because it is attractive in nine less important categories.
Set hard gates first. Typical examples include:
- required deployment region or data-sovereignty boundary;
- supported identity provider, single sign-on and role model;
- audit logs with the events and retention your control environment needs;
- recovery objectives and an evidenced business-continuity approach;
- contractual access to data exports in a usable format;
- mandatory integrations and supported APIs;
- accessibility requirements for web or mobile interfaces;
- industry-specific retention, privacy or segregation requirements;
- a support model that covers the hours and countries in which the system operates.
Security is a procurement criterion, not a technical review to schedule after selection. The Australian Signals Directorate’s guidance on choosing secure and verifiable technologies recommends assessing the product and manufacturer before purchase, including secure defaults, identity controls, auditing, encryption, supply-chain risk, connected systems, lifecycle support and contractual obligations.
Use a weighted decision matrix without pretending it is science
A scorecard helps stakeholders make trade-offs explicit. It does not produce an objective truth. Agree the weights before vendor demonstrations, score from evidence rather than sales claims, and record the assumptions behind each score.
| Decision criterion | Questions to answer |
|---|---|
| Strategic differentiation | Does this workflow materially change how the business competes, prices, fulfils or serves customers? |
| Workflow fit | Can the option execute the real process, including approvals, exceptions and reversals? |
| Time to value | How soon can a safe, adopted production release deliver value? |
| Five-year cost | What is the comparable cost across implementation, operation, change and exit? |
| Integration fit | Are APIs, events, rate limits, identity and data models suitable for the target architecture? |
| Security and privacy | Can controls be verified, monitored and maintained across the lifecycle? |
| Data control | Can data be accessed, governed, exported and deleted as required? |
| Scalability and resilience | Can the option meet realistic peak volume, availability and recovery requirements? |
| Changeability | How quickly can policies, workflows and interfaces change without creating an upgrade trap? |
| Operating capability | Does the organisation have the product ownership, engineering, support and governance capacity? |
| Vendor and concentration risk | What happens after a price change, acquisition, service decline or product retirement? |
| Exit feasibility | Can the organisation migrate data, integrations and operational knowledge without unacceptable disruption? |
Weight each criterion from 1 to 5 for importance, then score each viable option from 1 to 5 using documented evidence. Multiply weight by score and retain the explanation. The winning total is a discussion input, not an automatic approval. Hard gates, risk appetite and confidence in the evidence still control the decision.
Compare five-year total cost, not year-one price
Comparisons fail when a SaaS subscription is placed beside a custom-development quote. Those figures cover different responsibilities. Choose a common evaluation horizon—five years is often useful for core operational software—and include the costs each option transfers to the organisation.
Buy cost model
Implementation + licences + premium modules + environments + integration + data migration + vendor management + administration + training + support + expected change + exit
Build cost model
Discovery + product design + engineering + quality assurance + security assurance + cloud/platform + observability + support + product ownership + maintenance + dependency upgrades + compliance evidence + continuity cover + exit or replacement
Extend cost model
Platform implementation and licences + integration + custom extension + automated tests + upgrade validation + extension maintenance + support + exit
Use the same user volumes, transaction volumes, countries, environments, service hours and growth assumptions for every option. Separate committed costs from estimates. Run sensitivity cases for headcount growth, transaction growth, licence changes and a supplier exit. If the conclusion changes after one reasonable assumption moves, the decision is fragile and should be treated accordingly.
Do not assign a universal “maintenance percentage” to custom software or assume licence pricing remains flat. Obtain evidence from the proposed architecture, backlog, support model and supplier terms.
Test the real workflow with a proof of fit
A generic product demonstration is not evidence of fit. Run a time-boxed proof of fit using your own scenarios and representative, sanitised data. The objective is to test the riskiest assumptions before the organisation commits to licences or a major build.
I would include at least:
- one high-volume normal workflow;
- one exception with cancellation, reversal or reapproval;
- one cross-system workflow that tests identity, API behaviour and error recovery;
- a role and segregation-of-duties test;
- an audit-log and reporting test;
- a data export and re-import test;
- a realistic performance test at expected peak conditions;
- an accessibility check for the interfaces used by staff or customers;
- an upgrade or change scenario showing what happens to configuration and extensions.
Record pass, partial pass or fail, together with the workaround, owner and lifetime cost of that workaround. “Possible with customisation” is not a pass until scope, support boundaries and upgrade impact are understood.
If an ERP is one of the candidate foundations, compare platform fit separately from implementation quality. My Odoo vs NetSuite comparison explains the platform-level trade-offs, while the Odoo implementation checklist covers decisions that must be settled before configuration begins.
Security, privacy and accessibility belong in both paths
Buying software does not outsource accountability, and building software does not automatically provide control. The control model is different, but the organisation still needs evidence.
For a custom build, the delivery approach should incorporate a recognised secure-development baseline. NIST SP 800-218 describes a Secure Software Development Framework that can be integrated into different software-development lifecycles; NIST also notes that purchasers can use its common vocabulary when communicating with suppliers.
For personal information, define collection, access, retention, deletion and incident responsibilities during discovery. The Office of the Australian Information Commissioner describes privacy by design as embedding good privacy practices into technology and business design rather than adding them later. Organisations in other jurisdictions should map equivalent local obligations with qualified advisers.
For browser-based products, include accessibility acceptance criteria from the start. The W3C recommends using WCAG 2.2 to maximise the future applicability of web accessibility efforts. Do not treat an automated scan as complete accessibility assurance; important behaviours still require manual and assistive-technology testing.
Integration quality often decides the outcome
A product can fit one department and still damage the enterprise architecture. Before selection, identify the system of record for each important data object, the direction and frequency of synchronisation, failure ownership, replay behaviour, rate limits, authentication method and monitoring responsibility.
Prefer supported APIs and event mechanisms over database-level coupling. Test whether the supplier’s API exposes the same important actions available in the user interface, and confirm whether API usage is restricted by plan, volume or additional charges. For a deeper technical view, see how to integrate external systems through Odoo’s API.
In a hybrid design, keep the boundary deliberate. Stable commodity records may remain in the platform, while a separate application handles a differentiating workflow through supported interfaces. That is very different from scattering ungoverned scripts across the core system.
When buying is usually the stronger decision
- The requirement is a common business capability such as standard accounting, payroll, identity or collaboration.
- A mature product meets the hard gates and most priority workflows without invasive customisation.
- Speed matters more than owning the roadmap.
- The organisation does not want to fund ongoing product ownership and engineering capability.
- Supplier viability, security evidence, APIs, support and exit terms are acceptable.
When extending a platform is usually stronger
- A maintained platform covers the stable data model and commodity processes.
- The differentiating requirement is concentrated in a limited number of workflows.
- The platform provides supported extension points, APIs and upgrade-safe patterns.
- The custom layer can be independently tested, monitored and documented.
- The business accepts both the platform relationship and responsibility for the extension.
When a custom build may be justified
- The workflow is central to competitive advantage or a distinctive operating model.
- No viable product passes the hard gates without changing the business in unacceptable ways.
- The organisation needs control over roadmap, user experience, data model or integration behaviour.
- Expected scale or transaction economics make packaged pricing structurally unsuitable, based on validated scenarios.
- There is a credible owner, delivery team, security model, support model and multiyear funding commitment.
“We can build it” is not a business case. The build case is credible only when the organisation is prepared to operate the product after the launch team has moved on.
Contract and exit questions to settle before approval
- Who owns custom code, configuration, documentation and derived data?
- What export formats, APIs and assistance are available during transition?
- How long is data retained after termination, and how is deletion evidenced?
- What are the response, restoration and notification obligations?
- How are material product, hosting, subprocesser or pricing changes communicated?
- Which security capabilities are included, and which require a higher plan?
- What happens to custom extensions during upgrades?
- Can the organisation continue operating during a supplier dispute or outage?
- What knowledge-transfer obligations apply at handover?
These questions protect both buy and build decisions. For a custom build, the “supplier” may be an internal team, an external development partner or both, so ownership and continuity must still be explicit.
A practical decision process
- Frame the outcome. Name the operating problem, accountable owner, affected users and success measures.
- Map the workflows. Include exceptions, approvals, integrations and control requirements.
- Set hard gates. Agree security, privacy, accessibility, architecture and commercial non-negotiables.
- Shortlist all four models. Consider buy, configure, extend and build rather than forcing a binary choice.
- Model comparable cost. Use a common horizon and scenarios.
- Run proof-of-fit tests. Test the risky workflows and evidence, not presentation quality.
- Score with assumptions visible. Weight criteria before demonstrations and record confidence.
- Complete risk and contract review. Resolve ownership, support, security and exit.
- Approve a phased roadmap. Define the first production outcome, adoption plan and governance cadence.
The final decision pack should be short enough for executives to read and detailed enough for delivery teams to execute: outcome, options, hard gates, evidence, cost scenarios, risks, recommendation, assumptions and next-stage plan.
Frequently asked questions
Is buying enterprise software always cheaper than building?
No. Buying often reduces upfront delivery time and transfers product maintenance to a supplier, but the lifetime cost can include implementation, licences, premium modules, administration, integration, change and exit. Build and buy should be compared over the same horizon and operating assumptions.
What is the difference between configuration and customisation?
Configuration uses supported settings, workflows, roles and data structures provided by the product. Customisation changes or extends behaviour with code or unsupported modifications. The exact boundary depends on the platform, so confirm how each change is supported and upgraded.
What does “extend” mean in a build-versus-buy decision?
Extend means using a maintained product for the stable core while adding a controlled custom layer through supported APIs, events or extension frameworks. It can preserve differentiation without rebuilding commodity capabilities.
How long should the cost comparison cover?
Use a horizon that reflects the expected useful life and decision significance. Five years is often practical for core operational software, but the correct period depends on strategy, contract terms and likely replacement cycle. Apply the same horizon to every option.
How do we avoid vendor lock-in?
Lock-in cannot always be eliminated, but it can be understood and managed. Test exports, document integrations, prefer open and supported interfaces, clarify data and configuration ownership, negotiate transition assistance and maintain an exit plan before signing.
Can AI-assisted development change the build decision?
AI-assisted tools can accelerate parts of analysis, coding, testing and documentation, but they do not remove product ownership, architecture, security assurance, user validation, support or accountability. Evaluate their impact on specific delivery tasks rather than assuming they make a custom product cheap or low risk.
Make the decision from evidence
The best enterprise software choice is the smallest responsible solution that supports the required operating model. Sometimes that is a mature SaaS product. Sometimes it is a configured ERP. Sometimes it is a platform plus a carefully bounded extension. A full custom build should be deliberate, not the result of demo fatigue or frustration with one unsuitable vendor.
If you are deciding between packaged software, an ERP extension and a custom application, book a short discussion with me. I can help structure the discovery, proof of fit and decision pack. Any scope, timeline or commercial commitment should follow a review of your workflows, systems and constraints.
