← Writing

A Calm Side Project

There’s no way round it– side projects come with some measure of responsibility. As soon as you have users, fans or even customers, you can’t just leave anymore. People will be counting on your thing to work. Having customers means success but if you’re already drowning in one inbox then adding another busy one is not going to feel like success.

If your day job takes up all your waking hours, if it feels like the house is on fire at all times, if you feel bad when leaving the office –or closing the laptop if you’re a remote worker like me – then a side project isn’t a good idea.

If, on the other hand, you’re in the privileged position that your day job leaves you with time for yourself then there’s plenty of room in the week for side projects.

But because work on side projects is mainly (if not only) driven by your own excitement and curiosity, and because you only have so much time left after your regular job, your side project should allow your effort to go up and down without turning into, as they say, a garbage fire.

We don’t want garbage fires. We don’t want to burn out so we can’t keep doing the good work. We’re in this to build quality projects and quality connections to the people who use our thing. And if we’re constantly putting out fires or doing uninspiring, dreadful work, we won’t have the excess energy to do the good work.

Sometimes you will put in 2-3 hours and get loads of shit done. Other times you’ll feel like rewatching Arrested Development instead[1]. This should be alright, mostly always.

If your idea or app requires consistent, daily work, consider this: Can you repurpose or re-shape it into something that doesn’t require your every waking hour? It might feel exciting right now but in 2 years you’ll wish you never started.

  1. Don’t build business-critical things.
    For example, things that come with multiple nines[2] of guaranteed uptime. As soon as people rely on your service for the critical parts of their service, you’re on the hook. That’s why companies have revolving on-call schedules so one employee can go on a holiday or, well, sleep, because someone else is on the hook. When you’re just you, you are just you. No sleep.

  2. Automate the right things and at the right level.
    Between hand-holding users and fully automating things, there’s a scale of partial automation.
    If your signup process is hard to get right, maybe it’s better to do it manually for now. This is a good idea if you have few but large fish. Terrible if you have thousands of small krill.

Charging users (if you are so lucky) is something that often comes with lots of ifs and if it does, it can probably be done manually at first.
I love the idea behind the project Runbook where every step can start as a manual, human task, before gradually becoming automated.

  1. Use the tools that you know.
    Even though I’m always tempted to use something new and flashy, I mostly just use good ol’ Ruby on Rails. Even though I’m curious to learn Figma instead of Sketch, I make myself use the latter. This ensures that the mere 3 hours I have, go towards something constructive.

This is not meant to be an exhaustive list. It’s merely a suggestion of things to look out for before starting your project or how to calm down projects you may already have on your hands.


  1. Season 1-3 only, of course. ↩︎

  2. Service availability is measured in how many nines you can put as decimals after 99%. 5 nines means the service is guaranteed available and functioning 99.99999% of the time. If you’re down for one hour in an entire year, you’re for example already down to 99,9885844749% uptime. A single nine. ↩︎

Join my mailing list

Receive a note when I publish new writings on building, shaping and running small-to-medium software.