Buy and extend: the option most decisions actually land on

The decision is presented as a binary and almost never resolves as one. What companies actually do is buy the parts that are the same everywhere and build the parts that are not, and the quality of the outcome depends almost entirely on where that line gets drawn.

Drawn well, you get a system where the commodity work is somebody else’s problem and your engineering attention goes only to the thing that distinguishes you. Drawn badly, you get the maintenance burden of a build and the constraints of a purchase at the same time.

Finding that line is what a build vs buy analysis is for, and it is a more useful exercise than picking a side.

The line is drawn at differentiation, not at difficulty

The instinct is to buy the hard parts and build the easy ones. That is backwards.

Buy the parts where being the same as everyone else is fine or actively good: authentication, payments, email delivery, error monitoring, accounting. Being unusual in these is a liability, not an edge.

Build the parts where being the same as everyone else means having no reason to exist. If your routing logic, your pricing model, or the way you score a case is why customers choose you, that belongs to you regardless of how hard it is.

Difficulty is irrelevant to the line. Payments are extremely hard and you should still buy them.

Three shapes this takes

Product plus custom layer. You run a platform and build the specific workflow on top of its API. Cheapest, works well while the platform’s model matches yours, and gets uncomfortable when you need behaviour the API does not expose.

Custom core plus bought services. Your own application, with the commodity concerns contracted out to services. This is the default shape for most modern software and it is usually the right one.

Bought system with an integration layer. Several products, joined by something you own. Legitimate, and the piece to watch: that integration layer is a build, with all the obligations of one, and it is frequently treated as plumbing rather than as a system with an owner.

The failure mode to watch

The extension that grows into a product.

It starts as a small customisation on a bought platform. Over three years it accumulates logic until the platform is providing the database and little else, while imposing every constraint of its data model on code that has outgrown it.

You now have the worst of both: a build you did not plan, running inside somebody else’s assumptions, with a per-seat licence attached.

The signal is when engineers start describing work in terms of getting around the platform rather than using it. That is the moment to decide deliberately whether to move the logic out, and the decision is much cheaper then than two years later.

A practical way to draw the line

List the capabilities the system needs. For each, ask one question: if a competitor had exactly this, identical, would it hurt us?

If the answer is no, buy it. Authentication, invoicing, notifications — a competitor having identical ones costs you nothing.

If the answer is yes, that capability is a candidate to build, and it should be a short list. Most companies find three or four items on it, and the discipline is refusing to build the rest.

The line needs reviewing, not just drawing

The differentiation test gives you an answer for today. It expires, because what distinguishes a business changes and the market catches up on what used to be unusual.

Custom scheduling logic that was genuinely an edge in 2019 may be a standard feature of three products now. The code still works, so nobody revisits it, and the company keeps paying maintenance on something it could buy.

The reverse also happens. A commodity you sensibly bought becomes the thing customers choose you for, and now your differentiator runs on somebody else’s roadmap.

An annual pass over the list is enough. For each built capability, ask whether it would still fail the competitor test today. For each bought one, ask whether it has quietly become the reason people pick you. Two or three items move each year, and catching them early is far cheaper than discovering them during a migration.

Where this framing runs out

It assumes you can tell which capabilities differentiate you, and early-stage companies frequently cannot — the thing that turns out to matter is often not the thing anyone predicted. In that situation the safer move is to buy nearly everything and stay cheap to change, then build once the evidence arrives.

I also cannot tell you whether a specific platform’s API is expressive enough for what you have in mind. That needs someone reading the documentation against your actual requirements, and it is the check most often skipped before a platform is chosen.

Related reading: what building commits you to, buying software you can live with, and when off-the-shelf fights your process — which is usually what pushes a company from buy toward this middle path.