Lessons on Pricing
March 12th, 2017
One of my big projects of last year (and the beginning of this year) was Sentry’s pricing change—the design, implementation, and migration of our core business. Pricing is such a confidential and secretive topic, no one wants to talk about it. There is no Codecademy for business models. Mostly a lot of theorizing in Hacker News threads and overpaid consultants that tell you obvious things.
So, here’s what I’ve learned thus far.
Free is a philosophy, not a tier.
Free makes it much, much easier for people to adopt your product. In August 2016, Sentry dramatically increased both the capacity and the prominence of its free tier. Overnight, our signups tripled. In a cohort-based business like ours, getting people in the door and using our product is critical. Interestingly, when we reduced the size of our free tier in 2017, signups were unaffected. People want the assurance that your product will be usable without paying.
Demand is elastic
Conversion from that free tier is entirely based on price and highly elastic. Raise your minimum price? Less people convert. Lower it? More people convert.
Sentry’s gone through a couple major iterations on pricing.
- Early 2016: min price of $9/month
- Late 2016: min price of $29/month
- Early 2017: min price of $12/month
At each stage, actual conversions did exactly what we expected them to. Why? Because every tech company sells conveniences, not necessities. Before people used Sentry, their code ran—just with less visibility. So it’s not hard for someone to envision running code without Sentry.
Instead, Sentry’s approach is value based. Use us, learn to love us. And if you think we’re great, pay for us.
Coloring in the demand curve
The problem is that lowering your price (cutting it in half in our case) can run you into real problems. Namely, you make less money per customer. Our pricing is especially perplexing, as we ask our customers to pay us based on the number of errors they send. That means we have some customers that just have terrible, terrible code that throws thousands of errors a minute, but they do not want to pay. Other customers have massive engineering teams and large customer bases that hardly have an errors.
As a business, it’s really perplexing to watch that—we like charging rich enterprises more so we can charge small developers less. The funny thing is, everyone’s trying to save money and the Morgan Stanley’s of the world are likely more savvy negotiators. One of the things that Sentry will have to learn institutionally is that even if someone is rich, they don’t like paying more for the gas in their car.
They will, however, paying more for bottled water than tap. We’re still working on what that means for us, but I’m hoping our new pricing model will accelerate those institutional learnings (and we don’t regress to simply raising prices).