by Tigran Hakobyan

How to price your side-project

1*GvFlbBgvsCc4ofc3Wg2uPQ
Photo by Rajiv Perera on Unsplash

Introduction

If you had asked me a couple months ago if I could ever write an article about pricing, it probably would have made me laugh.

Until a few months agao, I didn’t know anything about product pricing even though I’d launched my first SaaS project. The way I priced my product was by solely relying on my own intuition, as well as looking at how other similar SaaS products priced their services. I think this is what most beginners do.

Then why on earth write an article if I’m not an expert on pricing? Because I’ve come to realize that it’s totally okay to write about topics you’re not expert on.

Chris Coyier’s tweet inspired me to start writing about things I wish I could find on Google.

I started to use blogging as an excuse to learn a specific topic. This article is the fruit of that inspiration, and I’m happy to share it with you all.

There aren’t many articles on the pricing of side-projects, even though the number of revenue-generating side-projects is growing. If you go to Indie Hackers you can see many of them there, and many makers in the community wonder and ask questions about pricing as well.

In this article, I’ve summarized everything I’ve learned about side-project pricing. For the last two months or so, I’ve been reading about pricing and talking to people who are knowledgeable about pricing. It really helped me to understand the basics and create a more successful pricing model for an SaaS project.

I’ve used Cronhub (my side-project) as an example to better explain my view and thinking process, because I believe it’s easier to digest new information using an example.

All my learnings here apply to SaaS products, but I think other types of businesses can benefit from them, too.

Why monetizing?

Monetizing your project from day one is very important. You can think of the “monetization” as a feature that you want your product to have. This feature significantly increases your product’s chances of success. Usually, you build features for your customers but this one is for you, to keep you more motivated to work on your project.

Your motivation and persistence are the key drivers to move your project forward. If you value something, it keeps your motivation high. What’s the easiest way to know whether your project is valuable? Asking people to pay for it. In my opinion, if you can find 10 people willing to pay for your project, you know you’ve got something that people are ready to pay for. After that, you can find the next 100, 1000, and even more. Finding the first customers is the hardest part.

Because finding the first customers is hard, it’s important to set the right pricing model in the beginning. Pricing is a living feature, and as any other feature, it requires multiple iterations until you get it right. It’s totally okay to make mistakes in the beginning. In fact, for Cronhub, I’m still not sure whether I’ve got it right or not. ?

However, I’m open to changing it if that’s what’s best, and that’s what matters.

If your intention is to build a business from your side-project, then you should charge for your project. It’s hard and more often demotivating to work for free. You value your time and others should, too.

Pricing strategies

Since I’m not an expert in this field, I can’t give you very technical answers to pricing strategies. However, one thing I can do is to explain these strategies in a more human way with simple words.

Maybe that’s even better for you? ? Good. Let’s go for it.

The primary goal of a pricing strategy is to maximize your product’s revenue. According to a book that I’ve read, “The anatomy of SaaS pricing strategy” (which a great book btw), there are three pricing strategies for SaaS products.

Cost-Plus Pricing

This is the most basic pricing model you can think of, because it really makes sense. First, you calculate everything that costs money for your project and then add a healthy margin on top of it. The margin is your profit, and it represents the value that you give to your customers.

Let’s take Cronhub as an example. Cronhub is a cron job (or any scheduled task) monitoring tool. Monitors cost me money, because they send emails and SMSs to my users. Sending emails and SMSs is costly for my business. Having more monitors will increase my cost, and that’s why I priced Cronhub by the number of monitors. If you want more monitors, you should pay more.

I think most first-time side-project builders take this approach, because it’s simple and it covers the costs. The challenge with this pricing strategy is the unpredictability of the future. If your costs unexpectedly go up in the future your profit margin will drop and you will have to increase your prices.

Competitor-Based Pricing

As the name implies, this pricing strategy is influenced by your competitors. When you don’t know the initial value of your product, you usually turn to your competitors. You check their pricing tables so you can come up with yours. Well, I’ve done it for Cronhub, too.

If you’re launching a product in a new industry, it makes sense to check competitor pricing because you don’t want to go too high or too low. We’re always afraid of losing customers because of the big price difference from our competitors.

This pricing strategy is simple and less prone to be wrong. You can probably spend an hour or so researching competitors and come up with a pricing table that is similar to your competitors. This way your future customers won’t think that your product is too expensive or too cheap.

The one downside I see for this model is that you don’t want to be guided by your competitors from day one. You want your product to have its own personality, and it should be reflected in the pricing as well. Use competitor pricing as an inspiration and benchmark, but not your guiding strategy. For me, I see this strategy mostly used in combination with other pricing models.

Value-based pricing

This strategy is also called customer-based strategy and is solely based on your customer surveys and research. You want to know how much your customers are willing to pay for your product, and the only way to do so is to go and talk to them. Most companies use in-product surveys to collect this data.

There are many other benefits with this strategy, too. You get to know your customers and their needs, which helps you to build the best product. I think that by following this strategy, you’re most likely to come up with a better pricing table.

