Beyond SaaS

Software Innovation and Business Models

Software innovation begets business model innovation. For the past 70 years, start-ups have taken advantage of abstractions in computer architecture to dislodge incumbents with new pricing and packaging that (1) lowers the barrier for software adoption and (2) better aligns with the value customers receive from software.

There have been five epochs of B2B software business models: hardware and software bundling (1950-1970s), bespoke software services (1960s-1980s), licensed software products (1980s-2000s), SaaS (2000s-present), and usage-based pricing (2010s-present). LLMs should create a sixth. 

LLM-native companies are in the early days of business model innovation. Model providers such as OpenAI and Anthropic still rely on subscription and usage-based pricing models akin to traditional SaaS vendors and cloud providers for now. But business models will change as AI capabilities improve. LLM-native application start-ups are leading the way. Their efforts to find business-model-product-market-fit suggest how pricing and packaging may evolve beyond SaaS as a result of this technology:

• SLA pricing: Software companies often price discriminate with different tiers of reliability (e.g. “two-nines” versus “five-nines”). LLM companies could go a step further and construct pricing tiers around latency, accuracy, and relevance. This approach would only require modest incumbent adaptation, making it the least disruptive business model.

• Output-based pricing: Output-based pricing is usage-based pricing++. Rather than meter resource consumption, LLM companies could better align their business models with customers by billing for outputs that are directly relevant to a buyer’s business metrics (e.g. qualified sales leads in the case of a sales automation company). Prospective buyers could purchase based on clear expectations of top line ROI. Incumbents would need to meaningfully alter their GTM and product architectures to compete with this strategy.

• Agent renting: Why buy software for humans when you can rent a task-specific agent to do (parts of) their job? “Agent leasers” are both the most futuristic and disruptive business model (and became a lot more plausible with the launch of OpenAI’s GPT assistant marketplace). In this version of the world, AI applications would probably price as a percent of labor spend, delivering prospective buyers concrete bottom line ROI.

A Brief History of Software Business Models

Every paradigm shift in software architecture created an opportunity for a new entrant to redesign pricing and packaging. 

Tight coupling between software and hardware (1950s-1970s)

In the early days of computing, computer manufacturers such as IBM and DEC sold purpose-built software that ran only on their hardware. Each hardware model required specialized operating systems (OS), limiting software compatibility across different machine types (standardized x86 and ARM architectures would only emerge later). Businesses accordingly had to collaborate with OEMs to build software. For example, American Airlines partnered with IBM to develop its reservation system program, Sabre, which initially could only run on the IBM 7090.

NASA used IBM computers to build the software for the Apollo program

Bespoke software services (1960s-1980s)

An incipient software market formed as new vendors used time sharing and advances in networking to manage mainframe resources as a service for customers. Famously, Ross Perot realized that most IBM customers didn’t run their computers at full utilization, creating an opportunity to use Local Area Networks to match unused resources from one company with others that needed this capacity. Perot started Electronic Data Systems, one of the world’s first software vendors, to outsource the complexities of resource pooling for customers and create custom software that took advantage of shared computing. However, vendors like Electronic Data Systems didn’t solve the architecture standardization problem. Instead of selling software products that could work across many customers, they sold custom software projects to individual buyers.

Electronic Data Systems workstations

Licensed software products (1980s-1990s)

The standardized OS, which acts as an abstraction layer between software and the hardware it runs on, paved the way for mass software products. Vendors were finally able to build a single piece of software and sell it to many customers. Microsoft capitalized on this possibility to become the world’s second largest company. MS-DOS (and later Windows) unbundled the OS from the machine (displacing IBM) and became the default computing interface for businesses and consumers. Customers could now purchase software applications off-the-shelf for an upfront license fee.

Windows 1.0 was released in 1985 and quickly became the dominant OS

SaaS (2000s-present)

With the rise of the internet and virtualization, software licenses gave way to SaaS. Though the license model marked a step function improvement from custom software services, it still created friction for buyers and vendors. Buyers needed to host, maintain, and store data for software applications. Vendors relied on a supply chain of distributors to sell their products. SaaS obviated both problems. Buyers could outsource much of their IT burdens to vendors and vendors could sell their products directly. Salesforce vocally spearheaded this transition with its “end of software” marketing campaign, which included a staged “protest” outside of a Siebel Systems conference.

Salesforce declares “the end of software”

Usage-based pricing (2010s-present)

