Monetize Your Side Project: Ways To Get Paid

When you start building a side project, it is hard to resist daydreaming of one day gaining millions of users and, as a result, earning millions of dollars.

Unfortunately, most developers don't know where to begin when thinking about charging for their app & some are even deterred by the idea of running a business or doing sales. I fell into both of these categories when I started experimenting with building side projects.

I am writing this series for other developers (and Paige) who, like myself, are not interested in building the hottest start up or running a business. The goal is having an app that can make a few extra dollars each month & learning enough to know how to do it solo.

To get started it is important to decide exactly how you want your side project to make money. A lot of people default to thinking about two main options: ad revenue & set-price monthly billing. Both of these are excellent places to start and will be a good fit for a number of projects but, they are far from the only options. In this part of our series, we will be looking at a few of the most common ways to earn money with your app & determining which approach best suits your app.

Don't worry, there is a reference chart at the bottom if you don't feel like reading.

A quick note on Freemium:

We are not going to talk specifically about freemium because it alone isn't a billing model. But, keep in mind any of the models discussed here can use a freemium structure by adding a free tier with less features or allowing a certain amount of consumption to be free.

Ads

We will start with the most common, &  the "default" for most applications: ad revenue. Putting banner ads on your webpage or displaying pop-up ads has become the de-facto generating app revenue in recent history; just open any free mobile game & you will be virtually assaulted with Pay-Per-Click (PPC) & Pay-Per-Impression (PPI) advertisements.

Part of the appeal for using advertisements as the primary source of revenue is that it is incredibly easy to get started. Services like Google Adwords, Chitika, & Adversal provide super simple SDKs and APIs making integrations with them as simple as adding a few lines of code to your application.

A second major selling point is that once you have integrated, you don't have to do much maintenance. The ad services do all the work to ensure the ads that are displayed are the type of ads you want viewed in your application & in many cases offer user targeting to help show ads that are relevant to the user.

It is easy to see why using an ad integration is so appealing to so many people: low effort & returns that scale with the number of users you have.

With their low effort to get started & ease of upkeep, ad revenue integrations have a trade of with the amount of money paid out. The pay-out is going to be affected by a number of factors such as; ad placement (banner, sidebar, etc.), the type of ad, and who the target audience for the ad is.

Some sources claim that a website with ~1,000 users per day will make around $150 per month. Getting 1,000 daily users is no easy feat & $150 extra per month might prove for many people not worth it, but ad revenue can be really effective when used in the right places.

Here are the situations where ad revenue really excels:

• Apps with a very niche audience: Targeting a smaller audience with very specific needs will allow you to choose ads that pay more due to their specific nature. Having your application target "Software engineers working in .NET that build apps in their free time" is going to allow for more specifically targeted ads than just "Software engineers".  
• Apps with incredibly high page view numbers: If you are getting millions of users per month, you can throw pretty much any ad in front of them & profit. Apps that promote social sharing, producing or aggregating content, or a frequently used utility (think 10 Minute Mail) will negate the low profit margins with volume.

Advertisements are not always a bad idea but, they definitely have some drawbacks that a lot of people overlook (or ignore). Before plastering your app with ads; let's look at some alternative ways to get paid.

Licensing

Is your app something that your end users install on their own hardware? Then maybe using a licensing model is something to think about. Product licenses will allow a user to pay one time & be given permission to use the application in a certain number of places for a certain amount of time. How long & how much usage is up to you.

Licensing works incredibly well for applications that don't use any (or many) remote resources. Applications that are contained to a specific install on a machine that you don't have control over; things like Photoshop, Microsoft Windows, or video games use this model really well to charge an up-front cost & not worry about the user using remote resources or needing to manage for visiting users.

There are a couple of services available to mange product licensing so, you don't have to worry about generating, validating, & managing them all by yourself. Some products, like GumRoad, will act as a full purchase & payment portal for your products.

Licenses offer the ultimate "hands off" approach to the monetization pipeline; you don't have to track usage, you don't have to constantly try to drive traffic to your site, you don't even have to get your existing users back. One user makes one purchase. End of discussion.

Licensed products will typically have a higher shelf price than similar, cloud based products. There are a couple of reasons for this;

