Never miss a beat

Join my newsletter.

Incomeware: Making money on side projects

Posted: 6/17/2022

Tagged under: businessside-projects
Incomeware: Making money on side projects

I have had a lot of side projects over my 12 years as a software engineer. Most of them are software projects, but some of them (like this blog) are not. The costs for running a side project can really start to add up and they add up even faster when you consider paying yourself or someone else for work. Thankfully, there are options for monetizing your projects to help offset costs for server hosting, professional services, fees and more. Here's how I look at monetizing my projects.

In regards to software projects, there are four main methods for generating income around your projects.

  1. Ads
  2. Subscriptions
  3. In App Purchases
  4. Pay to Use Software


Ads are extremely easy to setup and the barrier to entry is extremely low. Google Ads is the most approachable Ads Network that I've found, but there are more specific networks like Carbon that offer different (usually better) rates but have tighter constraints. Most of the time, setting up Ads for a project involve creating an account with the Ad Network and adding some JavaScript (generated by the Ad Network) to your webpage or setting up their Ads SDK for your mobile/desktop app.

Ads are ultimately a tricky monetization strategy. A lot of people choose to use Ad Blocking software because people have aggressively shoved ads at them in the past. There are still plenty of news sites that shove a full page (interstitial) ad at you as soon as you load the page. There are plenty of sites that do a little better but still shove a half page banner in your face and cover the right side or left side of the page in ads. Unfortunately, even if you do use ads in a mild fashion, the people burned by aggressive advertising in the past may never see your ads -- and if your ads aren't being viewed, you aren't getting paid.

Ads are a particularly nice monetization strategy because they involve so little maintenance. Occasionally, I'll have to go in and accept new Google Ads terms but that's really about it.

I've used Ads in several projects, but the most notable one for me right now is my blog (you're reading it!). I use Google Ads with "Auto Ads". Auto Ads place the ads on your site for you, but you can also constrain where they do and don't go. I've configured mine so that they only show up on blog pages. Unfortunately, this doesn't work super well with Single Page experiences like Gatsby (what this blog is built with). This instead gets executed as "Only show ads if the user's initial page load is a blog page." I still have some work to do to iron out ads with Single Page Experiences, but overall ads have helped me pay for server costs (when this site was built on Wordpress long ago) and help pay for coffee now that I'm hosting it for free as a Single Page App.

I'd recommend starting with Google Ads if you're looking to monetize something new via Ads. If its a mobile project, I'd look at Google AdMob for the same thing only for mobile.


Subscription services are probably the most complicated of the payment options that I'll support. Luna Journal leverages a subscription to provide users with extra features. Subscriptions help provide recurring income from users that are willing to pay for your project. Generally, subscriptions are used in one of two ways. The first way subscriptions are used is the "Freemium" model. In this model, the base experience for the project is free, but there are paid services that a user can add on. Luna Journal follows the Freemium model. The second model is the "Pay to Use" model. In the "Pay to Use" model, the user does not get access to project without a subscription (barring a free trial or similar).

Subscriptions have a fair amount of overhead associated with them. If a user can subscribe to your project, they'll also want the ability to cancel their subscription. Additionally, you'll need to provide receipts of purchase. In some cases, the user may also expect premium support if they're paying for your project, too.

A lot of the overhead associated with subscriptions can be managed by working with a platform. I strongly recommend this, too. You do not want to process/store credit cards if you can avoid it. There are a lot of subscription management platforms out there, but in the past I've used Stripe, Chargebee, and RevenueCat. Stripe is probably the most commonly used subscription service platform so if you're not sure where to start, I'd recommend starting there. RevenueCat is what I use for Luna Journal, but its a bit of an oddity here. RevenueCat abstracts the App Store subscriptions (both Google Play and the Apple App Store have subscription offerings, too). RevenueCat helps make integrating with the underlying platform easy and provides dashboards for monitoring transactions and tools to help resolve issues. The catch to these subscription management platforms is that they need to be paid, too. Stripe takes a cut of all transactions, Chargebee has a monthly fee, and RevenueCat has a monthly fee, too.

In App Purchases

In App Purchases are the newest player in the monetization field, although they've been around for a while. Conventionally, these are most acceptable in mobile apps and games but I think you could make them work anywhere provided the offering is good enough. With an In App Purchase, the user pays money to unlock something that they normally did not have access to. In some cases, this may be Game currency, extra lives, extra photo filters, removal of ads, and more. The general idea with In App Purchases is that a user can get enough value out of your project before making a purchase that they trust the quality and offering that you're selling to them. This model works great for users who may not be willing to pay for something without trying it first. For example, I may not pay $4.99 for a photo editing app until I've edited a photo with it. Even if the specific filter I want is a paid feature, trying out some of the other free filters might build enough trust for me to buy your premium filter pack. Additionally, you can allow users to buy individual items instead of packs. This could help motivate users who only want to use a single filter to buy the single filter they want for $0.99, when they would normally not purchase the $10.00 filter pack that contains that single filter.

In App Purchases can be built using some of the tools already mentioned. For web, desktop, etc, you can look at Stripe. In addition to their subscription offering, they support digital product purchases, too. On mobile, you'll likely need to use the Google Play In App Purchase System or the App Store purchase system. These are, unfortunately, requirements for making purchases through apps on those platforms, although this may be changing.

Regardless of what you go with for In App Purchases, no one is going to do that for free. Stripe has a similar cut as if you were doing a subscription service through them and the Apple/Play store takes a cut, too.

Pay to Use Software

Pay to Use Software is the classic paid software experience. In this monetization model, the user pays you a set fee for the right to use your software. The most common example is buying a CD of Software from a store like Target or Best Buy. For better or worse, those days have mostly passed, but the idea remains the same. Now the store front is the Apple/Play store or a digital storefront like Steam,, Gumroad or something built by the seller of the software. Pay to use software sometimes comes with a License Key that is required to activate the software but this is not always required.

Pay to Use software has medium overhead, but this can alleviated by selling through a marketplace (, Gumroad, Apple/Play store). Pay to Use software can include all future updates or can simply be for the software "AS IS". Things, a popular task management software is an example of a mix. With Things, you pay for the major version and all updates associated with the app. When Things went from V2 to V3, you had to purchase V3 separately. This can often receive a lot of backlash from your community, so you'll likely want to think carefully about this. A potential solution is to provide a steep discount to existing customers if they upgrade.

Don't Store Credit Cards

I seriously can't stress this enough. Using third parties to process credit card information is what keeps your side project a side project. As soon as you start storing credit card information, you open an entire world of hurt in terms of compliance and security. Your single developer project does not have the security that Stripe's 2,800+ employees can provide. Do not store credit cards. You've been warned!