It's popular these days to use hosted applications instead of running your own infrastructure. It's frustrating as a customer, though, when the pricing model is not sophisticated enough to match your actual usage.

In a SaaS product, your pricing should scale with the value the customer gets from the product. You want to charge big customers more while keeping it affordable for small customers, and you need to enable early stages of usage in big companies such as pilots or "viral" adoption.

If the value scales with the number of users, then charging per user makes sense. If you are making an app to help manage fleet of vehicles, then charging per vehicle may make more sense.

You also want natural "price breaks" which separate your entry level users from the features in the "pro" or "enterprise" plans. People who have 50 users have different problems than ones that have five, and you can charge them more if you are providing more total value.

Users are not all the same

There is a SaaS industry trend towards per-user pricing.

The fundamental problem comes when you have users within a customer account which are getting different amounts of value from your product. There is also a danger of alienating the small customers and technical users who have the potential to give them viral growth.

For example, the GitHub code hosting and collaboration platform announced a change in their pricing model that makes things difficult for consulting companies like ours. Instead of charging for the number of projects hosted, they charge per user per month. If the users are all active developers, then customers are getting value from the platform no matter how many projects there are, and it scales naturally with the size of the customer's organization.

The new change, however, increases our costs significantly without increasing value because we have inactive users. If we host a client's project in our GitHub organization, then we need accounts for our developers and one or two for client staff. When we are actively developing the project, then that's fine. If the project launches and switches to a maintenance phase, then we end up paying too much.

If the project is not active, paying for our developers is fine, as they will be working on other projects, but we are also paying for the inactive client accounts. If we take away client access to their source code, then they (reasonably) freak out. If we archive the repo, then it's same thing, and it's an administrative hassle for maintenance.

If the client has their own organization, then it's worse. They pay for their own inactive users and also for our inactive users. So they can remove our users and save the money, but that's a pain if we need to do some maintenance. When you don't have a lot of activity, it's like every bug fix costs $10 vig to GitHub to add the user for a month.

We see similar issues with production incident management products. I am ok with paying $50/month per on-call ops person, as we are getting value from the product. I don't like paying $50/month per developer who might potentially need to deal with a problem that gets escalated, or a product owner who might need to see what the status is. These users do not have the same level of interaction with the product.

Failure to get this right can result in people setting up their system to minimize costs rather than using it "properly." For security, users should have their own logins with roles that allow them to do their job. A sign that your pricing model has problems is when you see people sharing sharing account logins. For example, if you use GitHub's issue tracker, then anyone in your company might need to be able to create a bug report. Paying $10/user/month for that makes no sense, so we end up with a shared account. That's inconvenient, though, e.g. users can't get emails notifying them when the developer responds.

In your SaaS product, you may separate the management of "billable" resources, giving the owner control over how much money is being spent. For example, the owner can create resources that cost money each month, while the primary users manage them.

Sometimes the SaaS pricing seems like its own bubble world and we forget that there are other ways of doing the same thing. If I was to buy a little time tracking app that ran on my computer, I would expect to pay say $19.95, not $120 per year. For a while we used Harvest for time tracking, but it was $12 per user per month. The ROI on us making our own solution was a month or two, and we got to integrate it with processes like invoicing and accounting to make it work better for us.