Retooling the enterprise: how big companies are replacing expensive SaaS with vibe-coded software

For a decade the default answer to any new business problem was 'buy a SaaS for it.' Every team collected its own subscriptions, every CFO watched the software line grow, and every CIO inherited an integration mess. That default is finally breaking. In 2025 and into 2026, large enterprises have started retooling — pulling work back in-house and rebuilding narrow SaaS tools themselves with AI-assisted development, often called 'vibe coding.'

This isn't a fringe experiment. It's showing up in earnings calls, industry surveys, and engineering blogs from some of the biggest names in tech and retail.

The signal: real companies, real dollars

Starbucks is the loudest recent example. The company has been building what it calls a 'sovereign AI' stack in-house, and Wall Street coverage in July 2026 pegged the target at roughly $400 million in software cost reductions — money that used to flow to third-party vendors [1]. That is not a hackathon side project. That is a Fortune 100 balance-sheet decision.

Hudson Labs, which mines quarterly filings, published a running list of public companies telling investors they are moving off third-party software and building internally instead — spanning retail, financial services, and industrials [2]. When the trend shows up in 10-Qs, it has left the blog-post phase.

The most quantified data point comes from Retool's 2026 Build vs. Buy Report: 35% of enterprises say they have already replaced at least one SaaS tool with custom-built software, and 78% expect to build more internal tools in 2026 than they did the year before [3][4]. Retool frames it plainly — vibe coding and shadow IT have reshaped enterprise software.

Why now: vibe coding changed the math

The term 'vibe coding' was popularized by Andrej Karpathy in early 2025 to describe a new way of building software — describing intent to an AI assistant and iterating on the result rather than typing every line yourself [5]. In an enterprise setting, that shift changes the build-vs-buy calculation in three ways:

• The cost floor to build a narrow internal tool dropped from 'a full sprint team' to 'one operator plus an AI assistant for an afternoon.'
• The people closest to the problem — ops, finance, sales — can now prototype the tool themselves, so requirements and implementation collapse into one step.
• Per-seat SaaS pricing keeps rising, so the crossover point where a custom build is cheaper than renewing a subscription keeps moving down.

CIO's March 2026 feature on the trend describes the same pattern from the buyer side: leading-edge organizations are letting business units write their own apps and integrations with AI assistants, replacing point SaaS tools and glue code that used to require vendor contracts [6]. Tech Monitor's coverage adds the enterprise-IT view — governance, security, and support are the hard parts, not the code itself [7].

What is actually getting replaced

The SaaS most at risk is exactly the kind most companies overpay for: narrow, per-seat tools that solve one workflow. Think approval trackers, small CRMs, internal knowledge bases, custom dashboards, ticket routers, form builders, ops checklists, invoice trackers. Belitsoft's analysis of enterprise vibe coding vs SaaS makes the same point — the more narrowly a SaaS product is scoped, and the more it charges per user, the easier it is to justify replacing it with a bespoke internal build [8].

What is not going away: deep platforms with heavy compliance, network-effect data, or years of specialized R&D behind them. Nobody is vibe-coding their own Salesforce core or their own Snowflake. But the twenty adjacent tools bolted onto them? Those are on the table.

The risks are real — and manageable

Every serious piece of coverage on this shift ends in the same place: the code is the easy part. Without engineering discipline, vibe-coded internal tools can turn into a sprawl of shadow IT with security holes, no owner, and no upgrade path [6][7][8]. Atlassian's own engineering blog on running self-hosted AI infrastructure is a good reminder that at enterprise scale, the platform underneath the AI matters as much as the prompts on top [9].

The companies getting this right are pairing operator-built prototypes with lightweight engineering guardrails — a shared component library, an auth and permissions model everyone reuses, deployment on managed infrastructure, and a real review step before anything customer-facing ships.

What this means for operators right now

• Audit your SaaS bill. Every narrow per-seat tool is a candidate — the ones where you use 10% of the features are the best targets.
• Pick one workflow, not ten. The wins come from replacing a single painful tool end-to-end, not from a boil-the-ocean platform.
• Give your operators the tools and the guardrails. AI-assisted building without design system, auth, and hosting standards produces the shadow-IT mess everyone warns about.
• Measure the actual saved spend. The Starbucks and Retool numbers only exist because someone tracked them. Do the same on your own P&L.

The build-vs-buy pendulum has swung before. What is different this time is that the tools have finally caught up to the operators. The enterprises that figure out how to let their own people build — safely — are the ones showing up in these reports with millions of dollars taken out of their software line.