However, this model can only be applied after some initial iterations when you have a decent customer base. That’s why I believe that this model should be used as part of the last pricing iterations on your pricing table. It doesn’t mean that you should not talk to your customers from early days. Just set a goal for yourself that you eventually want to use this strategy to decide your pricing table.

You may want to re-apply this strategy often, because your customer base and the market needs keep changing.

Break down your customers into groups

I strongly believe that breaking down your user base into groups is not only important for building a better product, but also for modeling your pricing. When you start thinking about pricing, you naturally measure it with only one dimension using just a single variable (like I used only the monitor count as a pricing measure for Cronhub).

However, you want to add another dimension based on your customer groups. There is a term called “Pricing Axes” which I first heard from Joel Gascoigne in our company retreat this year in Singapore. These axes represent variables that you can use to better model your pricing. For instance, Cronhub has two pricing axes now after launching the team plan: the number of monitors and the team member count.

Breaking down my customers into groups helped me come up with the second axis for Cronhub. I have divided my potential customers into two groups, solo developers, and developer teams. It naturally makes sense that there should be different pricing for each of these groups, because their needs are different. Following this strategy, I’ve created two pricing plans for the team depending on the number of team members they need.

Of course, you can add more axes along the way, and it depends on your product. I think keeping your pricing axes around 2 - 3 makes sense at least in the beginning. Adding more variables may confuse your users, and you don’t want that.

Applying the strategies to Cronhub

I want to also talk about how I’ve applied the above-mentioned pricing strategies for Cronhub and the pricing challenges I’ve faced when starting Cronhub.

Cronhub is a product for developers. I knew that the developer market is not an easy one to be in, but it didn’t stop me starting something I’m very passionate about. I really enjoy hanging out with developers and getting to know them better. For me, what mattered most was to launch a product that would serve this market.

Being a developer, I know how much developers love to use free tools. However, they’re also willing to pay for a product that provides significant value to their flow and productivity. I want Cronhub to be one of these tools. I launched Cronhub with only two plans, “Free” and “Developer ($7/month)”. I wanted to see whether this was something other developers would pay for or not.

My very first pricing model was mostly a symbolic strategy to validate my idea. I didn’t spend much time thinking about the pricing plan and followed Cost-Plus pricing strategy to use the monitor count as a divider between the free and the paid plan. In the first month, I got a couple of paid customers which made me revisit my pricing. That’s when I’ decided to invest a little bit of time to learn about this topic.

After two months of reading and seeking advice from product people, I’ve come up with these key learnings that I’ve applied to Cronhub.

Don’t give up too many things in the free plan

We tend to give up too much in the free plan, especially in the beginning. It’s quite possible that your product doesn’t offer any free plan. But for Cronhub, I wanted to use this channel as a way to acquire customers. Limit the free plan to the minimum.

Know your customer groups

Knowing your customers is important, because it helps you understand how much they can afford to pay for your product. Cronhub’s free and developer plans are intended only for solo developers who have projects on the side.

I now also have two team plans: “Startup $19/month” and “Business $49/month,” and they are intended for engineering teams. Engineering teams should collaborate together, so the team support is necessary. Team sizes are different and that’s why I’ve priced these plans by the number of team members.

Think about your conversion flow

Picturing the customer conversion flow in your head is really helpful in understanding how pricing may work, and that’s why I’ve decided to offer a free plan.

I imagine the flow like this: a developer signs up for the free plan to use it for their personal projects. If they like my product very much, the chances are high that they will also promote my product within their company. It’s the word-of-mouth effect. Now someone from their company signs up to try the team plan, and there you have your potential lead who is very likely to become a customer.

Your pricing is probably too cheap

Don’t be afraid to raise your prices. We tend to undervalue our product, because we are afraid that no one will pay if it’s expensive. This is true especially for people who don’t have experience with pricing.

Unfortunately, pricing your project very cheap may discredit the value your product provides. It can make people question the quality of your product. That’s why you want to find the sweet spot where it’s not cheap and also not expensive.

Pricing will affect your long-term productivity

If you’re a single person team, then you probably do the product support as well. Higher paying customers tend to create fewer support requests compared to the customers who have signed up for the lowest pricing plan.

Think about your time and how you want to spend it. If you’re planning to stay a one-person team, then this will make a huge difference.

For Cronhub, eventually, I’m thinking I’ll only have two plans: a free plan and a business plan. The free plan will be for developers and the business plan for small and medium-sized engineering teams. Instead of having many low paying customers (and spending many hours answering support questions), I would prefer having a small number of high paying customers (and enjoy building a product).

Thank you very much for your time. I hope you’ve enjoyed reading this article and learned a little bit about side-project pricing. Writing is what I enjoy doing most after programming, and I hope to write more articles in the future. If you don’t want to miss any of my writings, follow me on Twitter. Feel free to send me a message or ask questions below!

Finally, If you’re a developer or part of a developer team that uses cron jobs, you can try Cronhub for free to monitor all your cron jobs in a beautiful dashboard.

Originally published at blog.cronhub.io on May 27, 2018.