The decision is not simply buy or build
Most organisations have at least four options: adopt an existing product, configure it, connect several products, or build a purpose-specific system. The right choice depends on how distinctive the workflow is, how much change the business expects and what it is prepared to own.
Custom software is not automatically more capable, and off-the-shelf software is not automatically more economical. Each moves cost and constraint to a different place.
Start with the business capability
Describe what the organisation needs to do without naming a product. Include the people, decisions, information, exceptions and outcome. This prevents the comparison from becoming a feature checklist copied from a vendor page.
Separate commodity needs - identity, billing, accounting or document storage, for example - from the workflow that makes the organisation distinct. Commodity capability is usually better purchased. Distinctive capability deserves closer analysis.
A decision matrix
Use the matrix as a discussion guide rather than a formula. One severe constraint can outweigh several minor advantages.
| Situation | Likely starting point | Reason |
|---|---|---|
| The process is common and can adapt | Existing product | Proven capability and faster adoption |
| Most needs fit but terminology or permissions differ | Configured product | Keeps the platform while reducing workflow friction |
| Data is fragmented across capable systems | Integration | Connects the journey without replacing everything |
| The workflow is strategically distinct | Custom software | Encodes the capability the business needs to own |
| The current system creates material risk or blocks growth | Staged replacement | Moves one bounded domain at a time |
When an existing product is the stronger choice
Choose an existing product when the process is mature, the market already solves it well and changing the workflow creates little disadvantage. The organisation benefits from vendor maintenance, an established user base and a shorter path to operation.
Evaluate the real fit before assuming a long feature list is enough. Permissions, reporting, data export, integration limits, accessibility, support and the cost of required add-ons can matter more than headline features.
When a custom system becomes reasonable
A custom build becomes more defensible when the constrained workflow is important, repeated and meaningfully different from what available products support. It may also be justified when fragmented tools create material duplication, a new digital product is the business itself, or ownership of the experience and data is strategically important.
The case should include ongoing ownership. Hosting, monitoring, security updates, support, product decisions and future releases do not disappear after launch. A build is only viable when the expected value can carry those responsibilities.
Compare total change, not just licence and build cost
A fair comparison includes implementation, migration, training, integration, workarounds, vendor constraints and the cost of changing direction later. It should also recognise uncertainty: a custom estimate before discovery and an advertised licence price before configuration are both incomplete numbers.
Model a sensible operating period and write down the assumptions. Ask what happens if user numbers grow, a critical integration changes, the vendor raises prices or the business process evolves. The purpose is not to make the spreadsheet look precise; it is to expose which unknowns could change the decision.
A hybrid path is often the best one
A focused custom layer can sit around reliable existing services. The organisation keeps commodity infrastructure while owning the workflow, interface or decision logic that creates value. This can reduce time and operational burden without forcing the business into a generic experience.
Before committing, map the current workflow, the target capability, systems of record, migration boundaries, decision rights and the smallest release that can prove the case. That brief is valuable even if the conclusion is to configure what already exists.