FIELD NOTE / 2026.09.185 MIN READ / 5 SOURCES

Why Artificial Intelligence Broke the Traditional SaaS Profitability Model

Generative AI looks like subscription software on the surface, but training, inference, model refreshes, and compute-heavy usage make its margin structure materially different from classic SaaS.

SaaS trained investors to expect extraordinary operating leverage

Traditional subscription software created one of technology’s most attractive financial models. Once a software product was built, adding another customer often required little incremental delivery cost relative to the subscription price. Sales and R&D could remain expensive, but gross margins frequently became high enough that mature companies had room to convert scale into operating profit. McKinsey’s Rule of 40 work reflects this tradition by treating growth and margin as complementary measures of software quality rather than as permanently opposed goals.[1]

The classic SaaS promise was that delivery got cheaper relative to revenue

A customer could use the software heavily without forcing the vendor to purchase a proportional amount of new computation for every interaction.

Generative AI attaches a cost to usage in a way classic software often did not

Every AI request invokes models running on specialized hardware. The more tokens, images, video frames, or agent steps customers consume, the more computation the provider must supply. Stanford’s AI Index documents a dramatic fall in inference prices for a fixed capability level, but the cost remains an operating variable rather than disappearing entirely.[2] This means revenue growth generated by heavy usage can bring substantial cost of revenue with it.

Frontier training adds a second cost engine above ordinary product development

Epoch AI estimates that training costs for frontier models have grown by roughly 2 to 3 times per year, with hardware and research staff making up most of the development expense.[3] A SaaS company certainly spends on R&D, but it usually does not need to rebuild a frontier-scale computational artifact every time the competitive bar moves. AI laboratories may face repeated cycles of training, evaluation, data preparation, and deployment before the new system earns a dollar of revenue.

The product can become obsolete before its training bill is economically recovered

Fast model cycles shorten the time available to amortize research expense. A release that looks technically dominant today may be price-competed or surpassed within months.

Gross margin therefore carries more information in AI than ARR alone

Annual recurring revenue became a favorite SaaS metric because it helped investors estimate the size and predictability of subscription relationships. But ARR does not reveal how much compute is required to serve those customers. Klover’s analysis of OpenAI emphasizes that impressive revenue can coexist with very large compute commitments and losses.[4] For AI, two companies with identical ARR can have dramatically different economics if one serves requests with inexpensive models while the other relies on costly frontier inference.

AI agents can make usage deeper as well as more valuable

Agentic systems do more than answer one prompt. They may plan, call tools, retrieve data, invoke several models, retry failures, and maintain long-running workflows. That creates an opportunity to charge for a much more valuable outcome, but it can also multiply inference and infrastructure usage. The profitability question becomes whether the economic value of the completed task grows faster than the cost of the sequence required to produce it.

Outcome pricing may be more natural than seat pricing

If an agent completes work previously performed by a person, the customer’s willingness to pay may relate to the business outcome rather than the number of users logging into a dashboard.

Model competition can improve margins and destroy pricing power at the same time

Falling inference costs are good for providers because each task may become cheaper to serve. They can also lower barriers for competitors. Stanford’s data show just how rapidly capable inference became cheaper.[2] When many vendors can access similar base-model performance, customers may expect lower prices. The winning company must therefore capture enough differentiated value through data, workflow, distribution, or product design to keep part of the efficiency gain rather than passing all of it to customers.

The accounting vocabulary must adjust to AI’s physical infrastructure

The SEC’s financial-statement framework separates revenue, cost of revenue, operating expenses, and cash flow because each answers a different question.[5] That distinction becomes crucial for AI. Training may appear in R&D, serving costs may appear in cost of revenue, data centers may require capital expenditure, and stock compensation may heavily affect reported expenses. A single headline metric cannot describe the entire economic engine.

AI looks digital to the customer and industrial to the balance sheet

The interface may be a chat box, but behind it sit chips, servers, networking, power, cooling, and specialized engineering labor. Profitability analysis must follow those physical costs.

Why AI needs a profitability framework beyond SaaS

The traditional SaaS model remains useful because recurring revenue, retention, and operating leverage still matter. It is insufficient because AI adds variable computation, rapid model depreciation, and unusually heavy research infrastructure. McKinsey’s growth-versus-margin discipline still applies, but the path to better margins may depend as much on model efficiency and architecture as on reducing sales expense.[1][3]

AI did not make software economics irrelevant. It made them more demanding. Investors now need to ask not only whether customers renew, but how much every unit of intelligence costs to create and deliver. The companies that solve that equation will look less like permanently subsidized research projects and more like the durable software businesses the SaaS era taught markets to value.

RESEARCH / PROVENANCE

Works Cited

5 SOURCES
  1. 01
  2. 02
  3. 03
  4. 04
  5. 05

CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.

Contribute / Corrections

Improve the record.

Use this moderated submission form to suggest a correction, provide a source, challenge a priority claim or identify a missing contributor. Submissions are treated as research leads, not automatically published comments.

Submit a research lead

Please do not submit confidential material or claims you cannot support.