The Case Against Usage-Based Pricing for AI

Every SaaS vendor today has an AI agenda, but most are stuck on the same question: how do you charge for it? The problem starts with cost. Running AI is expensive. The compute power behind large models burns through infrastructure budgets quickly, especially for advanced tasks like reasoning or deep research. One heavy user can rack up costs for the vendor in no time.

Most vendors deal with this by falling back on the good, old cost-plus pricing. They calculate what it costs them to run the service, add a margin, and pass it on to customers. As the LLM vendors measure usage by tokens, inference units, or API calls, metrics, many SaaS vendors that use the LLMs adopted the same pricing metrics. This is called usage-based pricing or consumption pricing. 

Because many pundits believe that AI and AI agents will replace traditional software, usage-based pricing is being heralded as the future of software. Startups like Metronome, Orb, and Lago specialize in usage metering, mediation, and billing. Their pitch is simple: “SaaS is dead, usage is the future.”, whereby they misleadingly equate “SaaS” with per-user subscriptions. 

Well, I disagree. Usage-based pricing is not the future of AI.

First, customers hate it. While “pay for what you use” sounds fair, it creates unpredictable bills. Businesses need to budget. They cannot run operations on costs that swing wildly. And consumers only tolerate usage-based pricing when the amounts are trivial. Once it becomes a line item, the scrutiny kicks in. Just think of utilities, transportation, or groceries. All usage-based, and none of them loved by the consumers. 

Second, usage-based pricing discourages usage. Imagine if Salesforce charged every time a sales rep updated a customer record. Or if Microsoft charged per PowerPoint slide. The vendors need users to enter customer data and create a lot of slides. The most successful AI software today is ChatGPT, which uses a simple subscription plan. Usage-based billing makes sense only when there are no users to tie pricing to, like in an API-only service. 

Third, usage-based pricing creates overhead. Vendors need to capture usage data, build metering tools, clean up the data (mediation), and deploy billing systems capable of handling complexities like pricing tiers, usage commitments, and overage rules. Customers then demand full visibility with dashboards, analytics, and self-service portals to monitor their usage. All of this adds cost for code that must be built and maintained without being monetized.

The history of other industries proves the point. Telcos once charged by the minute and kilobyte, but shifted to unlimited plans. ISPs used to charge by the minute, but now we expect always-on Internet. Apple used to charge per song; now we all pay flat monthly fees for Spotify or Apple Music. These are all powerful companies that can handle usage billing at scale, and yet they all abandoned the model in favor of a simple subscription. 

Usage-based pricing is not the future. It is a stopgap where vendors pass on their cost problem to their customers. Eventually, vendors will get better at predicting their own costs and offer pricing that feels stable and fair to their customers. That is exactly what happened with cloud infrastructure: AWS, Azure, and Google charge SaaS vendors one way, but those vendors turn around and price their products differently for end customers.

The vendors that make this shift faster will enjoy a clear competitive advantage.

Four Types of SaaS Companies

The traditional way of segmenting cloud companies is IaaS, PaaS, and SaaS where the main distinction is how much of the stack is provided by the vendor. But I want to examine a different way of segmenting cloud companies based on their target market. The four types of SaaS companies are:

• Consumer SaaS
• SMB SaaS
• Enterprise SaaS
• B2All SaaS

Depending on whom they sell to, cloud companies have very different characteristics and I examine them in this article. These characteristics have a profound impact on the companies’ strategy and their go-to-market approach. So, let's take a closer look:

Consumer SaaS

Consumer SaaS software (often called B2C) is the software all of us use every day on our smartphones and home computers. From Twitter to Spotify, Quicken to Über, and the Nest thermostat app to The Economist app, we are accustomed to using consumer SaaS applications so much that we usually don’t think about it as software. Often, we don’t actually buy the software - we either pay for it with advertising (Twitter or Facebook), we pay for the content (Spotify or The Economist) or we pay for the service or hardware that the software controls (Über or Nest). Still, there’s also consumer software we do pay for - increasingly as a subscription - such as Quicken or Adobe Lightroom.

