RLPCRichard Le Peurian Cross

Build vs buy decisions go wrong when they compare price tags. Ask whether customers choose you for this, then count the costs nobody invoices.

Somewhere, right now, a team is deciding whether to build its own authentication. Someone has said "it's just a login form". Nobody has yet mentioned password resets, rate limiting, account recovery, session revocation or the email from a security researcher that arrives eighteen months later. The login form is the visible tenth of the iceberg, and icebergs are famously generous with the other nine.

The opposite instinct arrives just as fast: "someone must already sell this". Someone usually does. Whether you should buy it is a separate question, and both instincts skip it.

The economist got there first

In 1937 Ronald Coase asked a question that sounds naive until you try to answer it: if markets are so efficient, why do firms exist? Why doesn't everyone simply contract for everything? His answer was transaction costs. Finding suppliers, negotiating, writing contracts and checking the work all cost something, and a firm is what you get when doing a thing in-house is cheaper than arranging for the market to do it.

Build vs buy is Coase's question at the scale of a sprint board. That explains why the usual framing, cost against control, keeps producing bad decisions. It compares the price of building with the price of buying and leaves out most of the costs on both sides. The licence fee is the visible part of buying. Integration, workarounds, renewal negotiations and the eventual migration are the transaction costs, and they never appear in the comparison spreadsheet because nobody has invoiced you for them yet.

Product or plumbing

A sharper question: do customers choose you because of this?

A restaurant makes its own signature dish and buys its electricity. No review has ever praised a bistro's relationship with the National Grid. Software divides the same way. Some capabilities are the reason people pick your product, such as the way a planning tool models dependencies between tasks, or the editing experience in a design app. Everything else is plumbing: it has to work, and customers only notice it when it doesn't.

The test: if a competitor shipped an identical version of this capability tomorrow, would your customers care? If the honest answer is a shrug, it's plumbing. Building it spends the team's scarcest resource, attention, on something that can never win you a customer and can only lose you one.

This is a strong filter rather than a law. Unusual regulation, extreme performance needs or the plain absence of a decent product can all pull plumbing in-house. And bought plumbing still needs an owner: someone who knows how it's wired, watches it and talks to the vendor before small problems become incidents.

What building really costs

Teams estimate the first release, which is the cheapest part.

The optimism has a name. Kahneman and Tversky called it the planning fallacy: we predict our own tasks from the best case instead of from how similar tasks actually went. "We can build that in a sprint" is the planning fallacy in its natural habitat.

After launch the bills keep coming: dependency upgrades, security patches for as long as the thing exists, monitoring, documentation for people who didn't write it, and an on-call rota for when it falls over at 3am. Then comes the line no estimate ever includes: everything the team didn't build while it was looking after this.

A quieter bias sits underneath. Norton, Mochon and Ariely found that people value things they've assembled themselves more highly than identical things they haven't, and called it the IKEA effect. Engineers have no special immunity. A home-grown system tends to look better to its builders than to whoever inherits it.

What buying really costs

Buying moves costs around. It rarely removes them.

Integration means mapping your data, identity and events onto the vendor's model of the world, which was designed for their average customer. Customisation has limits, usually discovered after signing. Prices change at renewal or as usage grows, on a schedule you don't control. Your feature requests join a queue with everyone else's.

Bought software accumulates technical debt too, in less obvious places: the glue code around the product's edges, the workaround for the field it doesn't support, the nightly job that tidies up a sync it gets slightly wrong. Lock-in is better treated as a price than a trap. Ask what leaving would cost and whether you'd pay it, because "could we leave?" is almost always yes and tells you nothing.

Five factors, one conversation

Put those costs together and five questions cover most of the decision:

1. Differentiation. Do customers choose us because of this?
2. Ownership cost. What will we be carrying in three years, whichever way we go?
3. Integration effort. How much work to fit it into our systems and workflows?
4. Exit options. How expensive is it to change our minds?
5. Team capacity. Do we have the skills and time, without starving something more important?

Resist turning them into a weighted score. Five guesses multiplied by five weights produce an answer to two decimal places and no more accuracy than the guesses. The factors earn their keep by surfacing disagreements while they're still cheap.

Where the answer flips

Three hypothetical cases show the same framework giving opposite answers.

Authentication in a project-planning tool. It's security-sensitive, well understood, expensive to get wrong and almost never the reason anyone buys a planning tool. Buy it. Teams with genuinely unusual requirements are the exception, and even they tend to customise a product rather than start from nothing.

The dependency model in the same tool. How tasks block, follow and relate to each other is the product. A vendor component that covers most of it leaves you owning the part that matters most through someone else's API. Build it.

A content management system. For a company publishing marketing pages, a bought or open-source CMS is the obvious choice; nobody picks a company for its admin screens. For a product whose whole proposition is how creative teams compose and publish, the editing experience is what customers pay for, and the answer reverses.

Time moves the answer as well. A recommendation feature might start as a bought service, a cheap way to learn whether recommendations matter to your users at all. If they become central and the vendor's model starts to constrain you, building becomes the right call. Simon Wardley's maps make this drift explicit: capabilities move from novel, to custom-built, to product, to commodity. Today's differentiator is often the next decade's utility.

Exit routes are options, priced accordingly

In finance, an option is the right, without the obligation, to do something later, and you pay a premium for it now. A thin abstraction layer around a vendor is exactly that: one internal interface the rest of your code calls, so the vendor sits behind one door instead of being threaded through everything. Regular exports of your own data in a usable format are another. Both turn leaving from a crisis into a project.

Options can be overpriced. Wrapping a vendor you will almost certainly never leave in layers of abstraction buys flexibility you won't use and complexity you'll maintain forever. Pay the premium where the capability is critical and replacing it is plausible.

Write the decision down, with its assumptions. A short note people can find beats a perfect architecture decision record nobody opens.

A one-page template

For a decision meeting with product and finance, one row per factor:

Ask product to challenge the differentiation row and finance to challenge the cost rows. When two people fill in the same row differently, the meeting is working: you've found an assumption nobody had said out loud. Finish with a decision, an owner and a date to look at it again.

Questions worth asking a vendor

Get the answers in writing:

• How does pricing change with usage, seats or data volume, and what happens at renewal?
• What are the term, notice period and termination conditions?
• How do we export our data, in what format, how quickly and at what cost?
• How much of the product is reachable through the API, and what are the rate limits?
• What uptime and support commitments do you make, and how are incidents communicated?
• What security and compliance documentation can we review?
• How are customer requests prioritised on the roadmap?
• What happens to us if you're acquired or shut down?

A vendor who answers the last one fluently has been asked it before, which is reassuring in its own way.

Explaining it to finance and product

Finance and product rarely need the architecture diagram. They need the risk (security, delivery, vendor dependency), the speed (time to value and what it does to the team's capacity) and the strategy (where the company means to be distinctive). Translate technical debt into terms they already manage: future cost, lost flexibility, roadmap delay. Show the options you rejected and why; a recommendation is more convincing when people can see what it beat.

Decide again later

Every build vs buy decision has a shelf life, so write the triggers down when you make it. For bought software: a price rise, usage crossing a threshold, the vendor changing direction, a customisation limit blocking a goal. For built software: maintenance crowding out roadmap work, or the market catching up and selling your capability as a commodity.

Coase's answer still holds. A company's boundary sits wherever doing the work yourself stops being cheaper than arranging for someone else to do it. In software that boundary moves every time a capability turns into a product someone else sells, which makes the most expensive build vs buy decision the one nobody revisited.