Build vs buy: how should a SaaS founder decide?

Product and engineering · Answered by Golden Section from more than 400 B2B software companies observed

The Golden Section answer

Build what your customers pay you for and buy everything else. The workflow, the data model and the industry logic that make you different belong in your own code; support tools, billing, authentication, infrastructure and most AI model capacity are better bought. Productize an off-the-shelf system at your core and you become a reseller with a software company's cost base. The answer turns on how replaceable the vendor is and what the dependency does to gross margin; AI-delivered revenue runs at roughly 53% gross margin, well below classic software. For AI, buy the model and build the portability: one abstraction for every model call, an evaluation suite, and a second provider carrying real traffic. Start by listing every third-party component and marking which ones your customers would notice if they disappeared.

The decision rule

Own the parts of the product a customer is buying and rent the rest. Any bought component you could not replace inside a week needs a contract, a fallback and a review date.

Usually ready when

  • You can state in one sentence what customers pay you for
  • Every vendor contract has been reviewed for price locks and assignment
  • AI model calls run through one abstraction layer

Probably too early when

  • Engineers want to build an internal tool because it would be interesting
  • The core workflow is still changing every quarter and a bought component would freeze it

The numbers

MetricValueWhat it meansSource
Committed AI model capacitylow single-digit % of revenueprovisioned capacity bought from a primary model provider, budgeted as insurancerung 2 of the continuity ladder; most companies at this stage should be fully at rung 1, model portabilityGolden Section playbookAI Vendor Continuity
Economic life of owned AI hardware3 to 6 yearsuseful life of purchased acceleratorsowned hardware does not beat reserved rental on a three-year horizon at small scaleGolden Section playbookAI Vendor Continuity
AI-delivered revenue gross marginroughly 53%gross margin on AI-delivered revenueICONIQ State of AI 2026 as cited by Golden Section, which underwrites AI-delivered revenue separately at 50% to 60%Golden Section, publishedInvesting in Software, 2026 addendum

Why

The build-or-buy question is really a question about where your value lives. Our research on AI in 2026 found that software whose value sits in proprietary data, compliance and workflow depth held up, while software whose value sat in the interface did not. That tells you what to build: the data model and the industry logic your customers would struggle to rebuild. Everything around it is a cost to minimize, and building your own version of a commodity tool spends engineering on something no customer pays for.

Buying has its own failure mode, which is dependency. A vendor that raises prices or deprecates a model can damage the business at the worst moment, and one that will not assign its contract to an acquirer can stall a sale. The vendor contract playbook sets multiyear price locks and assignment without approval as standard terms, and the AI vendor continuity play treats model access as a ranked risk with a fallback that carries real traffic. Keep the open-source register current too, because buyers will ask for every license your code depends on. And put AI inference revenue and inference cost on separate lines, so the margin effect of each bought model stays visible against the roughly 53% gross margin typical of AI-delivered revenue.

Illustrative scenario

The figures are invented for illustration. A company's engineers propose building an in-house support ticketing system because the bought one lacks a custom field, at an estimated four months of two engineers' time. The same quarter, its AI drafting feature runs on a single model provider called directly from a dozen places in the code. The product manager declines the ticketing build and configures a workaround. The engineering lead instead spends three weeks routing every model call through one abstraction, adds an evaluation suite, and sends a small share of production traffic to a second provider. When the primary provider deprecates the model two quarters later, the switch takes days and the customer-facing feature never stops.

When this does not hold

When nothing on the market fits a vertical's regulatory or workflow needs, building a component outside the core can be the only option. And very early, before the core workflow is settled, buying a component that locks the data model can cost more later than building a simple version now.

What to do on Monday

  1. List every third-party component and mark which ones a customer would notice if they vanished
  2. Check each material vendor contract for a price lock and assignment without approval
  3. Route all AI model calls through one abstraction and send some traffic to a second provider
  4. Update the open-source register with every license and dependency

Mistakes founders make here

From the Golden Section mistakes list, each paired with the play that prevents it.

Mistake 30: Outsourcing core product with off the shelf

Productizing an off-the-shelf system at the core turns a software company into a reseller.

Mistake 63: Building your own support tools

Building your own support and DevOps tools spends engineering where buying would do.

Mistake 170: Assuming your model vendor will keep selling you capacity

Every bought AI capability is a dependency that can be withdrawn without warning.

Mistake 92: Lack of vendor contract control

Uncontrolled vendor contracts bring auto-renewals and price escalations into the build-or-buy math.

Plays we would run

In the order we would run them. Each is on its own page, most with a free Excel template.

Vendor Contract Playbook

Sets the terms, price locks and assignment rights that make buying safe.

AI Vendor Continuity

Ranks model-access risks and builds portability you actually exercise.

Open Source Register

Records every license and dependency a buyer will ask about.

Channel Partnerships

Evaluates an integration partner, competitor or not, with the same metrics as any channel.

Partner Conflict Management

Models what a partner earns by replacing you, before that becomes their plan.

Vendor plays Contract, register and continuity plays for everything you decide to buy.

Questions this page answers

Should we integrate with a competitor?

Integrate when shared customers need it and it lowers their cost of adopting your core, but keep the workflow and the data in your product. Model what the competitor earns by keeping the integration against what it earns by replacing you, and measure the integration like a channel partner, on sales, retention and cost. An integration that turns your product into a feature of theirs is a dependency, not a partnership.

Should we self-host an open-weight AI model?

Not as a first move. Owning hardware converts a margin question into a balance sheet question and insures against a risk most companies at this stage have not yet experienced. A smaller open-weight model as a fallback can make sense if it carries real traffic and your contracts allow a degraded mode.

Is building internal tools ever worth it?

Only when no tool on the market does the job and the job matters to customers. Support desks, CRM, monitoring and DevOps tooling are better bought, because engineering time spent there is time not spent on what customers pay for.

What gross margin should we expect on AI features built on bought models?

Roughly 53% on AI-delivered revenue, and we underwrite the AI line at 50% to 60% at entry, well below the margin on classic subscription software. That is why the inference cost belongs on its own line and why portability matters: a second provider carrying real traffic is also your leverage on price.

Reviewed by Dougal Cameron, CEO & Co-Founder on 2026-10-22. Golden Section observations are labeled separately from external benchmarks and illustrative arithmetic.