What these applications have in common is a high scale. We often like to say “consumer scale” and that’s exactly what we mean - a scale that consumer SaaS applications work with can be quite impressive. We are talking millions of users and [really] big data. The applications usually run partly on your device/desktop and partly in the cloud that handles backend functionality at a high scale for things like data synchronization, subscriber services, provisioning, metering, billing, etc. 

This high scale represents a high barrier for entry, which is why some companies can dominate their market for a long time - just think of Quicken. Yet such examples are rare, usually reserved for software that established itself as a necessity with a high degree of “stickiness” and that manages to remain top of mind for the customers. That’s often the challenge for consumer security, anti-virus, or backup software. Because it runs in the background with little stickiness if any, consumers don’t develop any loyalty to it and are more than happy to switch to another vendor at a moment’s notice. 

Due to the massive scale, it is impossible to customize the software for every user. In fact, this is one of the key tenants of consumer software: every user gets the same experience. Sure, the UI might allow for some degree of personalization, i.e. setting default location, font size, or background color. But the functionality is always the same. My Twitter app is the same as your Twitter app even though we all follow different people.

The go-to-market effort of consumer SaaS companies is focused on two primary objectives: awareness as a way to attract customers and monetization, which varies from an advertising model to converting freemium users into subscribers. Consumers tend to be very fickle customers, difficult to please, usually highly price-sensitive, moving in packs when picking their software (just like fashion trends), often ignoring rational arguments over hype, and more than willing to churn when they don’t see the value or when there is simply something new that looks like a cool novelty. Consumer SaaS can be extremely lucrative but only for those few companies that keep winning over the long term.   

SMB SaaS

SaaS software for SMB targets small and medium businesses (SMB, eh?). In this market, you can find applications for every small business such as QuickBooks or monday.com but also a myriad of specialty applications targeting various verticals. For example, MindBody has software for fitness studios, ServiceTitan targets service companies, and InnoVint provides software for wineries.

The barrier to entry for SMB SaaS companies is usually lower than for consumer software or for enterprise software. The deployments are relatively simple, the customization needs are still only minimal, and the scalability requirements are modest. That’s why so many software companies fall into this category. The online software catalog Capterra lists over 35,000 software packages across over 700 categories - that’s 50 applications for each category! There is a lot of software companies out there that you have never heard of!

While many of the SMB SaaS vendors proudly sport a few logos of big companies in their marketing, don’t get fooled. These are not enterprise deployments. Usually, it’s a group deployment inside of a large company; often flying under the radar of corporate IT. But that’s not to say that all SMB SaaS software is built poorly. In fact, many enterprise SaaS companies start by selling to SMBs, because it’s really hard for an unproven startup to sell to an enterprise. But the shift from SMB to enterprise ultimately exposes whether or not the software has been built as enterprise-grade. After all, the software architecture cannot be an afterthought.  

