Besides being a Co-Founder of The Agile League, Micah also runs Obsidian Portal, a freemium SaaS web app. This article is part of Micah’s series related to the challenges of running a SaaS business.
Although it seems obvious now, in the beginning I didn’t realize that there is absolutely no connection between what price I can charge for a feature and how hard that feature was to code. As a programmer, it seemed natural that a hard-to-program feature should necessitate a big payment from a user, while an easy-to-program feature should be cheap or even free. Nothing is further from the truth.
An excellent candidate for a premium/paid feature is anything that provides value to the end user. The form that this feature takes, code-wise, is irrelevant. Solving world hunger in 250 million lines of code could be a great value. At the same time, a single line of code to send an email at the right moment can also be a great value.
A perfect example of this is Obsidian Portal‘s “email update” feature. People want to know when someone else edits a wiki page. So, we added a few lines of code to send the owner an email when a page is updated…if the owner is a paying subscriber. It was an easy feature to code, costs us nothing (emails are a penny per 10,000), and requires virtually no maintenance. We could have easily made it free, but we didn’t. We realized the value provided to the user is completely separate from the cost of implementation.
The flip side of this is equally true: You can’t necessarily justify charging for a feature just because it’s hard. While it’s up to you to determine what’s free and what’s paid, automatically slotting hard features into the paid bin might prevent some interesting opportunities. If that hard feature can form the core of your app and help to draw in more free users or increase the “wow” factor, then perhaps giving it away for free is the way to go. Or, if it’s hard and doesn’t provide a lot of value, maybe it’s just a bad idea overall?
When deciding where to draw the line between free and paid, focus on value to the user, not how hard a feature is to program. The users don’t care how hard you worked, and likewise, you’re under no obligation to give something away for free, regardless of how easy it was. Even better, before you start on a feature, balance its difficulty versus its value. Sure, maybe you can spend months writing that super-hard, brag-worthy feature you’ve been thinking about, but if you can instead write 2 lines of code and then charge $10/month for it, why not?
