For several years, our team’s founders, Mike and Marc, helped to develop and launch a new SaaS startup every three months.

For each one of the 20+ startups, Mike and Marc helped create the pricing strategies that would help get the businesses “right-side-up” and profitable (or pretty close) when they were on their own. By the time they were ready to focus all of their energy on one startup, it was safe to say they learned a lot about what worked and what didn’t work when it came to SaaS pricing.

While I don’t quite have that much experience—I joined the team a year ago without much pricing know-how—I have been trying to catch up on my SaaS pricing knowledge.

On my mission to learn as much as I can about SaaS pricing, I’ve spent hours with our founders, listened to dozens of podcasts, read hundreds of pages from ebooks, combed dozens of blogs, and contributed to Slack and Facebook groups on SaaS pricing. I’ve even written a few posts on SaaS pricing to condense all of the information.

(If you want to dive into some of the public pricing content I’m fond of, check out Price Intelligently and OpenView Venture Partners)

That said, it sounds like someone from our team should be able to set our product’s pricing perfectly, right?

Wrong.

We just made a pricing change. It was our second pricing change over the last year. And we’ll continue to change our pricing.

So, why are we still making so many pricing changes?

There’s no way for SaaS startups like ours to know if we’ve achieved perfect pricing. We only know if we’ve achieved better pricing.

Perfect pricing versus better pricing

I believe perfect pricing is an ideal that you can never fully reach; you’d have to try an infinite number of pricing models to know yours is perfect.

It’s much easier to achieve better pricing than perfect pricing. In explicit terms, better pricing improves customer lifetime value, customer acquisition cost, conversion rates, and the value you bring to customers compared to the last pricing iteration.

I believe chasing better pricing (or rather, a “price-market fit”) is like surfing: you continuously have to pursue a balance as everything changes beneath you. Sometimes you lose the wave, and other times you’re riding it like a pro. And when you’re riding price-market fit like a pro, that’s good news for your bottom line. A study from Price Intelligently showed startups that iterate pricing regularly have an average LTV:CAC ratio that’s 6x higher than those that don’t change pricing at all.

Heck, you might have great pricing and generating loads of revenue, but that will only work well for a short period. You’re likely continually improving your product, which changes customer value. And if customer value changes, your pricing should follow. That’s on top of the several other factors that continuously influence how you should price your product.

Our pricing change

For context, Cheddar is a usage-based billing platform, but that doesn’t mean we only do usage-based pricing. Rather, usage-based billing means that our API allows you to track software usage first—for things you might not even charge for—and then you can create pricing logic to apply to that activity later. One of the most significant advantages of this approach is that our customers can completely isolate billing code from the codebase, making pricing iterations easy.

Being a usage-based billing platform, we admit we are naturally pretty fond of usage-based pricing and see it as the future of SaaS. While you’re able to access our full API for free and play around with it, our pricing is based on usage: $99/month plus $0.30 per transaction to process live transactions. As an optional feature, we also allow users to use our built-in payment processor for 2.9% of revenue.

For some additional context, all of the plans include

Usage and metric tracking and storage
Invoice generation and customer communication
SaaS metric reporting
Revenue optimization (dunning)
Ability to switch payment processors or run more than one payment processor at a time

Over the last few months, we learned we had two issues with our pricing:

Our messaging around “not charging a percentage of revenue for billing” and only charging for transactions generated confused people.
$99 per month is a pretty steep cliff for smaller startups and bootstrappers.

First Problem: Our pricing confused people

Lesson learned: Look at your pricing through your customers’ point of view. If your potential customers are confused by your pricing, it’s your fault. Understand their context.

Our original pricing page emphasized that we never charge a percentage of revenue to use our product. Rather, we charge per-transaction. However, we did offer an optionally integrated payment processor which did charge users a percentage of revenue.

We quickly learned our pricing page’s layout, copy, and design weren’t completely obvious through messages and comments like…

