TLDR;

1. Build something that you actually want to use. Since the user is you, it doesn’t matter if it’s innovative or if someone has done it before.
2. Pick a comfortable number of new technologies to make it technically interesting, but not too many.
3. Focus on the core experience first (making it usable) and worry about the rest later (or never).

Looking through twitter threads or reddit forums related to programming, you’ve probably come across this sort of post: “Any ideas for a good side project?” If you’re thinking about creating a side project, you’re essentially thinking like anyone else in a creative field. It’s like an author saying “what story should I write next?” The only response that makes sense to me is “well, what’s something that would be fun for you?”

Maybe you really just don’t know what you should make. Or maybe you’re suffering from the developer’s equivalent to writer’s block. I think I’ve found a fairly good formula for thinking about side projects (see the TLDR;) and thought it might be helpful to share for people who find themselves asking these sorts of questions.

Who this is for

• People who enjoy building things, but don’t know what to make
• People who start a lot of side projects, but often end up stuck in “the setup phase”
• Junior/mid-level developers wanting to build a portfolio

Who this is not for (but for whom it might still be somewhat useful)

• People who want to turn a side project into a side business
• People who want to mainly focus on OSS development

Who, really, is going to use your thing?

I think some of the hesitation about what sorts of things to create comes from the following desire: you want to build something that other people will want to use or will think is cool.

First off, if you really do have a novel idea that you think other people will also find useful or interesting, that’s great! Go ahead and buy that domain name and start that side-business, or if it's more of an open source-minded project, then go ahead and publish the repository, share the project, and enjoy watching the number of stars climb on Github.

The problem is, however, that unless you have a specific problem or community of users in mind, it’s difficult to know what other people might want. Companies spend a lot of money trying to understand what things they should make. It’s actually a whole field in and of itself. If your main goal when developing something is external acclaim, you might be a little discouraged when the response is lukewarm, or at worst, no response at all.

What if you just focused on creating something that you, yourself, actually want to use? The great thing about creating something for yourself is that you have a clearly defined user (yourself) with clearly defined conditions (whatever it is that you want). It’s a one to one feedback loop between the creator and user. Who cares if other people think that the thing you made is innovative or unique? It is innovative and unique in and of itself because it is built for a very particular user with very particular desires.

Example 1: A shopping list

Here’s an example: I wanted an easy way to share a shopping list with my wife. She’s not that technically savvy, so the UI needed to be extremely simple. So I made a little web app that lets us share a shopping list. In other words, a todo list – the most basic and boring thing that you could ever create.

There are thousands upon thousands of apps that we could have just used. I’d even made a few todo lists before. But it doesn’t matter. There’s no outside audience here. It was just me creating something for the joy of it, that actually solved a problem that I had in my life, and that was actually useful to someone – even better in this case, two people! And it was technically interesting enough for me. I wanted to play around with Firebase and it was a perfect opportunity. And hey, I now had a public, (minimally) feature complete project that I could point to (albeit, not one that I think would be interesting or worthwhile to anyone else, but that’s besides the point.)

Don’t worry, the point of this is not to say “just build a bunch of todo apps!” The point is to try to convince you to avoid creating unnecessary expectations before you’ve even started. Going back to the comparison of creating a side project to writing a book, it’s important to avoid “preparing your acceptance speech for the Pulitzer Prize before even writing a single word.”

Again, if you have an innovative idea for something that you think will turn into an exciting open source project or lucrative side business, that’s awesome. But if you don’t, that doesn’t mean you shouldn’t be creating things. The path from side project to passion project to OSS project/side business is a natural one, and much more realistic than starting with the goal and working backwards.

Keeping it technically interesting (i.e. killing the right number of birds with the right number of stones)

Another important ingredient for a good side project is choosing what kinds of technologies to use. You want to build something that is creatively and technically interesting to you. It should be fun. My advice here is to choose enough new things that the project itself is technically stimulating, but not overwhelmingly so.

Any developer who has worked on a side project has inevitably found themselves in the following situation: you’ve got a Saturday all to yourself and you have a good idea for a new project. Your mind starts racing. "I’ll try using this thing for the first time. I’ll research all of the newest build tools, frameworks and libraries, and make sure everything is perfect."

You start reading documentation and hacking away and before you know it you’ve just spent the last hour cross referencing various issues on various repositories because the latest version of some library doesn’t work with some other thing and the day is over and you’ve accomplished nothing. You turn off your computer and never touch the project again.

