A team sits in a room deciding whether to build their own analytics tool or pay a vendor for one. The engineers want to build it, it looks interesting, and "we could make it exactly fit." The finance lead wants to buy it, the licence is cheaper than three months of salary. Both are arguing about the wrong thing. The real question is not what costs less today; it is whether owning this particular piece of software will ever help the company win customers. Get that straight first, and the build-or-buy answer usually falls out on its own.

The quick version

  • Build means your own people write and own the software. Buy means you pay a vendor for theirs, usually as a subscription (SaaS) you rent, not own.
  • The deciding test is strategic vs utility: build the few things that make you different from competitors; buy the many things every company needs (payroll, email, expense claims) and just adapt to how the bought tool works.
  • Compare total cost of ownership, not sticker price. Building has a long tail of maintenance; buying has lock-in, integration work and per-seat fees that grow. Both have hidden costs that dwarf the obvious one.
  • It is rarely all-or-nothing. Most companies buy the commodity layers and build the thin slice on top that is genuinely theirs, and revisit the line as things that were once special become ordinary.

The idea in depth: build what makes you different, buy what makes you normal

The cleanest way to cut this decision comes from Martin Fowler, who splits software not by technology but by what it does for the business. In his "Utility Vs Strategic Dichotomy" (martinfowler.com, July 2010, updated 2016), he draws a line between utility software, the necessary functions every firm needs, like payroll, where the goal is reliable and cheap, and strategic software, which directly creates competitive advantage. His build-or-buy rule follows from the split: for utility, buy a package and bend your process to fit it; for strategic work, build, because, in his words, "you don't want the same software as your competitors because that would cripple your ability to differentiate."

This is the same idea Geoffrey Moore frames as core vs context in Dealing with Darwin (2005). Core is any activity that creates the differentiation customers will pay you for and rivals struggle to copy; context is everything else that has to get done but wins you nothing. Moore's strategic prescription is blunt and useful: extract resources from context to pour into core. Applied to technology, that means refusing to spend your best engineers re-inventing a CRM so you can spend them on the one workflow no competitor has.

So the move is to start the meeting with the right question, not the budget. Before anyone estimates a cost, ask: if we owned the best possible version of this software, would a customer ever choose us because of it? If yes, it is a candidate to build. If no, if it is something a customer expects but never celebrates, your default is buy, and the burden of proof sits on anyone arguing to build. Fowler's own estimate is that only around 5% of projects are genuinely strategic, yet organisations routinely talk themselves into believing far more of their work is special than truly is.

The honest limitation: the line moves. Moore is explicit that strategic work decays into context over time as the market catches up, and occasionally a piece of context becomes strategic when someone turns it into a differentiator. A bespoke logistics engine that was your edge in 2018 may be a commodity SaaS product by 2026, at which point continuing to build it is just expensive nostalgia. The test is not a one-time verdict; it is a question you re-ask.

Why the boundary of the firm is an economic question, not just a technical one

"Should we make this ourselves or get it from the market?" is one of the oldest questions in economics, and it has a Nobel-winning answer worth borrowing. Transaction cost economics, traced to Ronald Coase's 1937 essay The Nature of the Firm and developed by Oliver Williamson, who won the 2009 Sveriges Riksbank Prize in Economic Sciences "for his analysis of economic governance, especially the boundaries of the firm", says firms do work in-house when using the open market would cost more than organising it internally, and buy from the market when the reverse is true. The costs that tip the balance are not just the price tag: they include the effort of finding a supplier, negotiating, writing the contract, and policing it afterwards.

Williamson's sharpest contribution is the idea of asset specificity, and it maps neatly onto software. The more a capability is specific to your situation, the harder it is to buy cleanly off a shelf, and the more sense it makes to bring inside the firm. A generic need (email, accounting) is low-specificity: many vendors serve it, switching is feasible, the market is safe. A need that is highly particular to your business has few or no good vendors, forces heavy customisation, and leaves you dependent on a supplier who knows you can't easily leave, which is exactly the dependency that makes building it yourself the safer governance choice. This isn't a contradiction of Fowler; it is the economics underneath him. Strategic work is usually high-specificity work.

You are not choosing software. You are choosing where to draw the edge of your company.

Practically, that means grading each capability on two axes before you decide anything: how much it differentiates you, and how specific it is to you. High on both, lean build. Low on both, buy without guilt and adapt your process. The interesting cases are the corners, generic-but-strategic, or specific-but-commodity, and those are where a "partner" model (a deep vendor relationship, a contract, a co-build) often beats a pure build or a pure buy. This is the same make-or-buy logic the Toolkit covers from the commercial side; see build, buy & partner decisions.

quadrantChart
  title Where does this capability sit?
  x-axis "Commodity (many vendors)" --> "Specific to us (few/none)"
  y-axis "Won't win customers" --> "Differentiates us"
  quadrant-1 "Build (your edge)"
  quadrant-2 "Partner / customise"
  quadrant-3 "Buy and adapt"
  quadrant-4 "Buy, watch lock-in"
  "Payroll": [0.15, 0.15]
  "Generic CRM": [0.30, 0.30]
  "Your core algorithm": [0.85, 0.85]
  "Niche workflow tool": [0.75, 0.45]
Grade a capability on differentiation and specificity before arguing about cost. The corners are where "partner" beats a pure build or buy. Leaders Loop

Count the whole cost, not the sticker price

