In short
Buy software when the capability is standard, a mature product fits the workflow, and vendor dependence is acceptable. Build when the workflow creates strategic advantage, requirements are genuinely unusual, or external constraints would distort the operation. Compare total ownership, integration, change, data, and exit costs—not licence price versus build estimate.
Start with strategic importance and uniqueness
Plot the capability on two axes:
| Standard workflow | Distinct workflow | |
|---|---|---|
| Low strategic value | Buy or simplify | Adapt carefully; avoid bespoke vanity |
| High strategic value | Buy, integrate, differentiate elsewhere | Strong candidate to build |
Payroll, email, and ordinary ticketing are rarely differentiators. A proprietary pricing model, fulfilment system, or customer workflow may be.
Buy when
- the problem is mature and widely shared;
- vendor workflows are acceptable;
- speed matters;
- internal engineering capacity is limited;
- compliance or infrastructure benefit from a specialist provider;
- integration and export are sufficient;
- switching cost is understood.
Buying transfers some development and operating work. It also accepts roadmap, pricing, platform, and data constraints.
Build when
- the workflow is central to advantage;
- available tools require damaging workarounds;
- proprietary data or logic creates value;
- integration depth is unusual;
- control, performance, or user experience materially affects the outcome;
- the organisation can fund ongoing product ownership.
Custom software is not a one-time purchase. It creates responsibility for roadmap, support, security, infrastructure, data, and change.
Count total cost
Buy
Licence, users, usage, implementation, configuration, migration, integrations, training, specialist administrators, add-ons, contract increases, and exit.
Build
Discovery, design, engineering, infrastructure, testing, monitoring, security, support, maintenance, documentation, staffing, opportunity cost, and replacement.
Compare three- to five-year scenarios with uncertainty, not one confident total.
Test fit before committing
Use representative workflows and data in a trial. Ask real operators to complete the difficult task, not the vendor's demo path.
Check:
- edge cases and permissions;
- API and bulk operations;
- reporting and audit;
- data export;
- regional and language needs;
- failure behaviour;
- vendor roadmap and support;
- contract and price-change terms.
Consider hybrid boundaries
Build the differentiating workflow while buying identity, payments, messaging, search, hosting, or other mature capabilities. Avoid customising purchased software until it becomes an undocumented private fork.
Common questions
Is buying software always cheaper?
No. It usually reduces initial build cost, while licences, integration, administration, constraints, and switching can make long-term ownership expensive.
When is custom software justified?
When a strategically important workflow is genuinely distinct and the value of control exceeds ongoing ownership cost.
How should vendor lock-in be evaluated?
Test data export, API completeness, contract termination, migration assistance, proprietary workflows, identity, attachments, and the time needed to operate elsewhere.
Can we buy first and build later?
Yes. Preserve clean data, document workflow, avoid excessive platform-specific customization, and treat the purchased tool as a learning stage.
Who should make the decision?
Business owners, operators, finance, product, engineering, security, and data owners should contribute, with one accountable decision-maker.
