SaaS pricing: Push your base version

I see many startups that take a page from the smart folks at 37 Signals. They build their sites / apps in rails, they use similar design / UI principles and even copy their mode of presenting 4 or 5 pricing options. Often, and coincidentally, just like 37 Signals, these pricing options show the 2nd or 3rd most expensive pricing plan as the “most popular”. ¬†When I see that, something smells fishy to me.

In almost all cases, its highly unlikely for the more expensive pricing options to be the most popular, especially for young startups. When your user base is growing, you are adding lots of free users and hopefully converting a bunch of them to paid. Invariably, new paid users start at the base package. So, by definition, if your user base is growing then your most popular paid package will be the base one. And your average revenue per user will always be driven down towards the base level by virtue of the growth in new paying users.

If users really are going direct to a more expensive package when they 1st subscribe, then I think you need to review your packages and potentially kill one or more cheap ones.

And if that’s not the case, and instead you’re just copying what works for 37 Signals, don’t. Just serve up the pricing options with a clear feature differentation and let the user decide.

On that note, since the biggest battle is getting a free user or visitor to pull out their credit card for the first time, don’t give all the pricing plans equal billing if the vast majority of new paid accounts are your base paid version. Instead, devote lots of real estate to showing people who don’t pay you why they should. That means really showcasing the value of your base premium package.

Over time, you can try to convince paying users to upgrade. But the biggest battle is getting people to pay you in the first place. Don’t lessen your chances of winning that battle by confusing users with info that they don’t need (such as the great benefits of your super whiz bang, most expensive package).

  • Learn about what "additional features" your customers are keen in actually paying it – not by building the product immediately but placing a "dummy" placement and get customers to signup when feature is ready. Great way to test what to build and be consider as part of pricing package testing.