Buy the commodity. Build the edge.

The wrong question

"Is it cheaper to build this or license it?" produces a number quickly and the number is close to meaningless, because it compares a known quantity against an estimate and ignores the two things that actually decide the outcome: whether the capability is a differentiator, and who is responsible for it in three years.

The rule

Buy where the capability is the same for you as for your competitors. Build where it encodes something only you know.

Almost everything is the first category, and that is a feature of the rule rather than a weakness. Nobody wins by having a bespoke way to transcribe a call, store a vector, authenticate a user or send email. Those are solved, commoditised and getting cheaper every quarter. Building them consumes the budget that should have gone to the thing that is actually yours.

What survives the test is narrower than most build proposals assume:

• Your data model. How your entities relate is specific to you and rarely fits a product's assumptions.
• Your operational rules. The logic accumulated over years that staff apply without being able to write down.
• Your integration surface. The particular set of systems you run, including the legacy one no vendor supports.
• Anything a customer sees as you. If it shapes their experience of your business, a shared template makes you generic.

If a competitor could buy the same product tomorrow and get the same result, building it bought you nothing except a maintenance obligation.

Most real answers are both

Framing it as a binary is the second mistake. The shape that works in practice is bought infrastructure with built logic on top: licensed models, managed databases, standard authentication and off-the-shelf integration components, with your own layer holding the data model and the rules.

That is also the architecture that survives change. When a better model appears, you swap a dependency. When a vendor is acquired and repriced, you replace a component rather than a system. What you built stays yours; what you bought stays replaceable. A build that reaches all the way down to infrastructure gets none of that and ages badly.

What buying actually costs

Two costs are routinely omitted from the buy side of the spreadsheet, and both arrive later.

The first is integration. A product that does 80% of what you need still has to reach your systems, and the last 20% is where the work is. That gap is frequently filled with an internal build anyway — you end up maintaining software regardless, without owning the part that matters.

The second is the exit. Ask before signing, not after: what happens to your data on termination, in what format, and how long does extraction take? A capability you cannot leave is a capability whose price you no longer control. That is the buy-side equivalent of the ownership question you would ask a build vendor.

What building actually costs

The build side has its own reliable omission: the cost does not end at delivery. Software you own is software you maintain — dependency updates, model changes, integration drift as connected systems change, and the person who understands it eventually leaving.

This is why the honest build question is not "can we build it?" — usually yes — but "are we willing to own this in three years?" A build that nobody is resourced to maintain becomes a liability faster than most organisations expect, and it fails quietly rather than loudly.

A decision that takes an afternoon

Four questions. Any single strong signal usually settles it.

One caution on the middle rows. Heavy customisation of a bought product is the worst of both outcomes: you pay a licence, you maintain the customisation, and you inherit the vendor's roadmap as a constraint on your own. When the customisation starts looking like a build, it is a build — price it as one and decide again.