The amount of new stuff to try out really depends on the person. Personally, if I don’t have at least something on a screen by the end of the day, I’ll lose motivation and probably never work on the project again. Some people are more (or less) patient, and the amount of time someone can invest in setting up a project without losing focus will vary person to person. But it’s important to get a sense of what that sweet spot is for you.

It’s also important to remember that not all technologies are created equal. Trying out a new css library is not the same as creating a native application for the first time. Trying out a new framework is not the same as trying out a new language.

Example 2: A personal finance tracker

I’m really bad with keeping track of the money I spend, and so I thought, hey, why don’t I make a little app for logging my expenses. It could have some simple labels like “Food,” “Socializing,” etc., and it could show me how much I spent in each category each month.

Much like the shopping list, personal finance tracking apps are a dime a dozen. And some of them are extremely feature rich, with the ability to link bank accounts or credit cards and even automatically read the data off of physical receipts. But I just wanted something really simple, and I had a general idea of how it would work. And I also just really wanted to make something.

I wanted to try out FaunaDB with its automatic GraphQL api generation, and I also wanted to finally try using the React version of Material UI. Furthermore, I wanted to try my hand at making a PWA. The rest would just be the normal stack of whatever I was comfortable with at the time. I got it up and running fairly quickly, and had the core of it done in a couple weeks. I did a little more development here and there, used it for about a year, and then stopped. But, it’s still there, and still something that I actually used for quite a while.

And in this case, it actually helped me to get my current job. When I first applied there was concern about my experience with React, and so I said: hey, here’s this thing I made. It’s not great, but I think it shows that general experience with React shouldn’t be an issue. And thankfully, they reconsidered.

A note on portfolios: in general, I think it’s good to think about your portfolio less as a showcase that will wow potential recruiters, and more as potential fodder for discussion. If you apply somewhere and there is concern about your experience in some area, you can use it as proof that you at least have experience in that domain.

For this reason, I’d advise against deleting old projects or making them private. No doubt, looking at code you’ve written in the past always feels a little… embarrassing? We grow so quickly and fast as developers, and looking back on a project you created even a year ago can feel like looking back decades in time. But the benefits outweigh the negatives. Your past projects are a record of your growth, and any potential recruiter or employer who wouldn’t it see it that way is, in my opinion, a place that you wouldn’t want to work.

Do it until it’s done (there’s plenty of time to do it better later)

So you’ve got an idea for something you’d like to do, you’ve picked out a couple of new technologies that you’d like to try, and you’ve started to build something. How do you know when this side project is “done?”

Since you’re creating something that you want to use, you naturally have a general idea of what the minimum functionality for that thing is, and the creation of that is what you should be initially aiming for. You can think of it as an MVP, but since this is something that you’re just having fun doing in your free time, it’s ok if it isn’t so formal.

Personally, for me, done is when the initial idea is implemented, the thing "works" and I’ve spent enough time exploring and using the new technologies that I feel technically satiated.

For this reason, I'd advise kicking the can of implementing user-facing sorts of things like authentication, payments, or traffic optimizations down the road unless they are core to the project or part of the new technical things you are exploring. If you finish creating the core experience and feel that it is something worth sharing or developing into a service, then you can handle that sort of stuff later. If you share your project and a bunch of people visit the site and bring it down... congratulations on your newfound fame!

Example 3: A scraper for a podcast

My friend and I have a podcast where we talk about Japanese convenience stores. One thing that we do each week is that we look at all of the new items coming out and then choose ones that we think look particularly awesome or weird. Usually this involves something like 250 new items across seven different convenience store chains. We usually open up seven different tabs and just manually look through each of the items that way.

I thought it would be cool if we could make this process a little bit easier, and so I decided to make a scraper that could get new item data and make it viewable in a custom web app. Someday, perhaps this scraper could scrape all of the data for each convenience store, and maybe we could share it with our listeners. But the minimum functionality that I envisioned for this first step was: try to create a scraper that could scrape the items, and display the items for one convenience store.

In terms of new tech, I wanted to try building a monorepo, and I wanted to play around with Playwright. That was it for new technology for this project. I got it up and running pretty quickly, and in this case, went on to continue developing it fairly regularly. The project has extended into being a sort of passion project, and one that we have actually shared with our audience.

I guess the thing that ties all of this together, and the point that I want to stress more than anything else, is stop inventing unnecessary obstacles for yourself and just enjoy the process of creation. It doesn't matter if your thing is boring, or uses a mediocre stack, or isn't 100% feature complete. It's important that you "actually create things," and that you learn and have fun while doing it.