Why "build vs. buy" just flipped

For most of the last two decades, the default answer to "should we build this internally or buy a SaaS for it?" was buy. The reasoning was sound: software engineering was expensive, vendors had specialized expertise, and the marginal cost of one more SaaS subscription was lower than the marginal cost of one more in-house tool to maintain.

That arithmetic is no longer the arithmetic.

What changed

Three things changed at roughly the same time and compounded.

One — the cost of building dropped through the floor. Capable language models have cut the time-to-build for internal tools by a factor that varies between 3x and 10x depending on the team. Not in the demo. In production. A two-engineer studio in 2026 ships software at a volume that took a ten-person team in 2019. The ratio is widening quarterly.

Two — the cost of integrating SaaS rose. The average enterprise SaaS purchase in 2026 carries a six-figure annual cost, requires SOC 2 and DPA negotiation, demands SSO and SCIM, includes vendor lock-in via proprietary data formats, and ships with a built-in roadmap mismatch between what you need and what they prioritize. None of that is news. What is new is that the alternative — building it yourself — is no longer prohibitively expensive.

Three — AI-native workflows do not map cleanly to SaaS-shaped products. Most internal AI workflows are sequences of LLM calls, retrieval steps, judgments, and routing that touch data the customer considers proprietary. There is no SaaS that does this generically well, because it cannot be generic — the value is in the integration with your data and your operations. The vendors who try to sell a generic solution are the vendors whose customers churn at month nine.

The new arithmetic

For an internal tool with a clear scope and modest user base — say, a back-office workflow, an internal analytics surface, an AI assistant trained on your data — the new shape often looks like:

Approach	Year 1 cost	Year 3 cost	Customization	Data control
Buy SaaS	$80–250K	$250–800K	Vendor's roadmap	Vendor controls
Build internally	$80–200K	$150–400K	Yours	Yours

The build column was 3–5x higher across the row in 2019. In 2026, for many categories, it isn't. Sometimes it is lower in year one and almost always lower in year three, while delivering exactly what your team actually wants.

This is not a universal rule — it's a category-by-category one. The categories most exposed are the ones where:

• The workflow is unique to your business (no generic vendor wins).
• The data is proprietary (you want to keep it).
• The user base is modest (you don't need a vendor's scale).
• An LLM is in the critical path (the vendor can't beat you on prompts because they don't have your data).

If three of four apply, you should be building.

What categories are most exposed

The clearest exposed categories in 2026:

• Internal AI assistants — "ChatGPT for our company" is increasingly a 4-week build, not a vendor evaluation.
• AI-augmented internal analytics — replacing a $150K/year BI vendor with a stack of OSS tools + a domain-specific LLM agent on top is now a project, not a moonshot.
• Workflow automation with AI in the middle — generic workflow platforms (Zapier, Workato) struggle when AI judgment lives at any step. In-house wins.
• Customer-facing AI features — vendor solutions all look the same to the end user, which means they are not differentiation.

Categories that are still mostly buy: highly regulated identity and security (Auth0, Okta), commodity infrastructure (databases, CDNs), office collaboration (Slack, Notion, Linear). Vendors with deep network effects or genuine domain specialization still win — but the bar has risen.

The vendor lock-in question

The hidden cost of every SaaS decision is what does it cost to leave? For most categories, the answer is high — data migration, retraining, re-integration. The hidden benefit of building is that the leaving cost is your team's standard ongoing engineering. There is no migration because you own the system.

Build-vs-buy is, in this lens, a question about where you want your maintenance burden. With a SaaS, the burden is integration, negotiation, and migration planning. With an internal tool, the burden is engineering capacity. In 2019 the engineering capacity was the expensive side. Increasingly it is not.

What this means for buyers

If you are still defaulting to buy, you should at least be asking the question for every six-figure SaaS decision. The right reflex in 2026 is to scope a 4-week internal build alongside every vendor RFP. About half of those builds will turn out to be the right call. The other half will have produced a much sharper RFP for the SaaS you do eventually buy.

The teams that get this right are the ones moving fastest. Not because they build everything — they don't. They build the right things, and buy the others with much better leverage because they know what building would cost.

---

If you are evaluating a build-vs-buy decision and want a second opinion from a team that does build work for a living, book a call.