Pricing for SaaS products | Author:

In our previous article Funding launch , we talked about building a product under a funding constraint. We explained how you can avoid or embrace a funding constraint and the consequences of each choice.

In this article, we discuss our decision making for pricing Async.

The main constraint that we face while building Async is keeping our product simple. This constraint forces us to think about keeping any new feature and the overall product simple.

Simple to:

  • test a feature
  • extend a feature
  • analyze how a feature is used

For our customers, we want Async to be simple to:

  • understand the features
  • use the features

The same idea should be true for our pricing. Pricing should be simple for us to test/extend/analyze, and it should be easy for our customers to understand/use (commit to pay and pay).

If you pay for multiple SaaS products for your business, you are probably familiar with the most popular pricing strategies:

  • per-seat
  • per-feature
  • flat (the least popular)

All three strategies can be combined with a freemium version or free trial period.

In the per-seat strategy, you price your SaaS product based on the number of users the customer has. If a customer has 10 users on the team, you charge customer 10X/month (where X/month is your per-seat price). In the per-seat model, you offer the single version of your product to all customers.

In the per-feature strategy, you have a tier for your products. In other words, you have multiple products and you charge more for products with more features. Nowadays, many SaaS companies offer basic/individual, pro/business/team, and plus/enterprise tiers.

The most popular pricing strategy seems to be a combination of per-seat and per-feature, sometimes including a free tier option.

Check out these examples: launch launch launch launch

There is probably some science behind why a particular company chooses a particular pricing strategy. I hope so. Because many typical pricing pages confuse the shit out of me. I could spend 10 minutes reading through those pricing tables and still have no clue on which plan to choose.

In a flat strategy, you have one version of the product and pricing does not depend on the number of seats. All of your customers pay you the same X/month. The flat strategy seems wasteful at first. Why in the world would you undercharge customers with larger teams?

Yet, we chose to go with flat pricing and charge all of our customers $50/month. Paying customers can add any number of private repos and repo members to Async. Below are the two main reasons on why we chose flat pricing.

We built Async for small teams

Async is built for small teams by our small team. We would never be able to build a product for a large team. Kelly and I have only worked in small teams: our largest team size was 6, and our current size is 3.

We use Async every day to work on Async and to manage our open source and side projects. We eat our own dog food. We build every feature under a simplicity constraint and then test by using each feature for weeks or months. Async is probably very hard to use for teams larger than 20. As of writing this article, all of our paying customers have 5 or fewer repo members per private repo.

If our pricing was variable and we charged larger teams more money - we would optimize our product for large teams. We simply cannot do that, because we are not one. In our previous article, Funding launch , I described how we customized our previous paywall software to satisfy the needs of a few large customers. When you customize your product for a few large customers, you ultimately wonder if (1) the product you built is actually a SaaS product OR (2) you've become a custom development shop for large customers.

That's why we have no per-seat pricing in Async.

We impose a simplicity constraint

As I mentioned at the beginning of this article, we embrace a simplicity constraint in building Async. Every new feature of the product, including pricing, has to undergo a simplicity test. Is it easy to test/extend/analyze this feature? If we had per-feature pricing, then we would have to test/extend/analyze at least two versions of our product. We cannot afford that. By managing two versions of the products, we would lose focus, and each version would suffer UX-wise and accumulate technical debt. Thus we refused per-feature pricing.

Because we are a small team that insists on simplicity, the only acceptable pricing strategy is flat pricing.

Have a question or suggestion? Feel free to email us at launch