At Airplane, we recently exited our free early access period and started charging for our product. I thought it'd be helpful to write a post talking through the logic behind our pricing model, partially as an explanation for our customers, but also as a data point for other early-stage B2B SaaS businesses. Prior to Airplane, I also spent 7 years at my previous startup Heap iterating several times on pricing.
What are you optimizing for?
It might seem obvious that the point of pricing is to maximize revenue, but this isn't necessarily true. Or rather–maximizing the long-term revenue potential of your business might mean adopting different short-term goals.
There are several axes that a SaaS pricing model can optimize for. These are neither exhaustive nor mutually exclusive, just things we considered at Airplane or I've considered in the past at Heap:
- Maximize adoption: Most obviously, a company can use low or free prices as a way to maximize adoption. The cheaper a product is, the more people will try it out and buy. Pipedrive has significantly cheaper pricing than most other popular CRMs.
- Competitive advantage: Lower price is an obvious way to gain a competitive advantage over others. Another technique is to use asymmetric pricing strategies against competitors. For example, if your competitor charges $10 per widget, but you charge $100/month for unlimited widgets, then your customers may buy your product for the peace of mind of consistent pricing, even if some months that results in a higher price. Splice uses a strategy similar to this to sell music samples via subscription vs competitors that sell samples in one-off packs or a-la-carte.
- Customer legibility: A company can present prices in a way that are easy or hard for customers to grapple with. This isn't purely about complexity. For example, if a SaaS product charges based on the number of emails sent, but the customer doesn't know how many emails they're going to end up sending through this product, then they don't know how to estimate how much the product will cost for them. Legibility is about how easy it is for a customer to understand what they'll be charged. Infrastructure products can suffer from this (how many Heroku Dynos do I need?)
- Implementation cost: A complex pricing model can create a large operational burden for the company. If you have a model with tons of product lines, mixtures of a la carte/per-license/per-usage pricing, complex overage schemes–this can be a huge amount of engineering effort to implement. It's also a lot of work to train your sales and customer success team on how to communicate this pricing model effectively to your customers. Even if this kind of pricing scheme is revenue-maximizing, it will have a large organizational cost.
- Lead qualification: Many SaaS companies have a specific ideal customer profile and want to spend as little time as possible with customers too far outside that profile. For example, a company that only serves large enterprises with high willingness to pay likely will have a pricing page that reveals no information and has a "Contact Us" button that requires you to fill out a lead form. Even for companies with public pricing, having a high published price floor and no freemium plan might help keep out undesired customers.
- Price discrimination: A well-designed pricing model can extract close to the maximum willingness to pay from each customer while not keeping anyone out. This is tough to do in consumer products (everyone in a certain country pays the same price for Netflix) but much easier to do in complex SaaS products with a high degree of customizability and features that correlate strongly to willingness to pay (e.g. audit logs). An example of a company taking this to the extreme is Salesforce, with 15 different product lines and each one having a massively complex feature-and-function grid:
What do we care about?
It's impossible to have a perfect pricing model that maximizes all of the above criteria. Many of these trade off directly against each other. A Salesforce-like pricing model that maximizes a company's ability to price discriminate will be almost incomprehensible to customers without the assistance of a sales team to help them figure out what they need.
Today, Airplane is an early-stage startup–just a few dozen early customers. We're building a self-serve SaaS product that has a lot of potential uses. It's a horizontal product, i.e. we're not focused on a specific use case or industry. Over time, certain niches may emerge, but we don't yet have a strong belief as to what that might be.
As a result, our goal is to get as many customers as possible in order to maximize our rate of learning and iteration. Each new signup tells us a bit about the types of customers that might be interested in our product; each new active user tells us more about the use cases people are discovering for Airplane; each new paying customer tells us which use cases have non-zero economic value.
Therefore we wanted a pricing model that optimized for customer legibility, broad adoption, and implementation cost. We want people to understand how our pricing works very clearly and feel that the pricing is low enough to justify trying out the product. We also didn't want to spend an inordinate amount of time implementing billing logic when we have so much else to build.
This might not be the right decision even for other early stage startups. For example, a startup targeting large enterprises may want to deliberately set high prices if they're trying to validate willingness to pay for the problem they're solving, or if their early customers will require a lot of customization.
The process
With this in mind, the highest-level thing to decide was the primary unit of pricing. No matter how complex a company's pricing model, there's usually one variable that determines how price scales. In the case of Salesforce's gargantuan grid, the highest-order bit is users (also called "licenses" or "seats")–the more people that use the product, the more you pay.
Other products have a usage-based pricing model based on how much the core service is used. Stripe charges a percentage of each transaction, Segment charges based on monthly visitors to a website, and AWS EC2 charges based on compute utilization.
We had several logical choices at Airplane. We're building a developer platform for quickly building internal tools. Engineers use Airplane to create "tasks" which are operations that can then be run by other engineers, or non-eng teams like support or ops. A task might be something like "Update a user's email address" or "restart a service."
Based on this operational model, we had three obvious options:
- Users - how many people have access to Airplane to create or run tasks?
- Tasks - how many tasks has the team created in Airplane?
- Runs - how many tasks are being run per month in Airplane?
Tasks and Runs correlate strongly with value, so we thought about using one of those options. Each Task represents a concrete app that someone has built with Airplane, and therefore represents some amount of engineering time saved vs not using Airplane. Each Run represents someone choosing to actively use Airplane, meaning that specific workflow was completed more efficiently or safely than the alternative. Both are decent proxies for value.
However, when we surveyed our early customers, they didn't like being charged for Tasks or Runs. They had no idea how many runs were happening in Airplane, and they didn't have a clear sense for how many tasks they would end up creating in the future. Even if they did have a strong understanding of these numbers, they felt that charging on either metric would disincentivize usage of Airplane.
We therefore decided to price per User to maximize customer legibility, and to keep the per-user cost relatively low compared to similar tools (e.g. Retool or Postman).
The Pricing Model
We ended up with a per-user, tiered, freemium model:
- Free up to 5 tasks and 5 users, which in our experience covers what most small startups need, and allows larger teams to test out the product a significant amount
- $10/user/month up to 30 users and 30 tasks, which is sufficient for most <100 person startups
- Custom pricing beyond that
The reason we chose to do custom pricing beyond that threshold rather than publishing a number is that we found that larger companies have specific requirements that need some customization. For example, a company may be comfortable paying $50/user/month for one team, but they also want to expand Airplane to another team which has a much less valuable use case and only has $10/user/month willingness to pay. Enterprise customers are typically willing to trade off some amount of pricing legibility for customizability.
Is it working?
We just rolled out these pricing plans a couple weeks ago and only have a handful of early customers on these plans. So we'll know a lot more about how it works in the coming weeks.
Already there are some signs that we could better optimize these plans. This is a conversation I had with a customer (heavily paraphrased):
- Customer: I'd rather not pay per-seat for people who aren't using Airplane. But I don't want to completely remove their access since they might need access occasionally. Have you considered only charging per active user, like Slack does? I'd even pay more per user for the active folks if I wasn't being charged for the non-active people.
- Me: If we instead charged $15 per active user, and $0 for inactive users–let's say people with fewer than 3 runs/month–would that work for you? Given your account usage, that would actually have been a bit more expensive than $10/user for all users.
- Customer: I'd prefer that–even if it's a bit more expensive now, I can invite everyone in the company, and then be confident that we'll only get billed for what we're actually using.
We had briefly considered trying an active users-based model, or splitting out developer vs non-developer seats (charge a different amount for people who can create tasks vs those who can only run them). However, we felt these would reduce customer legibility and increase implementation cost without providing much upside along the other criteria. Now we were getting some evidence that, at least in the case of this one customer, this would have proven valuable (both for them and for us!)
I'm not sure yet if this is actually what we'll end up doing–it's only one data point. But it is evidence that there's a lot more room for iteration.
Hopefully this perspective has been helpful. There are some other really good resources out there that talk about SaaS pricing that are worth checking out as well–Stripe Atlas guide to pricing, TNW Pricing Page analysis, Price Intelligently's SaaS pricing guide.
About Airplane
Airplane is a developer platform for quickly building internal tools. Airplane lets you turn Python/JS scripts, SQL queries, REST endpoints and more into lightweight internal apps that your support, operations, and other teams can use. We provide UIs, notifications, permissions, approvals, audit logs, and more out of the box so that engineers only need to implement the backend logic of an operation. Learn more and watch a demo video here.
