Build vs Buy in the Age of LLMs

The build-vs-buy conversation used to be reasonably simple. If a problem was generic, you bought it. If it was specific to your business, you built it. The economics held for decades.

LLMs changed the math, and most operators are still calibrating to the new shape.

What changed

Three things shifted in the last 18 months that operators should sit with:

1. The cost of building shrank. A focused team can ship more software in 8 weeks in 2026 than the same team could ship in 6 months in 2022. LLMs aren't replacing engineers; they're compressing the slow parts of the work.

2. The cost of generic SaaS rose. Not in price (though that's true too)—in opportunity cost. The features your vendor ships next quarter are features your competitors get the same week you do. Generic AI features land for everyone at the same time. The differentiation moved.

3. The cost of not owning your data layer rose. Every vendor wants to add AI on top of your data. The companies that own a clean canonical layer underneath have a real advantage. The ones that have their core data scattered across twelve vendors are stuck.

The result: the line between "should buy" and "should build" moved meaningfully toward "build" for anything that touches the parts of your business that are genuinely yours.

The new framing

The old question was "should we build this software?" That's still useful, but a sharper question is now also on the table: should we own the layer this software runs on?

• Own the data. Almost always, yes. Even if you're using a vendor on top, the system of record should be yours.
• Own the workflow. Sometimes. If the workflow is competitive—if your team does it differently than the industry, and that's why you win—own it.
• Own the model. Rarely. The frontier providers are good enough and getting better. The interesting work in 2026 is around the application, not the foundation model.

Where vendors are still the right answer

It's important not to overcorrect. The places off-the-shelf still wins:

• Commodity productivity tools (email, calendar, docs, design)
• Transactional infrastructure (payments, identity, storage, observability)
• Specialized workflows where the vendor has 10+ years of domain depth (tax, payroll, compliance)

Building these because you can build them is a mistake. Burning months on these is exactly the work LLMs should free you up to skip.

A useful test

When a build-vs-buy decision is genuinely contested, we ask:

"If this surface worked twice as well as the average competitor's, would our business be visibly better?"

If the answer is yes, you're looking at custom. The marginal gain compounds over the years you'll run it.

If the answer is "not really, we just need it to work," you're looking at SaaS. Buy the most boring, reliable option and move on.

What "build" actually costs in 2026

A meaningful piece of custom software—a focused internal tool, a customer portal, a domain-specific AI surface—generally costs $40k-$200k all-in, ships in 6-16 weeks, and replaces between $30k and $150k in annual SaaS and operational drag. The math has gotten genuinely good.

That doesn't mean every problem is worth solving. It means the kind of problem worth solving with custom software is broader than it was three years ago. We talk through this calibration in nearly every discovery engagement—because for most businesses, the issue isn't whether to build, but which one thing to build first.