The go-to-market at SMB companies is primarily focused on finding target prospects and convincing them to give the software a try. The buyer is often the company CEO or owner and the software is rarely free. While every business needs some bookkeeping software, convincing them that` they need reputation management requires a very convincing pitch. That has to be done at scale because SMBs, by definition, don’t have many users and so you need a lot of them to reach scale. On top of that, SMBs are notorious for churning. They will give it a try and cancel if they don’t see quick results. Since SMB software doesn’t require much deployment effort, churn rates up to 40% are not unheard of in this market. At that churn rate, you need to keep feeding the beast constantly with new prospects and customers to keep growing. 

Enterprise SaaS

Enterprise SaaS companies target enterprises. While every vendor has its own definition of where SMB ends and enterprise starts, this software is meant to address the requirements of even the largest companies. That involves scalability in terms of the number of users, transactions, processes, or the amount of data under management. True enterprise software can cater to customers that truly stretch the limits of its architecture.

While the enterprise software scalability doesn’t often reach the scale of consumer software (after all, no enterprise has 100 million users), enterprise software also needs other requirements: security, high availability, compliance, and - most importantly - extensibility. Extensibility is the key characteristics of enterprise SaaS; something that really differentiates it from SMB and consumer software. Because in the enterprise, every deployment is different. Even when deployed at two companies for the same use case in the same industry, the two deployments won’t be the same. And that is hard to do.

Enterprise software pretty much always requires professional services to deploy. Yes, it’s still running in the cloud and the customers don’t have to worry about the hardware, the infrastructure, disaster recovery, provisioning for peak demands, upgrades, and patches. But enterprise software needs to be integrated with other enterprise software, it needs to be customized for the “last mile” of specific requirements, and it needs to be agile enough to quickly respond to any market changes. 

That’s why software from Oracle, ServiceNow, ServiceMax, and Zuora is built on an extensible platform and comes with developer tools for no-code, low-code, or high-code developers. That’s why all these companies provide their own professional services and also partner with global and local system integrators to deploy, integrate, and customize the software.  

On the go-to-market side, enterprise software requires less branding and awareness and much more high-touch marketing (i.e. ABM or, account-based marketing) and sales effort with long sales cycles and complex sales processes involving RFPs, customized demos, proofs of concept, and multi-stage deployments. Because of the high effort to deploy, customize, and integrate, enterprise software tends to be very sticky. Churn, if any, usually comes from a mismatched fit - for example when an SMB company purchases enterprise SaaS only to realize that they don’t use most of the capabilities.

B2All SaaS

There are SaaS companies that managed to build software for everyone - from consumers and small businesses to enterprises. This was what made Microsoft Office the king of software for decades. We used Office at home and at work, no matter how small or big the company was. We were vested in it because we learned to use it well which made it very sticky. Our colleagues and friends used it too and sharing documents in the Office format forced us even more to use Microsoft. For years, there was just no alternative.

Today, the companies that sell to everyone are companies like Box, Dropbox, Slack, Zoom, Docusign, Evernote, Google Suite, and Microsoft Office 365. Since they address the requirements of a really broad market, the B2All software has to be easy to deploy and use. Every user still gets the same experience with no customization of functionality, no matter whether they use the software at home or at work. But this software also has to satisfy the requirements of an enterprise such as integrations to other applications and systems, compliance for regulated companies, or enterprise security features such as SSO. 

Obviously, all of this is not easy to do. The B2All software has the satisfy the scale, ease of use, and seamless experience for the B2C audience as well as the complexity and extensibility expected from a B2B software. It also needs to manage the situations when B2C users use their private software accounts in the enterprise and share information with their co-workers. This is the so-called “roque software”, the nightmare of all IT departments!

To do all that, B2All software has to be well designed with a solid architecture to satisfy all markets. It needs to scale like enterprise software and provide at least some of the extensibility of enterprise software. That makes for a very high barrier to entry, which is why not many companies make it. But those that do, are often rewarded with great brand awareness and high trading multiples.  

On the go-to-market side, B2All is all about leveraging the network effect to convert individual, private users to an enterprise license. Sign up as many users as possible using the B2C marketing tactics, make them use the product at work, share with each other, and then convert companies with enough users to an enterprise license. The B2All SaaS companies have to master marketing and sales strategy for consumers and for enterprises.

Well, those are the four types of software companies, based on their target markets.

Customizations - Heaven or Hell?

There are many traits that make enterprise software different from consumer software or even software packages used by small organizations. Scalability, security, and the ability to integrate with other software usually come to mind. But none of them are as polarizing as the ability to customize enterprise software deployments.

The idea is pretty simple. As organizations compete with each other, they want to tailor the deployed solutions to match their business processes and other organization-specific needs. Enterprise software vendors usually design their software in a way that allows for a significant amount of customization with technologies such as modular architecture, web services, application programming interface (API) and software development kits (SDK).

You might think that all of this is going away in the new world where software is delivered as a service (SaaS). It is certainly true for the SaaS software that targets the small and medium sized businesses or simple generic applications. But if we consider the leader in SaaS - Salesforce.com - as the sign of the things to come, we must realize that most of the Salesforce deployments today are being heavily customized.

Customizations are important. In fact, a big part of the appeal of open source software is the ability to significantly customize it; even re-write entire functionality modules given that the developers have the actual source code. Of course, customizations matter in the world of commercial ‘closed source’ software just as much.

Customizations, however, come at a price. Not only does a typical enterprise deployment often require an investment into professional services that comes at a multiple of the cost of the software licenses, customizations also carry a significant hidden cost.

Every time the software goes through an upgrade cycle, the customizations have to be upgraded as well. There is no easy way around it even if the vendor provides tools to make the work easier. Those are your customizations, they are a one-off type of software and nobody but you can upgrade them. Often the work to migrate the customizations can be significant. If the customizations actually contain significant amounts of original code, migrating them may be akin to a complete re-write.

Consequently, customers tend to struggle to keep up with the vendors who are trying to maintain the pace of innovation. It is important, that the customers are allowed to do that - not to keep up. The ability to skip a version is becoming a critical requirement for enterprise software. Many vendors handle it by providing the notion of safe-harbor releases that ensure that from here, you can move to the next level at your own pace.

In the end, there is no magical solution. Customers shouldn’t avoid customization because they do need the competitive advantage that highly customized software can provide. In many industries such as insurance or financial services, there is very little differentiation possible on the product side. Car insurance is just car insurance and mortgage is just a mortgage. Only the customer experience and the process efficiency can differentiate competitors. Those differentiators require customized software. But customers have to think beyond the customizations of the current release. The ease of migrating customizations is one of the key issues overlooked by many vendors in their slick demos.

The Real Problem with the Cloud

I am a big fan of cloud computing. The idea of having software provided as a service without having to actually deploy it makes a lot of sense. But, I often encounter skeptics who keep bringing up what I think are the wrong anti-cloud arguments - security concerns, availability issues, or perhaps the lack of customizations. The troubles that Amazon, Sony or Twitter just recently experienced are only fueling such arguments.

While those are valid concerns today, they are just growing pains. They are often exaggerated by the media and the blogosphere. In time, the cloud offerings may be able to address these issues better than any on-premise deployment. Take security, for instance, which is perhaps the most common issue raised by the cloud skeptics. Every one of my employers in the US used a SaaS based solution for payroll. And since that particular vendor caters to millions of users, I trust their security more than I would have trusted any one of my employers.

The one thing, however, that worries me about the cloud-based solutions today is the ability of a customer to part ways with their cloud providers. Nothing lasts forever and it is very likely that every customer will come to a point where they will want to get their data, templates, process definitions, business rules, users profiles, permissions, and customizations off the cloud vendor and move them into some other cloud.

The reasons may be many. The vendor could go out of business - it’s not like all those cloud start-ups are widely profitable today and some of them will just not make it. The vendor could also decide to shut down the service just like Google discontinued Wave and Video. The vendor could be acquired by someone else who changes the business terms. Or, the customer’s requirements evolve and the vendor no longer meets them. In any case, getting off a cloud where you have invested a ton of data and work isn’t trivial.

Nobody is talking much about this today. Of course, all the vendors are keen to attract and keep customers. Nobody wants to advertise the ability to let customers go easily. But that’s exactly what they need to do to get serious enterprise customers. They need to provide the right APIs, tools, services and terms that make an easy farewell possible.

This is the one cloud challenge that has me worried. On-premise software is also tough to leave but at least the customer owns the system and the data and has usually a plenty of time to figure out how to dump their vendor. A 30 day notice is not what enterprise customers will be comfortable with.

To SaaS or Not To SaaS

A couple of years ago, Nicholas Carr published the book The Big Switch where he proclaimed that Software as a Service (SaaS) is taking over IT. Since then, it’s been a few years now and we are still waiting for the next SaaS killer application since Salesforce.com. Sure, there is Gmail which is supposedly a SaaS replacement for Exchange. But Gmail is basically the same as Yahoo Mail which we have been using since the early 90s – it would be presumptuous to declare that SaaS based email has made the ‘big switch’.

Don’t take me wrong, I am a SaaS optimist. I do believe that you can start a company today in which the entire IT infrastructure consists of a wireless router. But for most existing organizations, the big question is which applications are candidates to be taken on by SaaS and which are not. The following factors should help:

1.Security
One of the most common questions about SaaS applications remains “can we trust a SaaS provider with our confidential data”? But what if your data could be more secure in a SaaS application than inside your enterprise? Many organizations use ADP as a SaaS application for their payroll. I’d trust ADP’s security more than the security of most employers. Similarly, when subjected to a denial of service attack, Amazon may be better equipped to protect you than your own firewall. I believe that security is only a factor in truly high-security environments such as military or national intelligence.
2.Mission Critical
Can we assume that SaaS applications candidates are only the non-mission critical applications? After all, Salesforce.com can hardly be labeled as mission critical. Sure, a Salesforce failure in the last week of a quarter sounds like a bad thing but most of sales pipeline work is not done in the last week and even then the sales reps find a way to get the contract signed using e-mail or fax. Not many organizations that use Salesforce actually process orders in a SaaS application.
3.Legacy
Are SaaS applications more likely to succeed in an area without a lot of history? Replacing incumbent applications, particularly those with significant data legacy is difficult. Sales Force Automation existed before Salesforce.com but it had a very low penetration and most of the Salesforce.com deployments replace spreadsheets. If you have terabytes of transaction data in your ERP, you may not want to move it all out into the cloud. And if you don’t you will end up keeping your on-premise system and not achieve your SaaS objectives.
4.Customization
Are SaaS applications limited to solutions that need no customization? After all, the most widely used SaaS-based application is e-mail which is a perfect example of no customization. Salesforce.com is combating this challenge with APIs and an array of add-on modules but it can hardly be expected that every SaaS solution could do the same. Besides, highly customized Salesforce deployments start resembling the complexity of on-premise applications. Also, the customization needs are correlated to the application maturity and their innovation cycles. Less-mature applications should expect a high pace of innovation with frequent upgrades.
5.Silos
If you entrust your data to a cloud, you have to accept that it will not be managed consistently with the data in another cloud. When applications require a common data store, it can only work if they actually come from the same vendor. I don’t think that all applications need to share a common data model and policies but some for sure do. If they do, SaaS might not be the right approach.
6.Data Volume
The math is pretty simple – the total costs of ownership of a SaaS application is determined by the number of months and megabytes of data stored. If your pricing model includes charges for the volume of data stored, you need to consider that a factor for SaaS suitability. Annual performance reviews in SuccessFactors hardly consume a ton of data. An email archive, however, does, and if it charges by data capacity, you might be looking at a steep bill down the road.
7.Utilization
One of the greatest benefits of running a SaaS application is the ability to leverage a vast infrastructure providing sufficient provisioning for any peak in utilization. That is assuming that your SaaS provider operates an infrastructure shared across multiple customers and that all the customers don’t experience peaks at the same time (e.g. quarter end or tax time). Scaling effortlessly to utilization peaks is important to certain applications and such applications are good candidates for SaaS.
8.Performance
Performance is only a factor in some cases. The performance of SaaS applications is likely to be better than the performance of on-premise web-based applications – the SaaS apps enjoy greater resources and better optimization. Only certain applications in which users are paid by the volume of processed transactions or where they manipulate vast data volumes need to consider performance a factor.

The table below features examples of different content applications, covering a broad spectrum of ECM. I have done a simple and very high level assessment of the factors above. This assessment has to be taken with some care as there is a lot of room for interpretation. But the table suggests interesting results:


As you can see, there are only very few slam-dunks here. Arguably, new product introductions and idea management are well suited for SaaS deployments. A marketing web site and litigation discovery (used for the review, analysis, and production stages of the litigation process) are also likely candidates. Running a terrorist threat assessment or insurance claims processing, on the other hand, seem to be better done on premises. The bottom line, however, is that the answer is almost always ‘it depends’. But it depends on the factors laid out above. Those factors and their weighting should be examined for every application before making the call whether to SaaS or not to SaaS.