Skip to content

Knowledge base

Build or Buy Framework

Decide build or buy on four dimensions: functional, technical and operational complexity, plus unique business value. Then count cost at five levels, from technology and staffing up to lost business and missed opportunity. Build what differentiates the business and what your team can understand and operate.

Written by

Updated:

Software Engineering 5

Our position. We hold that the build-or-buy equation has shifted, because AI collapses the cost of building: invest in your team’s training and your own internal tooling rather than renting closed vendor platforms. Bought packaged solutions give temporary speed, and built internal capability gives permanent advantage (build capability (opens in a new tab)).

The framework below still structures the case. It comes, with both case studies, from Buy or Build? (opens in a new tab), published on 18 April 2020. For the agentic-era version of the question, read Build versus buy.

What should a build-or-buy decision evaluate?

Every build-or-buy decision should be evaluated across four dimensions. Skipping any of them leads to decisions driven by gut feeling rather than structured analysis.

1. Functional Complexity

The ability to spec out the entire functionality is one of the most important determinants of buy-vs-build decisions. Often we know what the primary functionality should be – e.g. being able to show metrics on a graph (a monitoring solution). The devil is in the details, though, and spending time discovering peripheral functionality is critical to avoiding a situation where you jump head-first into building something seemingly simple and then get stuck.

E.g. how does the monitoring solution handle server-churn for the services it is monitoring? Does it rerun the entire query when auto-refresh is turned on?

Discovery technique: Look across competing products that offer the solution and see how they differentiate themselves from competitors. Each of those differentiators is functionality that is relevant to some customer, and could be relevant to you as well.

2. Technical Complexity

Knowing what to build (functionality) is a starting point. The next step is to understand whether you have the capability to build that functionality. It’s not uncommon to find that functionally complex products are not technically complex and vice-versa.

  • Functional complexity arises out of the uncertainty in specifying the desired behaviour in a way that is known to be easy to code.
  • Technical complexity arises out of the ability to meet the functional requirements in repeatable and reliable ways. E.g. interactive information retrieval remains a technically complex domain despite years of R&D. The business requirements and scale requirements keep growing to outpace any simplifying developments.

This is one of the less difficult criteria for evaluation. Provided you have a good enough understanding of the functional complexity, you know whether you have the skills to build it in-house or whether you can hire to build the skill-set.

3. Operational Complexity

Things that are easy to build could be deceptively difficult to operate. Keeping something running reliably with predictable performance under stress is especially hard.

Anyone who has handled “discount sale” events – from book publishers to game engines to e-commerce platforms – knows the pain of F/OSS technology that works beautifully at small scale, only to blow up spectacularly under high load at a time when the business critically depends on it.

Signal to watch for: If you see a product for which there’s no shortage of F/OSS offerings, yet there are “enterprise” offerings that are highly profitable, it’s a strong indicator of operational complexity.

The black-box rule: If you want to treat some technology as a black box, don’t use F/OSS that you operate yourself. If you’re operating something on your own, it’s best if you have built it or you have the ability to benefit from the openness of its source and understand exactly how it works under the hood. Another alternative is to understand its behaviour empirically by stressing it beyond your foreseeable requirements and figuring out how you’ll handle its failures. Both of these – understanding through code or empirical behaviour – are expensive propositions.

4. Unique Business Value

The last evaluation criteria (but not the least important by any means) is how the component you’re evaluating acts as a differentiator for your business.

The differentiator consideration is extremely important. People often argue that we should build something in-house because it’s business-critical. Well, the Internet is business-critical but pretty much no one is building their own telco network, are they?

The staffing consequence: There is a very dire consequence of deciding to build something that is not a differentiator for your business – lack of long term investment into the component. When deciding to staff a team, the business will always prefer to allocate more to components where they can see a clear, tangible business benefit. The less that a component contributes to business differentiation, the less focus it will have from a staffing perspective.

Soon you’ll find that the component that was cutting-edge at the time you built it has turned into a dinosaur a few years down the line while the state-of-the-art has progressed much further, potentially becoming even more cost effective.

How do you count the full cost?

A retrospective mini-game for your decision-making maturity on cost comparisons. Most teams stop at Level 1 or 2. The real insight comes at Levels 3-5.

Level 1: Technology Cost

You compare the cost of servers and other operational components and see how much you might save.

Level 2: Staffing Cost

You throw in the CTC of the developers who will be building and operating the component.

Level 3: Business Development Cost

This is where it gets tricky. If you allocate the budget from Level 2 (i.e. your sharp engineers) to building direct business value, how much additional revenue would you gain? If you pull existing engineers who are directly building business value, how much revenue would you lose? For a high growth startup still executing on its product plan, this cost could be really high.

Level 4: Loss of Business Cost

Even more tricky than Level 3. This requires comparing monetary impact of SLAs and Quality of Service:

  • Impact on revenue per minute if the component fails
  • Impact on revenue if the component degrades in performance or reliability
  • Loss of revenue due to reduced engineering and business productivity due to poor performance

Level 5: Business Opportunity Cost

The most interesting aspect of making a buy vs. build decision. In a nutshell, it captures the impact of lack of investment (build) or control (buy) in the evolution of the product under consideration.

It’s closely tied to the differentiation factor:

  • Low differentiator built in-house: Most likely future is understaffing, leading to growing Level 4 costs while the rest of the world (including your competitors) advances in capability.
  • High differentiator built in-house: Potential to increase future differentiation to the extent that it could become a source of direct revenue.

How does the framework play out in practice?

Case Study 1: Chat Server – Build