Once you know whether something should be built or bought, the second discipline is costing the choice honestly, and the number people quote is almost always the wrong one. The licence fee or the initial build estimate is the visible tip; the decision should turn on total cost of ownership (TCO), the full lifecycle cost including implementation, integration, training, support, downtime and eventual replacement. The term comes from Gartner, which applied it to IT spend in the late 1980s, and the point it makes is the durable one: the purchase price is usually a fraction of what a system actually costs once the invisible expenses arrive (CIO, "How to calculate TCO for enterprise software").

The two paths hide their costs in opposite places. Building looks cheap because the day-one estimate ignores the years of maintenance, security patching, on-call support and the fact that the people who built it will leave. Buying looks cheap because the headline subscription ignores integration work, per-seat fees that compound as you grow, data-migration pain, and the switching cost that quietly hardens into lock-in, the more your processes wrap around a vendor's tool, the more pricing power they hold at renewal. Williamson would recognise that last one immediately: it is asset specificity working against you.

The discipline, then, is to cost both options over a realistic horizon, three to five years, not year one, and to write down the assumptions, not just the totals. A poor build-versus-buy call can multiply total cost several times over across that window, which is why the cheap-looking answer in the meeting is so dangerous. Put the build's maintenance tail and the buy's lock-in and growth fees on the same page, and the comparison stops flattering whichever side spoke last. The numbers belong in the same language as the rest of the business; see financial statements for where these costs land, build often as capitalised then depreciated effort, subscriptions as recurring operating cost.

The honest limitation: TCO is a forecast, and software forecasts are optimistic in both directions, build estimates blow out, and vendor savings assume the tool fits closely enough that you don't quietly build a second system around it. Treat the comparison as a structured argument that surfaces assumptions, not a calculator that hands you a verdict.

A worked example

Take a fictional logistics startup, call it Cartway, weighing two technology decisions in the same quarter. (Illustrative figures throughout; this is a teaching example, not a real company.) First: an expenses and approvals system for staff. Second: a route-optimisation engine that decides, in real time, which driver takes which delivery, the thing customers actually feel as faster, cheaper service.

Run both through the test. Expenses is pure context: every company needs it, no customer will ever choose Cartway because its expense forms are special, and a dozen mature vendors do it well. It scores low on differentiation and low on specificity, buy it, adopt the vendor's workflow, and refuse to spend a single engineer customising it. The route engine is the opposite: it is the company's whole reason to exist, deeply specific to Cartway's network and data, and there is no off-the-shelf product that fits without gutting the advantage. High on both axes, build it, and staff it with the best people.

The costing seals it. Building the expenses system might take two engineers a quarter, then a permanent maintenance and security burden forever after, for a capability that wins nothing; buying it is a modest per-seat subscription and a fortnight of setup. Buying a generic route tool, by contrast, would mean either a worse answer than competitors or so much customisation that Cartway maintains someone else's product without owning it, lock-in on the exact capability it can least afford to rent. Same company, same week, opposite answers, and the framework rather than the loudest voice produced both.

flowchart TD
  A(["A new capability is needed"]) --> B{"Would owning the best version
ever win us customers?"}
  B -->|"No, it's context"| C(["Buy a vendor's.
Adapt our process to fit."])
  B -->|"Yes, it's core"| D{"Does a vendor fit without
gutting the advantage?"}
  D -->|"Yes, closely"| E(["Buy / partner,
watch lock-in at renewal"])
  D -->|"No, too specific to us"| F(["Build it, staff it well,
and re-test in a year"])
The same decision Cartway ran twice: differentiation first, fit second, cost throughout. Leaders Loop

Frequently asked questions

Isn't building always more flexible than buying?

Flexibility is real, but it is only worth paying for where flexing the software changes your competitive position. For context capabilities, the stuff every company needs, flexibility is usually a trap: it invites endless customisation of something that wins you nothing and saddles you with permanent maintenance. The discipline is to want flexibility only on the few capabilities that are genuinely yours, and to happily accept a vendor's opinions everywhere else.

What does "buy" usually mean today?

Most often it means renting software as a service (SaaS), a subscription where the vendor runs and updates the product and you pay per user or per usage, rather than owning a copy. That model lowers the up-front cost and shifts maintenance to the vendor, but it changes the risk: your costs grow with you, your data lives partly in their hands, and switching later can be painful. "Buy" is closer to "rent and depend on" than "own outright," which is why lock-in deserves explicit attention.

How do we avoid vendor lock-in?

You cannot eliminate it, but you can limit it. Favour vendors with open standards and clean data export; keep the integration layer between your systems and theirs thin and in your control; and avoid wrapping deep, bespoke process around a tool you don't own. The economic point is asset specificity: the more your business is tailored to one vendor, the more bargaining power they hold at renewal. Keep the specific, strategic parts on your side of the line.

Is it ever right to build something a vendor already sells?

Occasionally, when the off-the-shelf product would force you to give up the very thing that differentiates you, or when an existing capability has quietly become strategic. But this is the exception that proves the rule, and it is also the most common way teams talk themselves into expensive mistakes. Fowler's caution stands: assume far fewer of your projects are strategic than your team's enthusiasm suggests, and make the build case clear the higher bar.

Who should actually make this call?

Not engineering alone, and not finance alone, which is exactly why the opening meeting goes wrong. The differentiation question is a strategy and commercial judgement; the specificity and maintenance questions are engineering judgement; the lifecycle cost is a finance judgement. The decision is sound only when all three are in the room and the strategic test is settled before anyone debates the price.

Related in the Toolkit

This decision sits on top of the rest of the stack, what you build or buy still has to run on somewhere and be delivered through a reliable release process whether you wrote it or rent it.

Where to go next