While SaaS was mostly priced per seat, the shift to the cloud and software monitoring tools enabled usage-based pricing models. Cloud computing instances like EC2 are billed per second, so software applications built on top of these services can pass along that pricing granularity to customers (“only pay for what you consume”). Similarly, modern software monitoring tools capture real-time resource utilization metrics, making it easier to meter customer activity. Snowflake pioneered usage-based pricing by building its data warehouse on top of the cloud providers, allowing it to autoscale querying services up and down based on user requests and charge per query.

Snowflake’s usage-based business model allows customers to only pay for what they use

What will be the dominant business model for LLM applications?

Classical software interfaces require a user to manually specify a deterministic set of steps to accomplish a task. LLMs, by contrast, let users tell computers what they want the computer to do and leave it to the computer to figure out how to do it. This makes LLM applications naturally more outcome-oriented than their SaaS predecessors. As a result, LLM-native software vendors should move away from input-based pricing (e.g. number of seats) and towards output-based pricing.

But what exactly will LLM application business models look like? We’re seeing at least three plausible candidates take shape.

Price to SLAs

Cloud and database providers offer pricing tiers that differentiate on service SLAs. LLM apps could analogously charge for the quality output SLAs (such as latency and accuracy) rather than the quantity of outputs. Midjourney and Ideogram already price their premium subscription tiers based on access to “fast GPUs”. The ChatGPT Plus subscription plan promises “general access to ChatGPT, even during peak times” (uptime) and “faster response times” (latency). Since these particular SLAs are implicitly about receiving priority GPU compute, there is less room for new entrant counter positioning: the SLA business model lends itself to a continuation of seat-based pricing and incumbents can access GPUs better than disrupters. More creative SLA guarantees (e.g. quality of response) might prove tougher for incumbents to copy.

Examples: Midjourney, Ideogram, ChatGPT

Midjourney pricing chart

Output-based pricing

Output-based pricing is about delivering top line ROI to customers. Whereas usage based pricing charges for inputs (e.g. compute resources), output-based pricing charges for units of business-relevant outcomes. This might mean qualified leads delivered for a sales software company, PRs merged for a code generation company, or renders created for a design services automation company. Outcome-based pricing should be attractive to buyers since it allows them to better match their software costs with the value produced by that software. Since most software today is designed to serve a human stakeholder rather than create that stakeholder’s work product, outcome-based pricing also facilitates GTM counter positioning versus incumbents. Companies that adopt output-based pricing will ultimately be most successful if they can obviate seats whereas SaaS products win by maximizing seats.

Of course, being accountable for outputs raises the stakes for software vendors (SaaS companies still collect revenue even if customers don’t get value from using their product). Only the most impactful tools will be able to price to outputs at first. But the ones that can should enjoy a decisive GTM advantage.

Examples: Cresta, Eleven Labs, EvenUp

Eleven Labs pricing page

Agent renting

Renting AI agents means showing customers bottom line ROI. Specialized agents could substitute humans for certain tasks (and perhaps eventually entire jobs). The companies that build these agents will rent them out, likely pricing them as a percentage of the labor they are replacing. This business model requires advances in agent capabilities to be viable. Once it is, disrupters will be able to strongly counter position against incumbents:

• Agent leasers will probably sell to executive stakeholders to automate the very users who incumbents consider their customers.

• The GUI may cease to be the dominant interface for B2B software. Instead, agent leasers might vertically integrate entire functions (e.g. a fully outsourced customer service department) and deliver their outputs via API. This is a rare example of business model innovation driving product architecture instead of the other way around.

Examples: OpenAI (via GPT marketplace)?

Return on Software Spend

Through time, software business models have increasingly aligned vendor and buyer incentives. Licenses, for instance, don’t require customers to front the capex for bespoke software. Usage-based pricing allows buyers to better tailor spend to their business needs than SaaS (which rarely price discriminates depending on usage). LLM business models will represent another leap forward: vendor revenue will be tied to the business outcomes driven for customers.

We may thus be headed towards a future where customers view software spend similarly to marketing spend. If software vendors start to price based on outcomes, buyers should be able to precisely measure the revenue-generating impact of a new vendor and invest dollars accordingly. Just as growth teams use metrics like ROAS (return on advertising spend) to toggle marketing spend up or down depending on the effectiveness of a marketing channel, we could soon see the emergence of a measure like ROSS (return on software spend) whereby buyers continuously adjust spend on AI software vendors according to the observed impact on their business metrics – top line or bottom line. The hand-wavy ROI calculations that characterize SaaS procurement today should disappear.

To get there, we’ll need a Marc Benioff for the AI era – someone who agitates for “the end of SaaS”.

Thank you to Sam Packard, Abhishek Modi, and Samay Shamdasani for sharing their feedback. The premise for this piece was also partly inspired by a conversation I had with James Cham at Bloomberg Beta.