Beyond binary: a modern framework for build vs. buy decisions

In this post, my colleague Dave Sammut and I delve into this challenge.

We’ve all experienced the pressure to make the right decision between building custom software and buying off-the-shelf. 

A few years ago, I wrote a post setting out principles for when to build versus buy but often this is a false dichotomy – the ‘right’ answer may lie on a spectrum. The challenge is to identify where on that spectrum an organisation lies, to avoid wasting cost, time and opportunity. 

The reality check

Build vs. buy can be a complex equation with variables that are unique to your organisation. It’s possible for two almost identical companies with the same challenge to make opposite decisions, and both be right. Factors like timing, organisational capabilities and risk appetite create unique context that can’t be ignored.

Rule of thumb: context is key
Context isn’t only architecture. It also relates to organisational setup, timing, processes and practices. 

Do your homework 

Taking time to do the foundational work before diving into build vs. buy pays dividends later:  

• What problem are you solving? Problem framing workshops using techniques like 5 Whys or Jobs to be Done save months of misdirected effort. 
• Map your architecture. Your current architecture isn’t what’s documented in Confluence – it’s what’s actually running in production. 
• Identify non-negotiables. Legal requirements, integration constraints and security models are hard boundaries. Get compliance, security and legal teams involved early.

Clarify your goals

Understanding what can remain unchanged, what needs to stop, and where investment is needed will shape your entire approach. For example: 

• Getting off unsupported systems: Speed and risk reduction take precedence
• Modernising the stack: Distinguish between technical updates and new business capabilities
• Introducing new features: Does your unique implementation drive measurable business outcomes? 
• Saving money: Be brutally honest about hidden costs – I’ve seen “cost-saving” builds cost 3x more in maintenance

Differentiator reality check

What’s perceived as unique is often industry-standard functionality wrapped in company-specific language. 

To understand the difference, ask whether you can demonstrate that customers choose you specifically because of how we implement that functionality? If the answer is no, you’re probably dealing with a commodity function wearing a custom suit.

Aligning with strategy

Consider whether building or buying supports your broader business strategy, including future direction and capabilities.

Octopus Energy made the decision to build Kraken, their energy platform, after recognising that their strategy of disrupting the energy sector required fundamentally different capabilities than were offered by incumbent solutions. The decision wasn’t just about features – it was about creating a platform that enabled new business models and supported rapid experimentation and expansion. 

Rule of Thumb: The Strategic Alignment Test
Are you trying to change the game, or win the current game? 

• Changing the game = Different business model, new markets, platform as moat, rapid experimentation → Build
• Winning the current game = Operational excellence, execution advantage, speed to market, scaling proven models → Buy

Organisational readiness

Having the right idea but wrong organisation leads to expensive failure. Assess honestly:

Skillset reality:
Do you have talent to build and maintain a custom solution? 

Process maturity:
Custom software without mature CI/CD, monitoring and operations is like buying a sports car without knowing how to drive.

Team structure:
Conway’s Law is predictive. If your team structure doesn’t match the architecture you need, you’ll need to reorganise or adjust your approach, ensuring you have the agility needed to act on feedback. 

Risk and change appetite:
Is your organisation, from execs to individual contributors, ready for change and the corresponding risk

Drive vendor conversations

Too many decisions fail because companies talk to vendors before understanding what they need. The result is that the vendor drives the conversation and tells you what your needs are, which conveniently maps to their solution and features. 

Don’t just listen to pitches – shape them. Share your unique context and use reverse demos to present your architecture to vendors rather than vice versa.    

Heuristics that actually work

“Decide what you want to own” – If you build it, you own the tech debt, uptime, and roadmap. Only build if long-term ownership creates sustained advantage.

“Buy for fit, not features” – Choose vendors based on how well their product aligns with your architecture, not feature lists.

“Don’t overestimate how unique you are” – Are you solving a novel problem or executing poorly with current tools?

“Build less, buy more” – The question isn’t whether you can build it better – it’s whether you should own complexity long-term.

“Know your vendor” – Does a vendor’s strategic direction match your goals, and do their differences add measurable value? 

The real outcome

The benefit of carefully evaluating buy vs build (or both) isn’t just the best decision – it’s the understanding you’ve gained into:

• Required organisational changes: Team structures, hiring, process improvements
• Required engineering and methodology practices: CI/CD, platform engineering, paved road
• Explicit assumptions: About your organisation and market

Build in checkpoints from the start to reassess whether your approach delivers expected outcomes, with an understanding that decisions are reversible. 

Most complex technology decisions require a nuanced mix of build and buy choices. The outcome isn’t a binary verdict or colour-coded architecture diagram – it’s a comprehensive roadmap that addresses technology, organisation, and execution. 

Success depends on understanding not just *what* to build or buy, but *how* your organisation will deliver, integrate, and evolve these choices. 

Rule of thumb

• If it enables competitive advantage or is a disruptor or you require rapid experimentation and aligns with your architecture, and you can own it long-term—build
• If it solves a non-unique problem, aligns with your model, and can be reversed—buy
• If neither —wait, redesign or rethink your need

How we approach buy vs build: 

Here’s how we take build vs buy decisions from opinion-driven debates to evidence-based choices:

1. Foundation gathering – Use existing architecture documentation and metrics to establish context
2. Workflow decomposition – Break user journeys into functional components, identifying all systems, teams, and production pathways.
3. Current state mapping – Create Wardley Maps plotting each component’s evolution, revealing what’s custom versus commodity 
4. Market research –  AI-assisted research followed by structured vendor conversations 
5. Updated analysis – Redevelop maps, incorporating market insights
6. Target architecture – Design diagrams showing implications of decision paths
7. Organisational impact –  Document required team structure/process changes 
8. Multi-perspective synthesis – Gather various viewpoints to address stakeholder concerns