At Tokopedia, the team needed to build peer-to-peer and group chat capabilities. They already had experience with 3rd party solutions for reference.

Functional Complexity: Chat functionality is well understood. The team was able to nail down most of the core and peripheral functional requirements with clarity, validated against the core feature-set from 3rd party solutions.

Technical Complexity: Chat servers have traditionally been notoriously complicated pieces of technology to build. Keeping end-to-end latency under predictable bounds while handling hundreds of thousands of concurrent connections is a well known problem (cf. C10k or C10M Problem).

The game-changer was Go’s concurrency model. The select statement (opens in a new tab) combined with goroutines (opens in a new tab) and rapid benchmarking capabilities made chat servers trivial to build. Tokopedia is a Go shop and had engineers who could wield this capability into a reliable working solution.

Operational Complexity: Having built the chat server from scratch, the team had full control on its behaviour and failure patterns. They could dig right down into the TCP implementation of Go if needed, leaving very little behaviour that couldn’t be understood or controlled. Frequent stress tests allowed developing implementation and operations hand-in-hand for a low maintenance solution.

Unique Business Value: Chat is one of the most crucial touch-points that a business has with their customers. Being able to build workflows over chat, integrate business artefacts into the chat protocol, and control the experience end-to-end has very high business value. Full control over the solution meant integrations could happen at whatever level is most optimal, rather than only doing surface-level integrations through a 3rd party API.

Cost: Working through all five levels of cost evaluation, Level 1 and Level 2 costs were 10x lower at full scale for one of the use cases.

Verdict: Build. Low technical complexity (thanks to Go), high functional clarity, full operational control, and high differentiation value.

Case Study 2: Log Platform – Buy

Also at Tokopedia, the team needed a scalable log aggregation platform that could be used across the whole company – not just for application-specific logs but also for cross-application analysis at high speed of interactivity.

Functional Complexity: On the surface, log aggregation is well understood with limited scope. However, prior experience and analysis of 3rd party offerings revealed important peripheral functionality: handling instance churn in a containerised environment, highly responsive interaction, analytics and alerting on log data, etc.

Technical Complexity: Interactive information retrieval at scale is a complex problem. Basic log aggregation with simple filters was doable in-house, but building full-scale log analytics is technically complex.

Operational Complexity: The only option was to assemble and operate a F/OSS solution as a black box. That didn’t go well. Understanding a log platform is extremely costly – whether as a white-box (reading the code) or empirically (understanding failures through stress testing). Nobody wanted log platform maintenance to be someone’s full-time job. Keeping ingestion and query times low enough for “real-time, interactive” performance while ingesting TBs of log data daily – and scaling 10x for discount sale spikes – was not viable.

Unique Business Value: Log aggregation and analysis is business-critical but not a differentiator. No use cases specific to the business couldn’t be satisfied through off-the-shelf solutions. Business differentiation was very low.

Cost: Analysis revealed that Level 2 through Level 5 costs would have been higher for an in-house solution. High enough to overcome any savings in Level 1 costs, and the gap increased with scale.

Verdict: Buy. High technical complexity, high operational complexity, low differentiation value, and unfavorable cost dynamics at scale. They went with a 3rd party solution (opens in a new tab).

When should you sell what you built?

Most teams stop after making a buy vs. build decision. But the same framework can help decide whether you should sell what you’ve built. Two additional considerations:

Externally Relevant Differentiation

When you decide to build something with high complexity, it’s most likely because it has high business differentiation value for you or you’ve altered the economics of third party solutions. You’ve built something that is not only hard to build but also different from existing solutions in meaningful ways.

Since your business doesn’t operate in isolation, others might find that same differentiation meaningful. You could potentially sell your solution commercially or as a F/OSS offering.

But there’s one more thing to validate first.

Cost of Multi-Tenancy

When you build a solution in-house, you build it for your company, for your use cases. Selling it externally means doing a lot of additional work:

  • Separating out your company as a tenant of your solution
  • Ensuring multiple tenants don’t step on each other’s toes or discover each other’s business secrets
  • Adding cost computation and usage audits
  • Implementing more robust end-user security

Sometimes the cost of multi-tenancy itself becomes too high. Maybe the solution turned out to be profitable precisely because it wasn’t multi-tenant. One of the reasons enterprises buy enterprise solutions is because any platform in a large company inherently needs to support multi-tenancy. These companies don’t just have different teams – they have teams belonging to different business units that need to calculate internal charge-backs for shared technology and don’t take loss of reliability due to a sister unit’s misdemeanour lightly.

The sell decision: Only when externally relevant differentiation is high AND the cost of multi-tenancy is manageable should you consider productizing what you’ve built.

Why do build-or-buy decisions go wrong?

Different markets have different appetites to buy or build. A lot of “emotional” decision-making goes on. Functional vs. Technical complexity is often not differentiated and the wrong trade-offs between short term and long term prospects are made.

Use the four dimensions (Functional Complexity, Technical Complexity, Operational Complexity, Unique Business Value) to structure the analysis. Use the five cost levels to quantify it honestly. And if you end up building something great, use the sell framework to decide if the world should have it too.

Resources

Articles

  • Buy or Build? (opens in a new tab) - LinkedIn article that supplies this page’s four evaluation dimensions, five cost levels and both case studies, a chat server and a log platform.

Documentation

Posts

  • Build capability (opens in a new tab) - LinkedIn post arguing that AI collapses the cost of building, so teams should invest in training and internal tooling over rented vendor platforms.

Tools and repositories

  • Scalyr (opens in a new tab) - Scalyr’s log-management product page in an archived May 2020 snapshot, the third-party solution the buy case study chose.