fulgid techy things & other things by Noah Muth

Why Your Side Projects Need a Map

Sometime last year, I had an idea for an app: a Google Docs clone where documents would be saved as plain text org-mode files. Excited, I charged immediately into the wilderness, writing a complex API which would parse org-mode files and use operational transformation to support real-time editing by multiple users.

In the beginning, I made great progress, but after a few months I barely even thought about it anymore. I didn’t have some major life event or hit a technical wall or change my mind about the idea (I still think it’s a good one). The project just… died.

photo of graveyard
actual picture of my ~/Projects folder

This story is definitely not an outlier for me; I’ve abandoned so many side projects that I deserve a degree in abandoning side projects. Drawing on this wealth of experience, I’ve noticed a common pattern that almost always ends in failure:

  1. Start with an indisputably great idea: Hacker News for astrologers!

  2. Decide on the backing technical architecture: I’ll need a REST API that supports links, comments, users, karma…

  3. Implement some foundational logic: Can’t start working on a SPA until the API is finished!

  4. Work for a short while, then lose interest: I’ve been doing this for two weeks and all I have is an API with no interface…

It’s clear that the reason these projects die is lack of motivation. But we can dig deeper. Why, exactly, did I lose motivation working on that document app?

photo of chimpanzee thinking
let's help this chimp figure it out

Like I said, I’m something of an expert on abandoning side projects. And I can tell you that the projects which live the longest are the ones that know where they’re headed. In the examples so far, we’ve seen projects that start out with a vague or ambitious goal and no stepping-stones along the way. Instead, start by aiming for a tiny slice of functionality that can be accomplished in two weeks or less. Successful projects follow this pattern:

  1. Start with an immediate problem: Astrologers need a dedicated place to share astrology news.

  2. Come up with the quickest way to solve at least part of the problem: An anonymous link-sharing site is good enough to start. We can handle voting, ranking, comments, user accounts, etc. later.

  3. Decide on a technical architecture which directly supports that functionality: A form-based CRUD app will prove out the concept.

  4. Implement that tiny functionality in one fell swoop.

  5. Bask in the glory of shipping a product.

See how much more focused this is? Even user accounts are stripped out and left for later. A full-featured Reddit or Hacker News clone would take a few weeks of work to complete, but this could be accomplished in an afternoon.

The key to working this way is to think like a user. Users don’t care about architecture. Until they really start using your app, they won’t care about missing features, either. Users only care if your app solves their problem or makes their life easier. Taking a hard look from their perspective is a great way to scope down your project into tiny, achievable chunks– increasing its chances of survival by a massive amount.

If this “thinking like a user” is appealing to you, you might be interested in my upcoming eBook Building Tech in the Wilderness, which will teach you how to use that user-driven perspective as a map to stay on track, get out of tough spots, and make your project the best it can possibly be. Sign up for my mailing list for more updates!