Chris McCormick

In 2020 I made $693 USD from side projects. I contributed to several open source projects and made about a thousand commits on GitHub. I shipped a commercial game, a SaaS product, an IDE, two music apps, a handful of open source utilities, and a couple of websites. I love building stuff!

What I learned:

• Find demand before building something.
• Single-pay products are easier than SaaS.
• Build in public to boost the launch.
• Ongoing updates help people find the thing.
• Build websites to help people to find the thing.
• Being open source does not hurt sales.

The side project income mostly came from:

• A game called Asterogue
• A roguelike game template
• Two music apps (PO LoopSync and Beat Generator)

The SaaS products I worked on failed to generate more than a few cheeseburgers. 🍔 Good thing I love cheeseburgers. If you're doing a first time project and you want some quick wins then probably don't start with SaaS.

Most games follow a typical pattern. They earn all the money in a big burst at the start and then the income falls off to zero. I've heard this from talks by other indie game developers as well. There is a novelty factor in games. This was true for my game too.

I mainly got the word out on Asterogue by building the game in public. What that means is I posted in multiple game dev forums about progress as I was making the game. It was a big effort and the launch went alright as a result (as opposed to most projects which launch to crickets). My fastest sales were from Asterogue but they've fallen to zero now.

The two music apps have done better. I've had 3 months of steady sales from them. They're making a combined revenue of about $80 USD per month.

Beat Maker 3-month revenue

PO LoopSync 3-month revenue

I tried something new with PO LoopSync. I found demand before building. I studied a forum where enthusiasts of pocket operator devices hang out and I took notes. The notes revealed patterns in what they find important. Once I figured out what they want I made some mockups and asked them if it was what they wanted. When they said yes I built it.

This worked well and sales were good right from the start. Building stuff that people already want is more fun for everyone.

I've been building in public on different projects for a while now. It basically means I tweet about what I am making. Also, this very blog! When I launch something, people such as yourself can find out about it easily and tell others. That helps a lot to get the word out. Thank you for that!

I actually don't like building in public very much. It's uncomfortable. I especially don't like social media. So I've set up a system that allows me to interact with social media in an efficient and minimal way, but still be present. Maybe I'll post about that some time.

My problem up until now has been the bang-then-crash of launches. Initial interest and sales that then trail off. I've found two good ways to fix that this year. I guess you'd call these activities "marketing".

The first one is to post maintainance updates. Every time I update an existing project I try to post something about it. This probably seems obvious to a lot of people but it wasn't obvious to me. Each time I post an update I notice a small spike in interest and/or sales.

For example there was a gamejam for roguelike games this month. Leading up to the jam I made weekly updates to Roguelike Browser Boilerplate. I posted about them on the roguelike sub-reddit forum in their "saturday sharing" section. A bunch of new sales came in! Posting updates works.

The second thing I have tried is building useful websites that link to my apps. Marketing people call this SEO. I call it "building a useful website that links to my app". Not as catchy I guess. My friend Tobias showed me how effective SEO can be. There is also a good article about SEO by jdnoc that I learned from. Some people use SEO in a deceptive way but for me it's about giving my work the best chance to be found by people who are looking for it.

The first site I built is all about pocket operators. I used the research I did earlier to make a page about the most useful stuff. This got me on the front page of search for the phrase "pocket operator apps". Lo and behold one of my apps is a pocket operator app! So people find the page and then they can find my apps too. Here's a graph of the search volume on that site:

Another site I built is a free web app for generating random melodies. It's a procedural melody maker that generates midi melodies you can download. There's a link from the free web app to my other apps.

The name for this is apparently "side project marketing". So my side projects are being marketed by my side-side projects. The free web app shows up on the front page of search for a group of terms around "ai midi melody generator". One of the apps it links to is a random beat generator so the audience is very similar. Here's the graph of search volume for the melody generator:

