Developer product companies are asked to do two things: achieve near-ubiquitous adoption through an accessible, hobbyist-friendly offering, and convince large companies to pay them money. Unfortunately, these two goals often run contrary to each other.
Herokus* free dyno is a great example of this. Herokus initial pricing had a single unit the dyno and only charged for incremental dynos beyond the first. An app running one dyno would cost $0/month, an app running two dynos would cost $37.50/month, an app running three dynos would cost $75/month, etc.
This free dyno was immensely successful in driving active usage metrics hobbyists and students loved the fact that they could create web apps for free. The company ran into trouble, however, when Heroku started charging large enterprises for the same functionality. These large customers were savvy enough to realize that they were paying more per dyno than many of Herokus smaller customers that received one dyno for free, leading to some difficult negotiations. It took Heroku a couple of iterations to fix this problem ultimately by decoupling its free tier from its standard offering.
The following is a list of the common mistakes developer-focused companies make when pricing their products and services.
Even if your company doesnt have an enterprise product yet (you arent alone), you still need to build an Enterprise column into your pricing chart with a big Contact Us button.
This simple add-on immediately gets you three things: It provides a signal to investors, customers and future partners that you have an enterprise roadmap; it wins you trust from developers as they now know that they can one day implement your product at scale; and, most importantly, it gives you a list of people interested in paying for you product.
When your enterprise product is ready, youll hand that list to your head of sales and they will thank you for it.
This problem can be tricky to spot your customers probably wont tell you that your product is worth more than what theyre paying.
To avoid this, look for warning signs like sluggish conversion rates to more expensive plans or big logos that are stuck on low tiers. Its likely youve already done everything you can to have as awesome an enterprise product as possible, so this problem is going to require you to do something rather painful: Youre going to have to remove features from your free offering to make it less attractive.
Be warned, you likely will not enjoy doing this. Your coworkers are going to strongly disagree with this decision. Your users will not be thrilled that you are doing this and they will tell you that.
Thats OK. Implement a generous grandfathering plan. Remind your team that you do, in fact, need to make money. Trust that this will be small news in a few months.
Imagine: Its Friday night, and youre headed to the new restaurant in town. You open the menu and see this:
Guests are welcome to configure their own dishes:
Unless youre selling infrastructure, its rarely appropriate for your pricing to be a function of bytes. Dont base your pricing off storage, data transfer or compute. Not only do these plans make it difficult for customers to estimate how much your product will actually cost, it gets them thinking about it in entirely the wrong frame. All of a sudden theyre doing some simple back-of-the-envelope math comparing the price of your infrastructure to how much the same stuff costs on AWS and you look very, very expensive and theyre wondering how hard it would be to just build this from scratch.
Youve seen this pricing plan: use as much as you want, pay for what you use. This sort of free-form pricing provides flexibility, transparency and ease-of-use and is a terrible idea. Your users may care about flexibility; their managers care about predictable costs. Nothing is scarier to folks who manage budgets than a vendor that could charge an arbitrary amount per month.
Thankfully, theres a straightforward solution here: Come up with a handful of plans with distinct thresholds across whatever metrics you care about.
*Disclosure: Heavybit was founded by Herokus founder James Lindenbaum. James cut ties with Heroku in 2013 shortly after the company was acquired by Salesforce. Salesforce is an investor in Heavybit. The author of this post previously worked at Heroku and was a member of the team that worked on pricing.