The build-versus-buy decision is rarely a choice between a perfect product and a perfect custom system. A subscription product brings its own workflow, roadmap and constraints. Custom software brings discovery, delivery and maintenance responsibilities. The useful question is which set of compromises the organisation can operate responsibly.
Describe the work before comparing products
Choose one real process and map it from start to finish. Record the people involved, information they receive, decisions they make, exceptions they handle and systems they update. Include the awkward cases; they are often where a standard product stops fitting.
Separate requirements into three groups:
- Essential: without this, the process cannot operate safely or legally.
- Valuable: this saves meaningful time, reduces errors or improves the customer experience.
- Preference: useful or familiar, but the team could adopt another method.
If every request is essential, the organisation has not made the trade-offs needed for either route.
When buying is usually the stronger option
Buy or configure an established product when the workflow is common, the market already serves it well and the business can adopt the product’s process without losing an important advantage. Payroll, basic accounting and standard support ticketing often belong in this category because mature products also carry a large burden of updates and compliance work.
A product is still an implementation project. Data must be cleaned, permissions decided, integrations configured, staff trained and old processes retired. Include this work when comparing cost and timing.
When building deserves investigation
Custom development may be justified when the workflow is central to how the business delivers value, standard products create repeated workarounds, or several systems must be coordinated in a way that products cannot support reliably.
“Our process is unique” is not enough. Quantify the consequence of the mismatch: hours of duplicate entry, missed handoffs, preventable errors, licence cost for unused modules, or customers unable to complete an important task. That evidence helps define the smallest custom capability worth building.
Score both options against the same questions
Use a score from one to five and attach a short explanation to each answer:
- Workflow fit: how much essential work is supported without manual workarounds?
- Implementation: what data, configuration, training and process change are required?
- Integration: are documented APIs available, and who supports them when they change?
- Permissions and audit: can access, approvals and activity history match the risk?
- Data portability: can the organisation export complete, usable records?
- Reliability: what availability, backup, recovery and support arrangements exist?
- Roadmap control: who decides when a feature changes or disappears?
- Internal capability: who will own configuration, support and improvement?
Weight the questions before scoring. A polished interface should not outweigh data export or audit history when those are operational requirements.
Compare total cost over a useful period
For a product, include licences, usage charges, implementation, migration, integrations, premium support, training and the staff time spent on workarounds. Model how the bill changes when users, transactions or storage increase.
For custom software, include discovery, design, development, testing, hosting, monitoring, security updates, support, documentation and future platform changes. Also include the time of staff who must explain the process and test releases.
Use more than one scenario. A base case, growth case and exit case reveal whether an option becomes difficult when usage rises or when the organisation needs to leave.
Consider a configured middle path
Many decisions are not purely buy or build. A standard CRM can remain the system of record while a small custom portal handles a specialised customer journey. An automation layer can remove duplicate entry without replacing the accounting platform. This approach works only when ownership and failure handling are clear.
Do not create custom code merely to avoid changing a poor process. Remove unnecessary approvals, fields and reports first. Software should support a clearer operation, not preserve every historical workaround.
Run a proof before committing
Use representative data and one end-to-end workflow. For a purchased product, configure the difficult permissions and integration—not only the vendor’s ideal demonstration. For a custom option, prototype the highest-risk assumption before building the complete interface.
Define the decision date, owner and evidence required. Record why the rejected option was rejected so the organisation can revisit the choice when costs, scale or products change.
Sources and further reading
- GOV.UK Service Standard: choose the right tools and technology — includes the need to justify what technology to build and what to buy.
- UK Government Technology Code of Practice — lifecycle criteria for designing, building and buying technology.
If the answer is still unclear, Xapner’s custom software and CRM service can begin with a bounded discovery exercise rather than a commitment to a full build.