So I think these two sites are a fairly steady channel where people find my apps. They're searching for "pocket operator apps" and "melody generator" and they find those sites and then they also sometimes click through and buy my apps.

There is one other way people are finding the apps. I have a free app on the Play store. It's an app for building music apps. So people who are already interested in music apps and development can find that, and then some of them also find my other apps.

The final thing I will note is that being open source has not hurt sales. Beat Maker is open source and I haven't open sourced PO LoopSync yet. So it's an imperfect A/B test but it's still useful. There isn't really much difference in the sales. There is basically only upside to being open source for somebody at my scale. People like it, and it builds trust, and it fits my ethics.

Anyway, I hope this is useful to somebody. I'll continue to post updates about my dev adventures and things I have discovered.

I've just released a melody generator that I've been working on for a while. It's a small web app that you can use to procedurally generate looping MIDI melodies and then use them in your own music.

The fractalesque algorithm it uses to generate melodies is one I came up with when I was writing a lot of algorave music a decade ago. The MIDI melodies are rendered to sound using the wasm port of Timidity by Feross.

Enjoy!

In October 2010 when the Android store was just a spring chicken, I built a minimal open source app that generates random hip hop beats called "Can of Beats". I had been getting into procedurally generated music and so I was able to build the app in a matter of a couple of weeks, and then I uploaded it onto the Android store just to see what would happen. It sold ok, paying our internet bill for a while, but as I had no idea what I was doing, I soon got bored of the low sales numbers and basically ignored it for 10 years.

Over the lifetime of the app it generated a couple of thousand dollars worth of sales. Knowing what I now know about the compounding effects of building things in public, I should have spent the 10 intervening years doubling down on that first trickle of installs, and shipped a ton of minimal audio apps, one after the other. Ah well, hindsight is 20/20!

They say the best time to start compounding any investment is yesterday. So in the spirit of that I've been working through November on some new minimal audio apps, and I'm also re-launching the original beat generator app with some new features!

One feature I'm particularly excited by is the Pocket Operator sync. If you don't know what this means, don't worry, it's for a tiny niche of people who are super into it. If you are curious about what a Pocket Operator is, look it up, they're awesome!

Nassim Taleb has this idea of "convexity". There's a bunch of complicated maths but it's actually quite a simple concept once you get it. This concept is useful for indie hackers and people bootstrapping businesses, because it gives you a general strategy that works in the presence of high levels of uncertainty (i.e. real life).

Is your business idea any good? Is there a market? Is the timing right? None of these questions matter so much if you choose convex processes.

So what is convexity? If a process is convex it means it has a big potential up-side and a limited potential down-side. Take a look at this graph and imagine your project is a marble that is pushed randomly to the left or right.

If it is given a push to the left then it will roll down the slope. If it is given a push to the right it will go up the slope. You can clearly see that there is a maximum depth the marble can go if it goes left, but it can go much higher if it goes to the right. Given enough force to the right it's going to fly off and your project will make a million dollars! So the down-side is limited, but the up-side is unlimited.

If some activity maps to this graph then you can say it's convex and those are the types of things you want to do. What you want to avoid is activities or processes where the opposite is true: all pain and no gain.

One of Taleb's insights is that we should not worry about the direction of the push on the marble because we simply can't know it. It's an uncertain world and the force on the marble is effectively random. We only fool ourselves if we pretend to be able to predict it. How many times have you launched something or tweeted or posted and not had the result you expected? You're going to be wrong a lot. Convexity embraces being wrong a lot.

So how does this apply to bootstrapping a business? All you gotta do is make sure you are picking convex activities at each step of your project. Decide if a given process or activity or action has a limited down-side and an unlimited up-side, and do it if so. Do lots of these convex activities to uncover reliable up-side and run-away successes.

Non-convex indie hacker processes (bad)

Here are some examples of non-convex indie hacker processes that you should avoid:

