Pricing a SaaS app is hard

Pricing a SaaS app is hard. Really hard. My flagship product Teascript launched with a subscription-based pricing model in 2007. This was primarily due to a limitation in the payment system I was integrating with. I did a bit of “market research” before settling on $19 per year for unlimited use of the app. (And by “market research” I mean that I Googled some keywords related to my app to find competitors and learn what they were charging.)

This pricing stuck for several years but I eventually realized the amount of value I was providing through the app did not match the price tag. As I continued building new features, the value was increasing and I needed to change my pricing accordingly. I also decided to move from an annual charge to a monthly charge, mostly because I wanted a shorter feedback loop to measure churn.

I switched all subscriptions to $5 per month and also put a cap on app usage (which in hindsight, I should have been doing from the start but that’s a topic for another post). Surprisingly, this actually increased my sales even though the effective annual rate had more than tripled to $60. Why was this?

I was scratching my head initially until I realized many of my users were signing up for one or two months and then canceling their subscriptions. So I had actually increased churn by moving from an annual to a monthly charge. But that told me something about how my customers were using the app. Teascript helps homeschoolers and private schools build high school transcripts for their students. This is something that’s typically only done once in a student’s lifetime. Therefore, even in a family with 3 or 4 kids, a parent is only going to be using the app for a few months at a time per student, then they won’t have any further need for it.

This leads me to believe that moving to a fixed pricing model may be the right approach. Recently, I’ve been experimenting with various metrics to try to measure how much money I make off a typical subscriber. If most of my customers only remain subscribed for 3 or 4 months, that’s $15 to $20 of revenue. If I had instead been charging a fixed price of $39 (a price point comparable to most offline high school transcript kits) then I would have nearly doubled my revenue.

I still haven’t found a reliable way to determine the lifetime value of a customer, though. I’ve been experimenting with various Stripe metrics providers but haven’t found anything that calculates metrics based on the past 7 years of payment data I have in Stripe (everything I’ve found only calculates metrics going forward). When I do figure this out, I’ll be sharing the results here. Stay tuned.

In conclusion, did I mention pricing is hard? There are so many different ways to price an app. It’s hard to know ahead of time what will work for any given app. This is where A/B testing and customer feedback can be helpful. Even with that additional information, though, I feel like it’s something that could take a lifetime to master. I’m well on my way, but I still have a lot to learn.

Have you run into challenges pricing a SaaS app? Share your story in the comments.

One thought on “Pricing a SaaS app is hard

  1. Hey Matthew! Pricing is indeed quite difficult. Only real way to find the sweet spot is to experiment and A/B test.

    You mentioned that no Stripe metrics providers give you historical LTV…just wanted to let you know that Baremetrics actually does just that. We import all of your historical data (all the back to your very first charge) and give you metrics around those.

    Might be worth giving it a try. :)

    https://baremetrics.com

Comments are closed.