Build vs Buy Software: Should You Build on the Web Platform or Rent SaaS?

Should you build on the web platform or rent SaaS?

Build on the web platform instead of renting SaaS because AI coding tools have collapsed the cost of building software. Paying per seat, forever, for a problem you could own outright isn't a shortcut anymore. It's a tax. A growing number of engineering teams have noticed.

What is the SaaS bill nobody meant to sign up for?

Start with the number nobody budgets for on purpose. The average company now manages 305 SaaS applications, and that figure jumps to 696 at large organizations, a sprawl that has grown by double digits year over year for most of this decade. Nobody sat down and approved 305 subscriptions. They accumulated, one Slack message and one free trial at a time.

The waste that sprawl produces is not a rounding error. Companies burn somewhere between $18 million and $19.8 million a year on SaaS licenses that sit unused, and on average, roughly half of all purchased licenses never get touched. Shadow IT, the tools employees buy on an expense card without telling procurement, still accounts for about a third of the typical company's SaaS stack even after cost-cutting pushes. Two-thirds of organizations call that purchasing pattern a major governance headache.

This is the backdrop "just buy it" has operated against for years: pay to make the sprawl someone else's problem, and call the waste the cost of doing business.

Why did "just buy it" become the default?

That instinct wasn't irrational. For most of the SaaS era, building software in-house meant hiring senior engineers who were scarce, expensive, and slow to ship. A dashboard that would take a contractor two weeks and $400 a month to rent took a real engineering team a quarter to build and a platform team to maintain afterward. Renting the abstraction, the CRM, the survey tool, the internal admin panel, was the economically rational move. The build option wasn't actually on the table for most teams; it just looked like it was.

That premise is the one now breaking.

Is the web platform now powerful enough to build on?

While the SaaS industry scaled, the browser scaled with it. Features that used to require a JavaScript framework or a third-party library are now native: View Transitions, Declarative Shadow DOM, CSS :has(), @container, and @scope, Web Components, Compression Streams, Broadcast Channels. The W3C-backed Baseline tracker now follows more than 1,000 of these platform features, and the count supported across all major browsers has grown from roughly 400 in 2020 to nearly 700 today.

Developers who've moved off heavy framework stacks and back onto native APIs report big gains. One case cited by developer and critic Baldur Bjarnason: an ERP vendor's page load dropped from 4-5 seconds to 400 milliseconds after ditching React for native DOM APIs. His argument is blunt: if you're tired of your frontend going obsolete every few years, get back to fundamentals and work closer to the platform, with fewer abstractions between you and the browser. Other practitioners go further, arguing native browser APIs now cover routing, component scoping, form handling, and app-like transitions well enough to replace React, Vue, and Angular for a large share of use cases.

The platform got powerful. What it still lacked, until recently, was a way to write to it fast enough to compete with a credit card and a SaaS signup page.

How did AI coding tools break the build-vs-buy math?

That's the piece that changed. In a Retool survey of 817 builders, 35% of teams had already replaced at least one SaaS tool with a custom AI-assisted build, and 78% planned to build more custom tools to replace SaaS in 2026. Workflow automation (35%) and internal admin tools (33%) topped the list of SaaS categories most at risk. Half of the builders who shipped production AI-built software reported saving six or more hours of work per week.

The scale of this is visible beyond survey data. More than 10,000 new websites and apps are deployed per day through AI coding tools on Netlify's platform alone, and a large share are internal tools companies built for themselves instead of buying from vendors like Qualtrics, Momentive, or CPQ providers. That tracks with a broader shift happening across the industry, as autonomous coding agents ship production software with almost no human review. Netlify itself used AI coding tools to build its own internal employee survey tool rather than license one. Even sophisticated buyers are opting out of category leaders: a16z general partner Martin Casado built his own AI-powered CRM instead of using Salesforce, writing that "for some software, it's becoming quicker to code my own version with AI than learn someone else's non-intuitive, shit UI." The piece on why AI is now the SaaS killer walks through exactly this math for internal tools, and the conclusion holds up: the build option is now actually on the table, for far more teams than before.

What do 37signals and a16z show about the cloud rental trap?

