Custom software
vs off-the-shelf.
Compare fit, speed, control, integration, ownership and three-year cost with an eight-factor scorecard that can recommend buying, building or a hybrid of both.
Start by asking what should stay generic.
Off-the-shelf software should win when a proven product fits a standard process and gets the organisation to value quickly. Custom software should win when the process is strategically important, the product gap is structural and the business can own the result. Most established operations need both: packaged systems of record connected to deliberately built workflows.
Standard need, strong product fit
Use the vendor’s investment, support and established patterns. Test the critical scenarios and exit terms before adapting the operation.
Good products, expensive gaps
Keep dependable core software and build accountable connections or the missing operational layer around it.
Distinctive workflow, justified ownership
Encode the part of the operation that creates advantage, control or capacity—and fund its continuing lifecycle.
Custom vs off-the-shelf software.
Scroll horizontally to compare all three columns →
| Factor | Off-the-shelf software | Custom software |
|---|---|---|
| First value | Usually faster once selected and configured | Phased delivery; useful release takes design and build |
| Initial cost | Licence, implementation, configuration and migration | Discovery, design, delivery, migration and release |
| Process fit | Designed for a market; local exceptions use configuration or workarounds | Designed around the chosen workflow and its exceptions |
| Integration | Strong where supported connectors fit; vendor boundaries elsewhere | Can own unusual joins, data flow and failure handling |
| Change | Depends on configuration and the vendor roadmap | Roadmap is controlled by the organisation |
| Ownership | Vendor owns product direction; contract governs access and exit | Organisation owns the asset but must operate and maintain it |
| Assurance | Established controls may reduce effort if they fit the requirement | Controls and evidence can be specific, but must be designed and proven |
| Exit risk | Migration, data export, contract and replacement risk | Knowledge, maintainability, documentation and team continuity risk |
Build vs buy software scorecard.
Score the capability—not the whole company. Ask operations, finance, security and technology to score independently, then investigate the disagreements. A recent structured decision-support study similarly argues that explicit factors make build-versus-buy reasoning more transparent and auditable. Read the research paper.
Use evidence from operations, finance, security and technology. A neutral score is not a recommendation.
A hybrid approach is most likely
Buy the commodity capability, then integrate or build the missing workflow. Decide module by module instead of forcing one answer across the whole operation.
This scorecard structures a conversation; it does not compare actual vendors, prove feasibility or calculate total cost of ownership. Record the evidence behind every score.
Do not build what the market already solves well.
The process is genuinely standard
Payroll, accounting, collaboration, commodity CRM and identity often benefit from mature rules, integrations, support and continuing vendor investment.
A real product passes the critical scenarios
Not a polished demo: representative records, permissions, exceptions, reporting, import, export and integration work acceptably without invented future features.
Speed matters more than differentiation
A packaged product can create value now while the organisation learns what is genuinely distinctive instead of encoding an immature process.
The ownership burden would be neglected
If nobody will own roadmap, security, operation and change, buying a supported product is safer than creating an orphaned internal system.
The gap must matter more than preference.
The workflow creates advantage
Pricing, allocation, picking, planning, service or decision logic has a measurable effect that generic products flatten.
The integration is the product
Several acceptable systems must behave as one operation, with clear sources of truth and accountable failure handling.
Control has economic value
Roadmap speed, data ownership, auditability or the ability to respond without a vendor materially changes risk or opportunity.
The organisation can own the lifecycle
A named business owner, operating budget, support path and change process exist beyond the initial project.
Decide module by module.
“Build or buy” becomes misleading when applied to an entire operation. A wholesaler might buy finance and CRM, retain an existing order system, integrate product and customer records, then build mobile picking and route planning because those workflows determine service and margin. Use ORBN’s API and systems integration scorecard to test whether one of those connections is ready to scope.
Buy systems of record
Use established products for commodity records and controls where their model fits.
Name each source of truth
Agree which system owns customer, product, stock, order, delivery and invoice data.
Build the differentiating workflow
Keep custom scope around the operational decision, interface or queue that creates value.
Own the joins
Document monitoring, retries, reconciliation and the person accountable when a connection fails.
Three-year total cost, not day-one price.
Licence is only the first line
Include implementation, configuration, add-ons, users, usage, integration, internal administration, manual workarounds, contract increases, migration and exit.
Build is not the final line
Include discovery, delivery, migration, cloud, monitoring, security, support, product change, knowledge continuity and eventual replacement.
Replace the feature checklist with a real scenario.
Choose one representative case
Use a real order, customer, product, approval or service request with realistic volume and history.
Include the awkward exception
Add the substitution, reversal, late change, permission boundary or failed integration that creates manual work today.
Follow the data end to end
Show where every record originates, changes, reconciles, exports and remains accessible after contract exit.
Price the missing work
Separate configuration, customisation, third-party tools, integration and permanent manual steps from the core licence.
Repeat for the custom option
Prototype the riskiest connection or rule and test it with users before treating a custom estimate as certain.
Crowbond kept the core and built the gap.
Crowbond Foodservice had an existing order system and did not need to rebuild it. A packaged route-planning product had been trialled at £4,500 per month, but poor integration left manual work. ORBN built the missing optimisation workflow around the system already in place.
Integrate and build selectively
Retain the order record, automate geocoding and optimisation, preserve human override and reuse existing authentication.
Eight hours to under 20 minutes
Planning for more than 200 daily orders fell to a reviewable step, with over £36,000 reported annual savings.
Custom vs off-the-shelf, explained.
What is the difference between custom and off-the-shelf software?
Off-the-shelf software is a product built for a market and licensed to many customers. Custom software is designed for a defined organisation or workflow. Packaged software usually provides faster access to broad, proven capability; custom software provides greater fit and control but requires investment and ongoing ownership.
When is off-the-shelf software the better choice?
Buy when the process is common, credible products fit the critical scenarios, first value is urgent and the vendor's roadmap, data model and operating terms are acceptable. Accounting, payroll, commodity CRM and collaboration are often poor candidates for reinvention.
When does custom software make sense?
Build when a distinctive workflow affects margin, capacity, service or assurance; packaged products leave structural gaps; and the organisation can own the resulting product over time. A bounded integration or workflow is often a better first build than replacing an entire platform.
Can a business combine packaged and custom software?
Yes. A hybrid approach is common: retain packaged finance, CRM, identity or ERP capability, then integrate it with custom orchestration, operational workflows or customer experiences. The important decision is which system owns each record and who owns each connection.
Is custom software cheaper than SaaS?
Not necessarily. Custom software normally has a higher initial delivery cost and a continuing operating cost. It can become economically stronger when per-user fees, add-ons, manual workarounds, integration and delayed change dominate the multi-year cost of a package. Compare like-for-like scope over an agreed period.
Does a high score mean we should build?
No. The scorecard only makes decision factors visible. A build-leaning result still needs technical feasibility, a value baseline, ownership capacity and a bounded first release. A real vendor evaluation may also reveal a product that changes the scores.
Buy, integrate or build.
With the evidence visible.
Bring one workflow and the products already considered. We will help map the critical scenarios, the source-of-truth boundaries and the smallest experiment that changes the decision from opinion to evidence.