• Compared to similar SaaS products, licensed products will have a higher number of features or features that are unique to the product.

Because updating products installed on a user's hardware is rarely easy, the features licensed products have at the time of purchase are usually it. This means users will be expecting either a large number of features or, some incredibly unique features to offset the cost.

• Purchases are often irregular and inconstant.

Without recurring or consumption based charges, forecasting revenue is difficult. Past purchases are no indication of the future. In fact, many times a user that has bought the project last month is more than likely not going to buy again next month. We have to make sure that the revenue from the last purchase can last us until the next one.

With all this in mind, licenses can be appealing for applications with an infrastructure not managed by us or that require very few updates/enhancements. It could be worth considering if your project can be sold ad hoc.

Monthly Subscriptions

Now for the fun stuff. Recurring revenue is a goal for every paid product out there. Having money coming in reliably every month takes a huge part of the uncertainty of generating income which allows you to focus on other things. Offering your app as a monthly subscription is a very straight forward way to do that.

Most of us have used a service with a monthly subscription before. Services like Evernote, Spotify, or even Bloomburg allow users to pay a certain amount to use the app in some capacity. Many times the service offers multiple tiers of subscription allowing users who are willing to pay more to be granted more features or usages of the app.

Using a monthly subscription model for your application can help stabilize your revenue stream. Even better is there are quite a few payment providers out there that will manage the billing aspect with minimal effort on your part.

Companies like Stripe & Paypal allow you to write code one time to add a customer to your account & will manage recurring payments for you. Some companies will even handle account cancellations as well which, is one less thing for you to worry about.

One of the most difficult parts of getting a monthly subscription model set up for your project is determining how much subscriptions will cost & figuring out which tiers (if any) you will include.

A quick note on pricing:

Pricing itself is a really complex topic that wouldn't be done justice with a paragraph or two here. I will be covering it more in-depth in a separate post (I'll link to it here but, you should also subscribe so you know when it is out. Just saying).

Pay-As-You Go

Pay-as-you go billing has a lot in common with the monthly subscription model although there are a few key differences.

Unlike a monthly subscription, there is no set billed amount for the users. The usage for each user must be tracked throughout the month & a new bill calculated as a result.

This can lead to quite a bit of overhead with your billing integration & product in general. Having to track all of the usage by a user can get difficult when your product is an API or a product that tracks minutes/hours used (for example a voice to text product). User tracking is going to add new code to some areas of your application. If you are lucky, you will just have to track a single action which is significantly less overhead than multiple options.

The need to bill users based on their consumption for that period means that your system will need to have quite a bit of code specific to billing users:

• Tracking user consumption for a given period
• Calculating the payment due based on the tracked consumption
• Sending the bill/invoice to your payment provider
• Checking with your payment provider to be sure the invoice was paid
• (Optional) Keeping records of past usage & billed amounts

All of those extra "features" is enough to be a product all by itself (free product idea; you're welcome), making the pay-as-you-go model easily the most involved of the billing models. While it does require the most involved integrations & management, it also offers the most flexibility and control over your billing cycle & structure.

Donations

Donations are, by far, the most casual way to monetize your side project. They are not guaranteed payment for usage but, instead appealing to your users' generosity.

Typically, an app that accepts donations will use an integration with various services such as Buy Me A Coffee or Paypal to take your users to an external payment gateway so they can donate various amounts of money to the app's creator. A notable is jQuery, which is funded primarily by donations to the JSFoundation.

Using donations as a monetization strategy is great for keeping the relationship with your users casual. Donations send the message that you want as many people as possible to use your app, but it also isn't all about the money; if you donate, that's great. If you don't, that is okay too.

Some projects are suited incredibly well for donations. Maybe you don't think your application isn't big enough to be considered a full product or you don't have any interest in actively maintaining & updating it. Both of these use cases are perfect for donations; the casual revenue model matches the casual product model. If your project falls into this category donations are definitely better than assuming you can't make any money from it.

TL;DR - Comparison Chart

This ended up being a pretty lengthy post. I won't hold it against you if you didn't read it all. Here is a quick comparison chart you can use to help you decide which payment model makes the most sense for your side project.

The four major points to consider are; Difficultly of the initial integration, how much maintenance is required, revenue potential, & professionalism expressed.