Build or buy is an old question with a new answer, and most teams are still using the old one.
The old rule was straightforward: buy anything that is not your core product, because building it costs more than it looks and maintaining it costs more again. That rule held for about twenty years and it is now only half right.
What changed
The cost of building a narrow internal tool has collapsed. Something that was a two-month project for two engineers is now a week for one person who is good with models, and sometimes an afternoon for someone who is not an engineer at all.
At the same time, a lot of software you would previously have bought is a thin layer over a model you could call directly. You are paying a per-seat price for a prompt, a database and a user interface.
That combination moves the line. Not everywhere, but in a specific and identifiable set of places.
When buying still wins, clearly
Anything with a data moat. If the product's value is a dataset you cannot assemble, you are not building that. Enrichment providers, contact data, firmographics: buy.
Anything where being wrong is expensive. Billing, payroll, anything touching compliance or customer money. The cost of a subtle bug exceeds any licence fee.
Anything with network effects. A CRM is partly valuable because every salesperson already knows how to use one.
Anything in a category that is moving fast. If a well-funded company is shipping monthly against this problem, your internal version is dated in a quarter and nobody owns it.
When building now wins
Workflows specific to how your business actually runs. The glue between your systems, your reporting, your handoffs. This is where off-the-shelf tools make you change your process to fit their assumptions, and where a few days of work gets you exactly what you need.
Anything you would be paying per seat for, where only a few people need it, and where the underlying capability is a model call. Summarisation, classification, extraction, drafting. The vendor's margin on these is enormous and the build is small.
Thin wrappers you have already outgrown. If you are fighting a tool more than using it, that is a signal.
Anything where the data should not leave. Sometimes the build decision is a risk decision rather than a cost one.
The mistake both camps make
The buyers treat every problem as a procurement exercise and end up with nineteen subscriptions, a four-figure monthly bill, and a stack held together by manual copying between tabs. Nobody has ever audited whether half of them are used.
The builders underestimate maintenance, which has not got cheaper. The model that writes the tool in an afternoon does not look after it when an API changes, a schema moves, or the one person who understood it leaves. Internal tools without an owner become liabilities quickly, and the second year costs more than the first.
A useful test: who maintains this in eighteen months, and what happens if that person leaves? If you cannot answer, buy it.
How I would actually decide
Three questions.
Is the value in data you cannot get, or in logic you could write? Data, buy. Logic, consider building.
How many people need it? A handful, building is viable. Everyone, buy, because support and training become the real cost.
What breaks if it goes down for a week? If the answer is serious, buy something with a support contract.
The honest summary
Most organisations should buy slightly less than they do and build slightly more, and almost nobody should build the obvious things.
The interesting shift is not that building became cheap. It is that the category of software whose only real asset was a user interface is being quietly dismantled, and a lot of what sits in the average stack falls into it.
Weighing this up for your own revenue team? It is the core of AI enablement for revenue teams.