Comparison · Software procurement
Buy off-the-shelf software or build a custom tool
Last updated 25 October 2026 · 2 sources listed · Reading time about 3 minutes
Short answer
Buy when the process is common across companies, a mature product covers most of it, and speed matters. Build when the process is a source of competitive difference, existing products force awkward workarounds, and you can sustain engineering ownership over years. Hidden costs on both sides, integration and customisation for bought tools, maintenance and security for built ones, usually decide the outcome.
Who this is for: An operations or technology leader weighing whether a business process should run on a commercial product or on software built in-house or by a contractor.
What to evaluate
Process uniqueness
Commodity processes such as payroll or invoicing rarely justify custom code.
How to check: List the steps that differ from standard practice and ask whether they create real advantage.
Fit to requirements
Poor fit leads to workarounds, spreadsheets and shadow tools.
How to check: Score candidate products against must-have requirements during demos with real data.
Total ownership effort
Maintenance, upgrades, security patching and support continue long after launch.
How to check: Estimate ongoing staffing needs for a built tool and vendor-managed alternatives for a bought one.
Time to value
Delay has a business cost that offsets building advantages.
How to check: Compare realistic delivery plans including integration, training and data migration.
Integration and data access
Either path must connect to existing systems and reporting.
How to check: Review available interfaces for products and plan the integration design for builds.
Vendor and key-person dependency
Both vendor failure and the departure of the one developer who understands a tool create risk.
How to check: Check escrow or export options for vendors and documentation and handover plans for builds.
Comparison
| Concern | Buy | Build |
|---|---|---|
| Speed to launch | Faster when requirements are standard | Slower, depends on team capacity |
| Customisation | Limited by product configuration | Full control of behaviour |
| Ongoing cost | Subscription and administration | Engineering, hosting and security upkeep |
| Risk concentration | Vendor viability and pricing changes | Key staff and technical debt |
| Compliance burden | Shared with vendor certifications | Entirely yours to design and evidence |
Decision worksheet
Rate up to three options against this guide’s own criteria. It runs in your browser and saves only on this device. It is a thinking aid, not a recommendation.
1. Have you checked each criterion?
0 of 6 criteria checked.
2. Compare options (0 = fails or unknown, 3 = meets it well)
| Criterion | |||
|---|---|---|---|
| Process uniqueness | |||
| Fit to requirements | |||
| Total ownership effort | |||
| Time to value | |||
| Integration and data access | |||
| Vendor and key-person dependency | |||
| Total (max 18) | 0 | 0 | 0 |
Questions to ask before you commit
- Which requirements are genuinely unique and which are preferences?
- Who will own the tool, fix defects and handle security patches after launch?
- Can a configurable product cover most needs with a small extension?
- What is our exit plan if the vendor fails or the built tool is abandoned?
- How will data move in and out, and in what formats?
- What compliance evidence will we need and who produces it?
- What is the cost of delay to the business while we build?
Typical trade-offs
Configure a product versus extend with custom code
- Upside
- Stays upgradeable and vendor-supported.
- Downside
- Heavy customisation can make upgrades painful.
Build a minimal version first versus full-featured build
- Upside
- Tests assumptions early.
- Downside
- A prototype tends to be adopted without proper engineering.
Single product versus assembled set of tools
- Upside
- Cohesive data and support.
- Downside
- May be weaker in individual areas than specialist products.
Common mistakes
- Building because current products feel expensive; compare against the real staffing cost of ownership.
- Buying without a requirements list; vendors then define the problem for you.
- Underestimating integration effort; prototype the hardest connection first.
- Ignoring security and compliance duties for homegrown tools; plan for reviews and logging from the start.
Related questions
When does custom software make sense?
It makes sense when the process itself differentiates your business, no product covers it without constant workarounds, and you can keep a stable team to maintain it. Examples include proprietary pricing logic or specialised operational workflows. Even then, assemble commodity components, such as authentication and payments, from established services rather than writing them yourself. Whatever you decide, write the reasoning down, name who is accountable for the follow-up, and revisit the choice after a realistic trial period so that early assumptions are tested against what actually happens in practice.
Why do built tools often cost more than expected?
The initial build is only part of the effort. Over years the team must patch dependencies, respond to security issues, adapt to changing requirements, handle user support and rewrite parts as platforms age. Because these costs are spread thin across time and teams, they are easy to omit from the original comparison, which then flatters the custom option.
Can I mix the two approaches?
Yes, and many organisations do. A common pattern is to buy a platform that handles the standard processes and build a small layer on top for the distinctive part, using the vendor interfaces. This keeps maintenance manageable and preserves the ability to upgrade, provided the extension uses supported mechanisms rather than modifying core product behaviour.
How do I avoid lock-in with a bought product?
Insist on data export in open formats, documented interfaces and clear exit terms in the contract. Keep integrations loosely coupled so that swapping the product means replacing connectors rather than redesigning processes. Test export early, because untested export promises tend to fail when you actually need them. Whatever you decide, write the reasoning down, name who is accountable for the follow-up, and revisit the choice after a realistic trial period so that early assumptions are tested against what actually happens in practice.
Sources and further reading
These pages were reachable when we last checked. They informed definitions and rules referred to above; they do not endorse this guide. Where rules differ by country, check the authority for your location.
- Supply chain security guidance — National Cyber Security Centre, retrieved 27 October 2026
- Cybersecurity Supply Chain Risk Management Practices — NIST, retrieved 27 October 2026
Related guides
How to choose · Software procurement
How to run a security review of a SaaS vendor
Scale the review to the data and access the vendor will have. Collect independent assurance reports, a completed security questionnaire and documentation on encryption, access control, incident response and subprocessors, then verify claims rather than accepting them. Focus on what the vendor does with your data, how it detects and reports incidents, and how you can exit with your data intact.
Requirements · Software procurement
SaaS contract terms to review and negotiate
Beyond price, the clauses that most affect outcomes are renewal and termination mechanics, data ownership and return, service levels and remedies, liability caps, security and breach commitments, and rules on price changes. Contract law varies by jurisdiction, so treat this as a checklist for conversation with counsel, not legal advice. Negotiate before signature, because leverage drops once data is in the system.
Problems & fixes · Software procurement
Why software implementations fail or run late and how to prevent it
Implementations falter less from technology than from unclear scope, poor data, weak ownership and underestimated change effort. Prevent trouble by defining outcomes and boundaries up front, cleaning data before migration, naming a business owner with decision authority, and planning training and adoption as seriously as configuration. When a project slips, reset scope and sequence rather than adding pressure.
Comparison · ERP
Single-suite ERP versus a best-of-breed application stack
A single-suite ERP offers one data model, one vendor relationship and consistent reporting, but individual modules may be shallower. A best-of-breed stack gives deeper functions in each area at the price of integration work, divided accountability and reconciliation effort. The right balance depends on how unusual your processes are in the areas that create competitive advantage and how much integration capability you can sustain.
Comparison · Artificial intelligence
Build versus buy for enterprise AI capabilities
Buy where the capability is common and vendors can ship, support and secure it better than you can. Build where the workflow, data or user experience is a source of advantage or where packaged tools cannot meet control needs. Most firms end with a mix, so the key decision is a rule for which category each request belongs to.
Comparison · HR and payroll software
PEO or outsourced payroll versus in-house payroll software
In-house payroll software gives you control and often a lower unit cost but leaves compliance responsibility and filing oversight with you. Outsourced payroll services run calculations and filings for you, and a professional employer organization goes further by sharing certain employment responsibilities through a co-employment arrangement. The distinction matters legally and varies by country, so confirm what responsibilities actually transfer and which remain yours.
Problems & fixes · Project management
Why project management tool adoption fails and how to recover
Adoption fails when the tool adds work without removing any, when structures are inconsistent between teams, when leaders keep asking for status elsewhere, and when no one owns the workspace. Recover by simplifying the structure, removing duplicate reporting, running meetings from the tool, providing templates, and measuring whether the information in it is current rather than counting logins.