Build, buy, or partner — why the answer is almost never what the initial analysis suggests, and how to make the decision you will not regret in thirty-six months.
There is a decision that sits at the centre of almost every significant enterprise technology initiative.
It is framed as a simple binary. Build or buy. Make or purchase. In-house or vendor.
It is not a binary. It never was. And the organisations that treat it as one are the ones paying for that mistake — in deferred migrations, in vendor contracts they cannot exit, in custom systems that the team who built them has long since left, and in strategic capabilities they outsourced to a SaaS vendor and can no longer reclaim.
According to Forrester, 67% of software project failures can be traced back to an incorrect build-versus-buy decision.
Not poor execution. Not inadequate budget. Not insufficient talent.
The wrong decision at the point of commitment.
This article is about making the right one — systematically, with full visibility of the costs and constraints that most enterprise decision-making processes do not surface until it is too late.
Why the Standard Analysis Fails
The standard enterprise analysis of build versus buy follows a predictable structure.
Finance produces a cost comparison. IT evaluates vendor capabilities against a requirements list. Procurement negotiates commercial terms. Legal reviews the contract. A decision is made.
The problem is not the process. The problem is what the process measures.
It measures the cost of acquisition. It does not adequately measure the cost of dependency.
It measures the capability at point of purchase. It does not adequately measure the capability five years after purchase, when the vendor has repositioned the product, discontinued the features the organisation depends on, or restructured the pricing model in ways that are now contractually unavoidable.
It measures the implementation cost. It does not adequately measure the exit cost — the cost of migrating away from the system when business requirements evolve, when the vendor is acquired, or when a superior alternative becomes available and the organisation cannot move to it because the migration would take two years and cost more than the system itself.
The decision that looks correct in month one can look catastrophically wrong in month thirty-seven.
The organisations that make durable technology decisions are not the ones with the most thorough RFP processes. They are the ones that have learned to ask different questions — questions about strategic control, about total cost of ownership over a realistic time horizon, about what happens when the relationship with the vendor changes in ways that were not anticipated at contract signing.
The Real Framework: Three Questions Before the Decision
Before any technology procurement or development decision is made, three questions must be answered with specificity — not directionally, but with the evidence to support a defensible position.
Question 1 — Is this a competitive differentiator or a commodity function?
This is the most consequential question in the entire framework, and it is the one most frequently answered incorrectly.
A competitive differentiator is a capability that directly enables or constitutes the organisation's strategic advantage. It is the thing the organisation does differently from its competitors that creates measurable value. The underwriting logic that prices risk in a way competitors cannot replicate. The recommendation engine that drives customer retention at a scale that generic algorithms cannot match. The workflow automation that compresses a process from fourteen days to six hours in a way that is specific to the organisation's operational model.
A commodity function is a necessary operational capability that every organisation in the sector needs to perform, and that performing better than the market average creates no particular advantage. Expense management. Document signing. Video conferencing. Payroll processing. Standard compliance reporting.
The principle is straightforward: build what differentiates, buy what does not.
Organisations with proprietary core technology achieve approximately twice the revenue growth of those relying exclusively on off-the-shelf platforms. The inverse is also true: organisations that invest significant engineering resources building custom versions of commodity capabilities are diverting talent from the differentiated work that creates actual competitive advantage.
The difficulty is that this question is frequently answered through the lens of functional requirements rather than strategic positioning. A capability can be technically complex and still be a commodity. A capability can be operationally critical and still be available from a vendor more reliably and cost-effectively than it can be built internally.
The test is not whether the capability is important. The test is whether performing it better than the market creates strategic advantage. If the answer is no, building it is an expensive mistake — regardless of how unique the requirements appear.
Question 2 — What is the true five-year total cost of ownership?
Every technology decision involves a comparison of costs. Most of them compare the wrong costs.
The initial acquisition cost — whether the development investment to build or the license fees to buy — is the smallest component of total cost of ownership over a realistic time horizon. It is also the most visible, the most readily quantifiable, and therefore the figure that dominates the analysis.
The costs that determine whether a technology decision creates or destroys value over five years are the ones that appear after the contract is signed.
For bought solutions:
Hidden integration costs. The average enterprise now runs approximately 900 applications, and integrating a new system into an existing landscape is rarely the plug-and-play proposition vendor demonstrations suggest. Integration complexity routinely adds 150 to 200 percent to the sticker price in implementation costs alone.
Renewal inflation. Enterprise SaaS vendors increased prices at rates significantly above inflation across 2022 and 2023, and the structural conditions that enabled those increases — high switching costs, deeply embedded workflows, contractual constraints on exit — have not changed.
The price agreed at contract signing is rarely the price paid at the first renewal.
Customisation debt. Off-the-shelf software that does not precisely fit enterprise workflows gets customised. Those customisations create technical debt that accumulates against every subsequent version upgrade — making the system progressively harder to maintain and the vendor progressively harder to leave.
Vendor lock-in. When an organisation's workflows, data structures, and operational processes are built around a vendor's proprietary architecture, the theoretical ability to switch becomes practically unavailable. The switching cost — in migration complexity, in productivity disruption, in replicated integrations — exceeds the marginal benefit of the alternative. The vendor knows this. Renewal negotiations reflect it.
For built solutions:
Ongoing maintenance is the most systematically underestimated cost in custom development. Applications in active production use require between 40 and 80 hours of engineering support per month to sustain. New features, dependency updates, security patches, performance optimisation, compliance changes — these costs are perpetual, and they compound as the codebase matures.
Knowledge concentration. Custom systems accumulate institutional knowledge in the engineers who built them. When those engineers leave — and in the current market, they will — the cost of rebuilding that knowledge is significant, and the period of elevated operational risk during the transition is real.
The honest five-year TCO calculation includes all of these costs. Most enterprise procurement analyses include none of them. The organisation that makes its decision on the basis of year-one acquisition cost will consistently discover that the true cost of the decision reveals itself in years three and four.
Question 3 — What does control over this capability require in three years?
Technology decisions have a time dimension that is rarely modelled explicitly.
The capability the organisation needs today is not necessarily the capability it will need in thirty-six months. The vendor that serves current requirements adequately may not be positioned to serve the requirements that emerge as the business evolves, as the competitive landscape shifts, or as the regulatory environment changes.
The question of control is therefore not just about the current state. It is about the organisation's ability to evolve the capability on its own timeline, according to its own priorities, without requiring vendor permission or waiting for a product roadmap that was designed for a different customer's needs.
This question is particularly acute for AI and data capabilities in the current environment.
Organisations that are outsourcing core AI capabilities — training pipelines, inference infrastructure, proprietary model development — to SaaS vendors are making a bet that the vendor's trajectory will continue to align with their strategic requirements. Some of those bets will pay off. Others will result in the organisation discovering, at precisely the moment competitive pressure is highest, that the capability it depends on is controlled by a vendor whose commercial interests have diverged from its own.
The principle: capabilities that will become more strategically important over your planning horizon deserve a higher degree of ownership than their current importance alone would suggest.
The Third Option That Most Frameworks Ignore
The conventional framing offers two options. Build or buy.
There is a third option that consistently outperforms both for a specific category of enterprise requirements — and that most decision frameworks do not adequately account for.
Partner: acquiring a capability through a dedicated external engineering relationship that provides the ownership benefits of building without the fixed overhead of maintaining a permanent internal team.
The partnership model is not staff augmentation in the traditional sense — where the organisation acquires development capacity and directs it toward a predetermined specification. It is a collaborative engineering relationship where external expertise contributes to architectural decisions, technology selection, and delivery approach, while the organisation retains ownership of the outcome.
For enterprise requirements that are differentiated but not suited to permanent internal capability, the partnership model resolves the fundamental tension in the build-versus-buy decision.
It provides:
Strategic control without fixed overhead. The organisation owns the intellectual property, the architectural decisions, and the operational knowledge. It is not dependent on a vendor's product roadmap. But it is also not carrying the full cost of maintaining an in-house engineering team that may not be fully utilised once the initial capability is established.
Architectural expertise that is not available internally. Building production-grade agentic AI systems, cloud-native platforms, or complex enterprise integrations requires engineering expertise that most organisations do not maintain permanently at depth. A partnership relationship brings that expertise to bear without requiring the organisation to hire, retain, and continuously develop it internally.
Velocity that internal teams cannot match. An engineering partner that has solved the same class of problem across multiple enterprise engagements brings patterns, tooling, and architectural intuition that compress timelines dramatically compared to an internal team approaching the problem for the first time.
Managed transition to internal ownership. The optimal partnership engagement is designed to transfer knowledge — architectural documentation, operational runbooks, engineering training — such that the organisation can operate and extend the capability independently once the initial build is complete.
The partnership model is not universally appropriate. For commodity capabilities, buy. For the most strategic, highest-frequency capabilities where deep internal ownership is genuinely warranted, build. For differentiated capabilities that require architectural expertise, speed to delivery, or a scale of investment that internal teams cannot sustain — partner.
The failure to include this option in the analysis is one of the most consistent gaps in enterprise technology decision-making.
The Five Questions Most CTOs Skip
Beyond the three primary questions above, five secondary questions regularly determine whether a technology decision that looks correct on paper holds up under operational reality.
What is the realistic exit strategy?
Every technology decision should be evaluated against the assumption that the organisation will eventually need to change it. Not because the vendor will fail, but because requirements evolve, superior alternatives emerge, and the organisation's needs in five years will not be identical to its needs today. Decisions that do not have a credible exit path are decisions that transfer strategic control to a third party — and that transfer is almost never reflected in the initial cost analysis.
What regulatory obligations does this capability trigger?
In regulated industries, technology decisions carry compliance implications that are not always visible at point of purchase. Data residency requirements. Model explainability obligations. Audit trail mandates. Third-party risk management frameworks. A capability that appears commercially attractive becomes significantly more expensive when its regulatory footprint is fully costed.
Who owns the data this system generates?
In the AI era, the data generated by a system's operation — interaction logs, usage patterns, feedback signals — may be more strategically valuable than the system itself. Vendor contracts that grant the vendor rights to use operational data for model training or product development are transferring an asset that the organisation may not have priced into the decision. Data ownership terms deserve explicit negotiation and explicit analysis.
How does this decision affect adjacent capabilities?
Technology decisions rarely exist in isolation. The architecture selected for one capability constrains or enables the architecture available for adjacent capabilities. An organisation that standardises on a particular vendor's ecosystem for one function may find that the apparent cost savings are offset by the constraints that standardisation imposes on future decisions elsewhere in the stack.
What is the decision's sensitivity to key-person dependency?
Both built and bought solutions can create dangerous concentrations of knowledge in specific individuals. Custom systems built by a small team. Vendor relationships managed by a single procurement lead. Integrations understood by the engineer who built them. These concentrations are operational risk that should be identified and mitigated explicitly — not discovered when the key person leaves.
Applying the Framework
The framework described above does not produce a formula. It produces a structured conversation — with the people who hold the strategic context, the financial constraints, the technical requirements, and the operational accountability to make the decision well.
That conversation, conducted rigorously, consistently surfaces dimensions of the decision that the standard analysis misses. It surfaces the regulatory implications that legal should have flagged earlier. It surfaces the exit cost that procurement did not model. It surfaces the strategic trajectory that makes a capability more important in three years than it appears today. It surfaces the partnership option that nobody raised because the default framing was binary.
The decisions that hold up over five years are the ones that started with the right questions.
Build what differentiates. Buy what does not. Partner when expertise, speed, and ownership need to coexist.
And always, always model the exit before you commit to the entry.
WiseAccelerate works with enterprise engineering leadership to navigate technology decisions — from architecture strategy and build-versus-partner analysis through to delivery execution and knowledge transfer. AI-native engineers. Full-stack capability. The expertise to build what differentiates, and the discipline to tell you when it should not be built at all.
→ What is the technology decision your organisation is currently wrestling with — and which dimension of the analysis is causing the most friction? Interested in what engineering leaders are finding hardest to model.
Top comments (0)