Every quarter I sit in a room watching a team decide whether to subscribe to another SaaS box. The pitch always lands the same way: buy the tool, save engineering time, ship next week. It worked in 2019. It barely works now.
McKinsey State of AI 2026, an August 2026 survey of more than 1,700 executives across 97 markets, puts a number on the shift: 32% of organizations said they decided not to buy software because they could build it in-house with agentic coding tools. The same report says 80% believe AI improved individual productivity, yet the share reporting an enterprise EBIT impact stayed flat at 37%, and only 6% qualify as AI high performers. Translation: the tooling to build has arrived. The discipline to turn that into margin has not.
The other end of the equation got louder in spring and summer 2026. On 2026-05-20, Intuit announced cuts of about 3,000 jobs, roughly 17% of its workforce, alongside $300 to 340 million in restructuring charges and multi-year AI partnerships with Anthropic and OpenAI the same day. On 2026-05-08, Cloudflare cut 1,100 people, about 20%, while reporting record Q1 2026 revenue of $639.8M, up 34% year over year, and said internal AI usage had grown 600% in three months. On 2026-09-17, Monday.com announced roughly 630 cuts, about 20%, to pivot to an AI Work Platform. Vendors that sell you the workflow are the same vendors whose headcount your build-or-buy decision is quietly reshaping.
Why the default of buy stopped making money
The subscription premium is real. You pay for a generic version of a workflow you do not use exactly, and you absorb vendor churn on top. Renewal bumps, seat count creep, and feature bloat all flow into your monthly opex line. And when the vendor’s own org is being compressed by the same AI you are considering building on top of, vendor stability becomes a variable, not a constant.
Intuit is the cleanest recent example. The company was restructuring toward AI-native delivery while simultaneously buying more seats from itself in other product lines. If your SaaS vendor is cutting 17% of its workforce, treat every renewal term longer than twelve months as a bet.
The four dimensions that decide a build
I use one scorecard for every candidate workflow. Four dimensions, each rated one to five. Any dimension at two or below means you buy.
Requirement stability
A workflow that changes its rules every quarter is a bad build candidate. If your spec is not stable, you will be paying engineering time to re-shape a moving target. Score this three or lower and reach for the vendor’s configurator.
Data sensitivity
If the workflow touches customer PII, financial ledgers, or regulated records, building changes the risk profile. You own the audit trail, the retention policy, and the incident response. That is worth it when a vendor would process the same data with a black box, and it is not worth it when a vendor already has compliance certifications you cannot cheaply replicate.
Ops capacity
This is where most builds quietly fail. Building something is a sprint. Owning something in production is a job. If no one on your team can answer on-call for the workflow during a weekend, you are not really building; you are outsourcing a future outage.
Integration dependency
If the workflow needs five or more third-party systems, each with its own API drift risk, the integration surface outgrows the logic itself. Build only when the integration set is two clean systems or fewer.
Scoring the workflow end to end
Once you score the four dimensions, do the arithmetic. Take the monthly volume of runs. Multiply by an honest estimate of tokens or API calls per run. Compare that figure to the per-seat price of the SaaS tool, on the same monthly basis. Then add the human labor to review, patch, and babysit the build. That last line is where most teams undercount.
A build only wins when the total cost per run over a twelve-month horizon beats the seat price, and the ops load stays inside a weekly hour or two. If your monthly volume is low, no model pricing wins. If your monthly volume is high and your data is boring, almost any build wins.
Setting a hard cap on token spend
Roughly 20% of organizations in the McKinsey survey said they were constrained in AI use because of operating or token cost. That is the number that decides your cap.
Fix the monthly spend ceiling before you roll out, not after the bill arrives. Pick the cheapest model that still clears your quality bar. Run the workflow on that model as the default and only route heavier runs to a larger model when a specific quality gate is triggered. This keeps unit cost predictable as volume grows.
Defining the rollback trigger before you ship
I ask every team to write a rollback condition before their first production run. Accuracy below a threshold. Ops time above a weekly limit. Cost per run crossing a fixed line. Whatever you pick, put it in the same document as the decision memo.
Without a rollback trigger, a failed build becomes a permanent sunk cost. With one, it becomes a two-month experiment with a bounded downside. The build-versus-buy question is only fair when both sides have a defined exit.
When to buy, when to build, and when to cut
There is no universal answer. The table below is the version I bring to reviews.
| Dimension | Buy a SaaS | Build with AI |
|---|---|---|
| Up-front cost | Low, first month is a subscription | Higher: engineering time plus prompt and eval setup |
| Ongoing cost driver | Seats, renewal bumps, add-on modules | Tokens or API calls per run, plus a fractional ops owner |
| Ownership of the workflow | The vendor; you depend on their roadmap | You own the logic, the data, and the change log |
| Failure mode | Price creep, vendor exit, feature drift | Silent regression, unbounded token bill, orphaned code |
| Best when | Requirement instability, high data sensitivity, thin ops capacity | Stable spec, measurable volume, ops coverage in place |
The rule I land on: buy when ops capacity is thin, data sensitivity is high, or your workflow depends on a single vendor’s API. Build when requirement stability is proven, volume is measurable, and you have a real engineering hour budget plus a token cap. Cut entirely when neither option pays back in twelve months. If you are keeping a subscription that a small build could replace for less than the annual seat cost, drop the subscription.
The real constraint is not capability. It is cost discipline. About twenty percent of organizations are already capped by token and operating cost, so the winners are the teams that treat build as a budgeted experiment, not a hope. Pick your two or three highest-volume, most stable workflows, run them through the four-dimension check, set a monthly token ceiling, and watch the vendor list thin out. That is how you turn AI leverage from an individual productivity stat into a margin line.