Renting infrastructure follows the same arithmetic as renting SaaS, and the companies that measured it closely found the same pattern: cheap when workloads are small and unpredictable, punishing once they're not.

37signals calculated it would save roughly $7 million over five years by buying about $600,000 of Dell hardware and leaving AWS, without growing its ops team. As the bills kept compounding, the firm revised that estimate upward, eventually projecting savings closer to $10 million over five years, or roughly $1.5 million a year.

Andreessen Horowitz's "trillion dollar paradox" analysis found the same dynamic at public-company scale: cloud rental costs suppress the market capitalization of the 50 top public software companies by an estimated $100 billion, and by more than $500 billion across the broader software and internet universe, because cloud spend commonly eats 50-80% of cost of revenue once a company scales. The honest answer to that math is never just yes or no, it's a utilization number, and most internal workloads blow past the break-even point faster than teams expect. Dropbox is the textbook example: repatriating most of its infrastructure off public cloud saved it roughly $75 million over two years and lifted gross margin from 33% to 67%. The firms a16z consulted converged on a rule of thumb: owning infrastructure costs one-third to one-half of renting the equivalent workload in the public cloud, and cloud list prices can run 10 to 12 times the cost of owning equivalent on-prem capacity before volume discounts. A 2024 Barclays survey found 86% of CIOs, the highest share ever recorded, now plan to move at least some workloads back on-premises, and IDC separately found 70% of enterprises already shifting that direction. For a broader map of what that looks like category by category, see the self-hosted alternatives guide.

Is shadow IT the market already voting with its feet?

If this were just a theory, you'd expect to see it stay a theory. Instead, 60% of builders surveyed by Retool had already built software outside official IT oversight in the past year. Employees aren't waiting for a build-vs-buy memo from procurement. They're already doing the build side of the comparison on their own time, with tools their IT department didn't approve, because it's faster than filing a ticket and waiting for a vendor demo.

What does owning your stack actually mean in practice?

Not everything should be built. The useful distinction is between software that is a commodity record system and software that is a reflection of how your specific team works. In practice:

• Build internal tools, dashboards, and workflow automation. These are the categories where SaaS replacement is already happening fastest, and where Retool's data shows the highest share of teams already shipping replacements.
• Build the glue between systems. Reporting layers, approval flows, and admin panels that exist to compensate for a vendor's missing feature are prime candidates, since they're bespoke by definition.
• Keep buying systems of record where switching cost and compliance risk are high. Payroll, core accounting ledgers, and anything with heavy regulatory surface still favor a vendor who specializes in staying compliant.
• Keep buying what genuinely needs network effects. Tools that are valuable because everyone else uses them, not because of their feature set, don't get cheaper to replace just because building got easier.

This is roughly the framing Netlify's leadership has pushed publicly: AI coding didn't make every SaaS category replaceable overnight, it made the ones built around internal, idiosyncratic workflows replaceable now, and the rest later.

What is the governance tradeoff between speed now and maintenance later?

None of this is a free lunch, and the data that proves the build case also contains the warning label. AI lowers the upfront cost of writing software. It does not lower the ongoing cost of owning it. The top blockers preventing companies from scaling their AI-built tools into durable production software are unclear ROI (33%), budget constraints (30%), and maintenance burden (26%). A full 35% of organizations surveyed still haven't established any AI productivity metrics at all. Globant's leadership has separately cautioned that speed without governance just moves the risk from procurement to engineering, it doesn't remove it. The practical fix isn't to stop building. It's to treat what you build the way you'd treat anything else on the balance sheet: with an owner, a maintenance budget, and a decommissioning plan.

Why treat software as an asset, not a subscription?

The old logic was: building is expensive and slow, so rent the abstraction. That logic depended on scarce engineering time being the bottleneck. AI-assisted coding and a web platform that now natively does most of what frameworks used to charge for have removed that bottleneck for a large and growing share of internal software. What's left standing is the per-seat invoice, still arriving monthly, for problems a team could now own.

Owning software you build is not free. But it compounds in your favor instead of a vendor's. Rent, on the other hand, is a cost you never stop paying for a decision you only made once.