Overview
One of the most consequential technology decisions an organisation makes is whether to build custom software or buy an existing commercial solution. Get it wrong in the buy direction and you spend years working around a system that does not fit your processes, paying for features you do not need, and waiting for a vendor's product roadmap to deliver capabilities your business requires now. Get it wrong in the build direction and you consume development resources building infrastructure that commercial solutions would have provided faster and cheaper, creating maintenance obligations for software that is not a source of competitive advantage.
The correct answer depends on factors that are specific to each organisation and each use case — the degree of fit between available commercial solutions and the organisation's actual requirements, the internal capability to build and maintain custom software, the strategic importance of the functionality, the total cost of ownership over a realistic time horizon, and the risk profile of each approach. A well-structured build vs buy evaluation examines these factors systematically and produces a defensible recommendation rather than a preference driven by familiarity with one approach or the other.
The evaluation is distinct from a simple market survey of available commercial products. It requires understanding what the organisation actually needs — not the feature list from the initial requirements gathering, but the non-negotiable requirements, the important-but-flexible requirements, and the nice-to-haves that should not drive the decision. It requires evaluating commercial options honestly, including the requirements they genuinely cannot meet, the integration effort they require, and the ongoing cost and dependency they create. And it requires a realistic assessment of what building would actually involve — the development time, the ongoing maintenance, the infrastructure cost, and the opportunity cost of the development resources.
We conduct build vs buy evaluations for organisations facing significant software investment decisions — the ERP replacement, the custom trading system, the new customer portal, the internal tool that has outgrown its current platform, the integration layer that might be better served by an existing middleware product.
What a Build vs Buy Evaluation Covers
Requirements clarification. The foundation of a valid build vs buy evaluation is an accurate understanding of what the software needs to do — not a feature wishlist, but a structured hierarchy of requirements.
Non-negotiable requirements: the capabilities that the solution must have, without which it cannot serve its purpose. These are the requirements that commercial products must meet to be considered, and the requirements that a custom build must deliver at minimum to be viable. The discipline of separating genuine non-negotiables from habitual preferences — the requirement that feels non-negotiable because that is how the current system works, but that could be accommodated differently.
Important requirements: the capabilities that strongly influence which option is chosen but where alternatives exist. The requirement that a commercial product almost meets — the workaround that exists but adds friction, the configuration option that addresses the requirement partially, the vendor roadmap item that would address it in 12 months.
Operational and integration requirements: the technical requirements that are often underweighted in initial requirements gathering — the systems the new solution must integrate with, the data volumes it must handle, the security and compliance requirements it must satisfy, the hosting environment constraints, the SLA requirements. The integration requirements that are often more costly to satisfy in a commercial product than the commercial product's licensing cost.
Volume and performance requirements: the transaction volumes, user counts, data volumes, and response time requirements that determine whether a commercial product's standard tier is adequate or whether custom architecture is needed to meet performance requirements that commercial products satisfy only at premium pricing.
Commercial market analysis. The structured evaluation of available commercial products against the requirements.
Market mapping: the identification of commercial products that address the use case — the full landscape of options, not just the well-known names. The niche product that serves the specific vertical more precisely than the general-purpose platform. The newer entrant that better addresses modern requirements than the established market leader. The international product not commonly used in the local market but well-suited to the requirements.
Fit assessment: the honest evaluation of how well each commercial product meets the non-negotiable and important requirements. Not the marketing literature assessment — the technical evaluation that tests the claimed capabilities against the specific requirements. The requirement that the vendor claims is met through configuration but actually requires significant professional services engagement. The integration the vendor describes as standard that actually requires custom development.
Total cost of ownership: the full cost of the commercial option over a realistic time horizon — typically five years. The licensing cost (per-user, per-transaction, or flat fee and how it scales with growth), the implementation cost (professional services, integration development, data migration, training), the ongoing support and maintenance cost, the infrastructure cost for on-premises options, and the cost of the internal resource required to administer and maintain the system. The TCO comparison that reveals whether the apparently cheaper commercial option is actually more expensive than it appears when all costs are accounted for.
Vendor risk assessment: the evaluation of the commercial vendor as a long-term partner. The vendor's financial stability, the product's position in the vendor's portfolio (core product versus peripheral offering), the customer base size and concentration, the support quality, the upgrade path for future versions, and the exit strategy if the relationship needs to end. The vendor lock-in that makes replacing the solution expensive if the vendor is acquired, discontinues the product, or raises prices significantly.
Custom build assessment. The realistic evaluation of what building a custom solution would involve.
Build scope definition: the specific functionality that would need to be built — not the complete feature wishlist, but the minimum viable scope that addresses the non-negotiable and important requirements. The distinction between the core functionality that must be built and the surrounding functionality that could be deferred, bought as a separate component, or accepted as a limitation initially.
Development effort estimation: the realistic development time for the defined scope — accounting for the complexity of the requirements, the need for testing and quality assurance, the integration work with existing systems, and the realistic productivity of the available development team. The estimation that includes the entire development lifecycle, not just the initial build — the iterations that address requirements that turn out to be more complex than initially understood, the integration work that takes longer than expected, the testing that uncovers issues requiring rework.
Ongoing maintenance cost: the ongoing investment required to keep a custom-built system operational, secure, and current — the dependency updates that address security vulnerabilities, the compatibility updates when connected systems change their APIs, the bug fixes for issues that emerge in production, the feature enhancements that business requirements will inevitably generate. The maintenance cost that is often underestimated in initial build vs buy analysis and that accumulates over years of operation.
Infrastructure and operational cost: the hosting, monitoring, backup, and operational infrastructure cost for a custom-built system — the cost that commercial SaaS products include in their pricing but that custom-built systems require explicitly.
Internal capability requirement: the honest assessment of whether the organisation has the development capability to build and maintain the system correctly. The build decision that implicitly depends on hiring developers who do not currently exist in the organisation. The custom system that will be built by an external development partner and then maintained by an internal team that has not yet been assembled.
Total cost of ownership comparison. The side-by-side cost comparison over a consistent time horizon.
Year-one cost comparison: the initial investment for each option — the licensing and implementation cost for the commercial option, the development cost for the custom build option. The year-one cost that often favours commercial products (immediate availability, no development cost) even when the custom build is the better long-term choice.
Five-year cost comparison: the total cost over five years, accounting for the commercial product's licence fees, the custom build's ongoing maintenance cost, the expected growth in user counts and transaction volumes, and the enhancement cost for additional functionality that business requirements will generate. The five-year horizon that often changes the relative cost position significantly compared to year-one.
Cost sensitivity analysis: the factors that most affect the cost comparison — the licensing model that makes the commercial product expensive at scale, the maintenance estimate that drives the custom build cost, the integration complexity that adds significant cost to the commercial option. The sensitivity analysis that identifies which cost assumptions have the biggest effect on the decision.
Strategic and qualitative factors. The factors that affect the build vs buy decision but do not fit neatly into a cost comparison.
Competitive differentiation: whether the functionality provides competitive advantage that justifies custom development. The operational process that is a source of competitive advantage should not be replicated with a commercial product available to competitors. The generic administrative function that is not a source of competitive advantage is a candidate for a commercial product.
Flexibility and control: the degree to which the organisation needs to control how the functionality evolves. The commercial product's roadmap dependency — the organisation waits for the vendor to add the capability it needs. The custom build's flexibility — the organisation can add exactly the functionality it needs when it needs it, at the cost of development investment.
Speed to value: the time from decision to operational use. The commercial product that can be configured and deployed in weeks. The custom build that requires months of development before anything is operational. The speed-to-value factor that can make the commercial option preferable even when custom build is the better long-term choice, if the business need is urgent.
Risk profile: the risk of each option. The commercial product risk — implementation complexity underestimated, vendor discontinues the product, the fit turns out to be worse in practice than in evaluation. The custom build risk — development takes longer and costs more than estimated, the team that built it is no longer available to maintain it, the technical debt accumulates in ways that become expensive to address. The risk profile that matches the organisation's risk tolerance and capacity to manage each type of risk.
Hybrid options. The build vs buy framing that misses a third option — building on top of a commercial platform or combining commercial products with custom development.
Commercial platform with custom extensions: the commercial ERP with custom modules for the organisation-specific workflows that the core product does not support. The CRM with custom integrations for the operational systems it does not natively connect to. The commercial platform that covers 80% of requirements and custom development that addresses the remaining 20%.
Best-of-breed with integration: the multiple specialised commercial products, each best-in-class for its specific function, integrated through custom middleware. The alternative to the single comprehensive platform that addresses all requirements adequately but none exceptionally.
Open-source base with custom development: the open-source platform that provides the infrastructure layer while custom development adds the organisation-specific functionality on top. The Odoo ERP, the Moodle LMS, the WooCommerce e-commerce platform — open-source bases that can be customised more freely than proprietary commercial products.
Evaluation Output
A build vs buy evaluation produces a structured recommendation document covering:
Requirements summary. The clarified and prioritised requirements — the non-negotiables, the important requirements, the nice-to-haves, and the requirements that were initially assumed but are actually flexible.
Commercial options assessment. The evaluated commercial products, their fit against the requirements, their TCO, their vendor risk profile, and the recommendation on each.
Build assessment. The scope of a custom build that would meet the requirements, the development effort and cost estimate, the ongoing maintenance cost, and the team and infrastructure requirements.
Recommendation. The recommended approach — build, buy a specific commercial product, or a hybrid — with the rationale that explains why the recommendation reflects the organisation's specific situation better than the alternatives.
Risk factors. The key risks in the recommended approach and the mitigations that reduce them.
When the Answer Is Not Obvious
Some build vs buy decisions are straightforward — the requirement that no commercial product addresses at all clearly points to custom build; the requirement that is perfectly served by an established commercial product clearly points to buy. The value of a structured evaluation is greatest when the answer is not obvious — when commercial products partially meet the requirements but require significant workarounds, when the cost comparison is close, when the strategic importance is high, or when the organisation has strong but potentially biased inclinations in one direction.
Independent evaluation by a party without a stake in the outcome — not a systems integrator with commercial relationships with the vendors being evaluated, not an internal team advocating for their preferred approach — produces a more reliable recommendation than evaluations where the assessor has an interest in a particular outcome.