Quitting your job to go all-in on your unprofitable side project. This is non-convex because the down-side is ruin. If things go wrong you end up on the street with no job and a failed startup.

Spending a long time building without shipping. This is non-convex because the down-side is a loss of an unbounded amount of your most precious resource: your time on this earth.

Taking VC funding. Contraversial I know, but I beleive this is non-convex because you are locked into one business, beholden to the whims of investors, and you have given up all optionality (another Taleb idea I'll discuss below). Basically there is unlimited down-side in being beholden to somebody else's goals and not being able to do anything about it because they hold the purse strings.

Taking out a bank loan before you have paying customers. Taking on debt seems to be non-convex generally because of the unbounded way debts can grow.

Convex indie hacker processes (good)

Retaining some freelance hours while you work on side projects. This is convex because the down-side is limited (you still get to eat if you fail) and the up-side is unbounded if one of your side projects takes off.

Time-boxing your development and shipping frequently. This is convex because the time you lose if you build something that nobody wants is capped, but something you ship might actually catch on.

Posting on Twitter, Hacker News, and marketing in general. Marketing is convex because there is only a small amount of reputational risk and you have to be reeeally annoying to reach that level. The unbounded upside is having your product discovered by a market that really wants it.

Building in public. This is convex for the same reason as marketing. If you fail, or look like a fool, it's just not that bad. Upside is exposure, reputation, and viral adoption of what you're doing.

12 startups in 12 months. This strategy looks insane but if you look at how it works out for somebody like Pieter Levels it is convex. It's common for people to not finish their 12 startups and often the reason is because they also have the option to exit early on success (see below). It's a safe way to practice Taleb's "systematic convex tinkering".

Optionality

Another property you want is optionality. Let's take the Pieter Levels 12-startups-in-12-months example. Here you not only have convexity but you also have the option to take one of the 12 startups and run with it. Nobody is going to care if you stop at startup number 7 because it became a raging success that demands your attention. This is in fact exactly what Levels did. He launched Nomad List and Remote Ok, and then when it was clear they were popular, he took the option and went back and pumped them up.

So you also want to do things where you have the option to retain any up-side that is achieved.

Marketing is another good example. Lets say you post on Hacker News ten times and nine of those times you hear crickets, but one of the times your post blows up. Optionality means capturing that attention somehow so you can use it again later. So for example you might have an email list that people can opt in to. When a post does well you capture the up-side by letting interested people subscribe to your list.

Side note: are successful founders just lucky?

Elsewhere Taleb and Ole Peters and others talk about the concept of ergodicity, and two different types of probability: time vs. ensemble.

Ensemble probability is when you look at all indie hackers, and then the sub-set of "successful" indie hackers, and then figure out the probability of indie hacker success based on those two numbers. When I wrote that post which blew up it was about the ensemble probability of indie hackers, so it is actually a bit misleading because ensemble probability is the wrong way to look at it.

Time based probability is when you take a single indie hacker running many experiments, and look at their journey over time. It's the probability that one of their business experiments goes big.

The safest place to be is in the second category, running many convex experiments over time with no chance of ruin on any given experiment. You want to take the time based view because that is the one you actually have in real life. You are one single person, not many people in parallel.

Some successful founder stories are actually only visible in the ensemble category. They made one thing, got the golden ticket, and made a million dollars.

When taking the advice of successful founders you would do well to look at whether they are ensemble or time based. Did they try a ton of different ideas before succeeding? Good. Have they had more than one success or just one? Time based successes are the ones you want to learn from because they are repeatable. Individual successes from the ensemble are less useful as they may be due to good luck rather than good processes.

Conclusion

Run many business experiments sequentially, cap the down-side (time/cost/ruin), retain the option to capture any up-side.

Good luck! You won't need it.

PS You have the option of following me on twitter to find out about stuff I'm making. ;)

Footnote: I hope I have understood Taleb's ideas correctly, but if I have made any mistakes they are 100% my own.