Questions and comments we received on Intercom and Indie Hackers about our pricing

To address our customers’ confusion, we knew we needed to redesign the pricing page to highlight the difference between billing and payment processing. We also thought it might be useful to have a pricing calculator so potential customers could estimate what they might pay with us per month.

A new pricing page would take a little bit of time to design, create, and push live. In the meantime, we quickly published a blog post about the difference between billing and payment processing and inserted a hyperlink on our current pricing page. We also changed where we bolded some of the description text to emphasize the difference between the two.

*Subtle updates to our pricing page: added a hyperlink to an article which clarifies the difference between payment processing and billing, bolded "billing platform" and "payment processing"*

*Designs for our new pricing page. We’re still working on the copy and the pricing calculator, but it should launch soon. What do you think?*

Second problem: Our pricing caused friction when acquiring early-stage startups and bootstrappers

Lesson learned: While you shouldn’t default to giving your product out for free or less than it’s worth, you might be able to get rid of friction in acquiring higher-paying customers by offering a “loss leader”, a well-thought-out starter plan, free trial, or freemium plan.

With our per-transaction pricing, we knew we had a pretty convincing “value metric” which could scale across different size companies that had low, medium, and high transaction volumes.

However, our pricing also has another component: a $99 per month fee. That price included access to our dunning, customer communication, metric reporting, and security features which customers wouldn’t have to build or buy themselves. Combined with our usage-based approach using Tracked Items, we knew developers could go live with an entire billing stack little as one day and easily iterate their pricing model without code changes, so we thought this would be viewed as a small price to pay for the development time saved.

What we learned, however, was that the additional $99 monthly fee was a pretty big deterrent for getting smaller startups to convert to paying customers. Through Intercom conversations, emails, and talking with developers in person, most early-stage startups mentioned they couldn’t afford to pay around $1,200 annually for going live with our product.

We decided to add a new pricing plan where we would waive the $99 per month fee for smaller startups up until a certain point. Instead of offering this plan indefinitely, we decided to offer it based upon our usage pricing model: for up to 1,000 transactions, small startups can get all of our platform’s features for only $0.30 per transaction.

We might experiment with the number of transactions that we allow for free later. For now, 1,000 sounds like a pretty fair number. If you’ve gone through 1,000 transactions with an average size of $50-$100, you’ve already made between $50,000 and $100,000 in revenue. At that stage and after realizing the benefits of our usage-based billing architecture, we imagine people will be more willing to pay $99 per month.

While we’re concerned about lowering our average customer LTV without a proportional increase in the number of paying customers, we hypothesize that the lower-revenue plan will help us acquire more customers that will pay the $99 per month in the long-term.

A subtle difference on our pricing page, but a big difference and how much our customers would pay us. On the left, our original pricing. On the right, our new pricing where we’re advertising that we’ll waive the $99 per month fee for up to 1,000 transactions.

We’re already thinking about the next pricing change

We’re just starting to collect quantitative data about the pricing change, but we also want to collect qualitative data. So what do you think about our pricing change?

While subtle from the outside, our pricing changes have substantial potential implications on our business.

We hope our most recent pricing changes help us to get to better pricing and improve our customer LTV, CAC, conversion rates, or the value our customers receive from the product.

However, if we learn that our pricing hasn’t helped, that’s okay too. We’ll know what doesn’t work so we can be one step closer to finding what does work.

Of course, pricing isn’t the only piece of the startup puzzle that matters. As we monitor how this pricing iteration turns out, we’re also chasing the product-market fit "wave" by improving our product and experimenting with our marketing efforts.

If you’re as excited about pricing as us, I encourage you to join our SaaS Pricing community on Facebook, subscribe to our free Pricing Bootcamp, and explore how you could use our usage-based billing API.

Cheddar is a usage-based billing platform that helps you track customer activity, iterate your pricing, and optimize your revenue so you can focus on building awesome products, not billing for them. Made with ❤ from the Midwest.