You’ve got a software product. It does things. People want to do these things. Great! Now it’s time for people to pay you. How much should they pay? There are so many options that it’s easy to fall into analysis paralysis, and constantly second-guess yourself. In order to introduce more uncertainty in your decision making process so that you’ll be more likely to purchase my software (which helps make these choices and de-risk changes), I’d like to explain what your options for pricing are, and when it makes sense to use each of them. 

‍

One-time purchase

Most of the things we buy are sold with a one-time fee. You pay once for a pair of pants, for a banana, or for your car (although some manufacturers are trying to change that last part). Before the widespread adoption of software-as-a-service (SaaS), most software was also sold with a one-time cost. Photoshop was so expensive that students and novice photographers would pirate it, simultaneously inventing the free tier, a valuable marketing tool. 

‍

You probably aren’t creating software for which a one-time purchase makes sense. Many games and operating systems are sold this way, and it can be an appropriate model for any software that runs entirely on your customer’s hardware. It’s inappropriate, however, for software that has an ongoing cost to you, the vendor: customers can develop massively negative lifetime values if you’re spending money on hosting and compute costs without receiving anything in return. 

‍

Subscription fee

A recurring subscription fee is probably the easiest model to articulate and apply to a modern SaaS business. Each month (or each year, or perhaps once a quarter), customers pay some fixed amount, and they receive access to your product. This is great because the customer knows how much they’re going to pay, and you know how much money you’re going to receive. That makes forecasting easy. 

‍

In this flat-fee model, growing per-customer revenue depends on convincing customers to upgrade: that is, to give you more money in exchange for access to a wider range of features within your product, or to remove some friction, such as a limit on the use of some popular feature. 

‍

A flat fee makes sense for software which individuals purchase for their own use. Streaming services like Netflix and Hulu charge a flat subscription fee, as do storage providers like Google Drive and Dropbox. Multiplayer video games are another good application for subscription fees.

Seat-based subscription

In a seat-based subscription, customers pay based on the number of people within their organization who use your product. This is a good choice when the value your product provides to the customer scales when more of their colleagues use it, and when the bill payer is the company rather than an individual. In many cases, the same software that’s sold to an individual on a recurring subscription basis makes sense as a seat-based subscription when it’s used for work. 

‍

From a product perspective, you should provide customers the means to manage membership in their organization, to add and remove seats and to differentiate access between seat types. At a minimum, you should restrict the ability to modify billing details and add new subscribers to some sort of administrative user. In more expressive models, you might want to distinguish between billable and non-billable users, which will allow your product to “go viral” throughout an organization with a low-friction and no-cost signup, but then grow revenue over time as more of the users need access to features which are available only to paid roles. Loom did a good job of this with their “creator lite” users, who are restricted to creating fewer, shorter videos. 

‍

The danger of seat-based pricing is that multiple real-world users might share the same nominal “seat,” creating an inconvenient experience for your customer and reducing revenue for you. It’s also a bad fit for products which exist to reduce the number of people who need to do a particular job, like most of the current generation of AI tools: if your product’s success leads to fewer seats in a customer’s organization, seat-based models will reduce revenue as you provide more value! 

‍

Therefore, seat-based models work best for tools which enable ongoing collaboration. Applicant tracking systems like Ashby, task trackers like Linear and Asana, and Google’s workspace suite are good examples.  

‍

Usage-based billing

Usage-based billing refers to charging the customer each time some event occurs. It’s well-suited when there’s a cost to you, the vendor, when that event happens, or when the event happens at an unpredictable and variable cadence. Generative AI tools are a good fit for a usage-based approach, as are application performance monitors like Sentry and Datadog. 

‍

I actually don’t like usage-based pricing for most purposes. A usage limit set near the high water mark of your customer’s observed usage is more predictable both for the buyer and the seller, so they can forecast spend and you can forecast revenue, and avoids dreaded cases like multi-million dollar server bills for mis-configured Amazon instances.

‍

Usage credits

Closely related to usage-based pricing is the idea of a usage credit, a sort of software scrip which the customer purchases ahead of time, to be spent instead of dollars as they use your product. Credits allow you to pull revenue forward (since the customer purchases them before using the product) and they can encourage customers to use the software more frequently, since they’ve already spent the money. 

‍

Usage credits can also be used to pay for different features within your product - perhaps generating an image costs a larger number of credits than classifying an email, if you’re applying an LLM to both. 

‍

Usage credits can be dangerous, because they encourage you to sell your product on a cost-plus basis, rather than pricing based on the value that a customer receives from using the product. This limits your ability to increase your revenue by increasing the value you provide customers. 

Combinations and variations of models

Many companies seek to vary these models, introducing discounts for bulk purchases of credits, enforcing minimum seat counts into contracts, or pricing usage in ever-declining tiers. Some organizations will combine a recurring subscription fee for platform access with an incremental fee for usage. 

‍

Please strive not to do this without a compelling reason. You can reach a similar contract value in most cases by setting a fixed subscription fee with a usage limit, or offering a usage-based price that’s measured against the most valuable thing your customers do with your product. Whimsical and clever modifications and adjustments are very satisfying to debate in pricing council meetings. Tiered strategies can be fun for engineers to build. But complexity is often hard to explain to your customers, especially in a self-serve or product-led environment, and offering too many different levers for negotiation can slow down dealmaking, especially in a high-touch sales-led environment.

The place where byzantine pricing makes sense is in a rent-seeking and bureaucratic world with long contract terms. Enterprise relationships tend to be stable, and vendors which are deeply integrated into their customers’ workflows are difficult to replace. This opens up the opportunity to tack on additional charges with sneaky fees rather than driving revenue by providing more value to the customer. Please, I beg you: don’t do that. 

‍

(An exception to this is an implementation fee charged up-front in order to fund a vendor’s efforts to make the customer successful. This is clearly important when no general-purpose ETL exists to move a customer’s data from myriad spreadsheets into the vendor’s model, or when the vendor is able to offer engineering resources to integrate an SDK into the customer’s codebase). 

‍