I’m a huge advocate of side projects and I spend a great deal of my free time on them. Here’s why:
- You get the chance to experiment with modern/fun technologies that, more often than not, you won’t be able to in your day-job.
- You get the change to work on a product from end-to-end. Meaning, from conception, to deployment, to marketing. You’ll get firsthand experience with things that would normally be delegated to other teams in your day-job.
- It helps building online presence and that certainly won’t do any harm to your CV, career, network and professional evolution.
- Depending on what you decide to work on, it’s like buying a lottery ticket that, if against all odds, you win, you’ll be able to make passive income.
Usually, when I want to learn new technologies, I build something real because getting your hands dirty is the only way of actually making sure that you got it right. You need those “aha!” moments you won’t have just by reading/watching tutorials. Most people build ToDo List apps. Here’s my first advice: Don’t. If you’re going to spend your super precious time on something, make sure to at least spend it on something that has the least chance of adding value to other people. Make something useful.
However…
The bitter truth is: Undoubtedly, most side projects will “fail”. The majority not even reaching the first release, and those which do, often will eventually become abandonware. Beneath the waves, GitHub is a graveyard.
Not even Mubashar Iqbal, known for being one of ProducHunt’s most prolific makers is invulnerable to that.
This article is about helping you to pick one that will maximize your chances of not being part of the statistics.
Build something that will solve a problem that you have
I’m a big fan of Courtland Allen’s IndieHackers and I read most of the founder interviews and listen to every single podcast. The majority of the successful stories are about people that solved a pain they had themselves, or people that spent years working on a particular industry to the point they had enough firsthand experience to know what they could do better. For a side project, I strongly recommend the first: Do something that would solve a pain that you have. For a couple of reasons:
- You probably have made an extensive search on the web and didn’t find anything that would solve this problem, exactly the way you want.
- You already have a customer: You. And having you as a daily user, is going to make it easier for you to find flaws and aspects in which your product could be better.
- The world is big enough to be safe to assume that, if you’re actually able to ship something that solves your particular problem better than the alternatives, there will be more people interested in what you’re doing.
Build something minimalist. I mean, really.
Believe me: If you are an experienced developer, chances are that you are going to overestimate your own capacity. It’s common to feel like you’re more productive alone than you are inside your organization, and this is true to a certain extent. For a 200 hours project, yes, you’re going to be more productive alone, because:
- You don’t have to spend hours in fruitless meetings.
- You don’t have to convince anybody of your own point of view.
- Your code will be super consistent and strictly follow all the code conventions: Yours.
- You have to write less documentation and tests because, you know, all developers know 100% of the code. I mean, you.
The real problem lies when you think that you, the lone wolf, or your pack of 2 to 3 colleagues, on your spare time, will be able to build something that, in reality, would require a full-time team. Again, it’s really easy to overestimate your own capacity. To deliver a real software project is a painstaking challenge no matter how simple it appears to be on the surface. I failed multiple times until I realized that I would only ship something if I kept to the bare minimum. Think of how hard it is, for example, to deliver a SaaS project that doesn’t do absolutely anything: You still have to think of authentication, authorization, user management, e-mail confirmation, builds, deployment…
Additionally, the ideal strategy is to look for something that can start tiny but still have room for improvements. The challenge here is that it is increasingly hard to find simple ideas that still don’t have near-perfect competitors out there. As I mentioned, I try not to work on stuff I don’t think have a chance to add value to other people. But believe me, there’re still a loads of things yet to be done in this vast world.
Build something that is likely that you’ll still be interested in 3 years from now, and commit yourself to shipping in maintaining it.
It’s amazingly easy to find something the best idea of the world today, just to drop it for the next big thing tomorrow (add alcohol for extra effect). Be sure to think 10x before starting something. Please, do yourself this favor.
If you’re building a library, for instance, it’s absolutely guaranteed that you’ll drop it unless you or the company you work for will actually use it in the long run. Believe me: Don’t build and open-source a library that you won’t use. You’ll inevitably lose interest and cause a giant hassle to everybody in the community that trusted that you would continue to maintain it. Libraries, much more than apps, need maintenance, specially because of dependencies. If your library depend on React, you’ll have to update it to continue to work with React 16, 17 and so on. Again, think 10x before starting something and making it public. You have to commit.
Do not build communities/social driven apps. If you’re building a web or mobile app, build the simplest possible tool or game.
The recent multi-million acquisition of tbh by Facebook is a proof that it is still possible for small companies to be innovative and release social apps in spite of the fierce competition from FAANG. Cool? Sure, but don’t do it. For a simple reason: When it comes to social apps, the development of the app itself is just a drop in the ocean compared to the effort of making it to catch on. Imagine, for example, building a market place to help finding nearby professionals like ThumbStack. After the app is done, now you and your team need Jedi-level marketing skills and lots of money to make it catch on because you won’t have enough professionals to sign up until the app is popular, and it isn’t getting any popular until it gets lots of professionals. TL;DR: Out of your league. Don’t do it.
Build the simplest possible tool or game that people can enjoy alone. If, throughout the process of making your app, you end up building libraries you think people would be interested in, consider open-sourcing them on GitHub.
Spreading the word
Here’s what you’ll do after you ship your side-project:
- If it’s a web/mobile app, post it on ProductHunt.
- Post about it on sub-reddits that might have interest.
- If you there’s a slight change HackerNews would be interested, post it like “Show HN: Look at this cool thing I’ve done. What do you think?”. The same for the IndieHackers forum, but starting with “Show IH:”.
- Tweet and blog about: What you’ve done; The experience you acquired throughout the process; What you’ve learned; What you could have done better/different; Stats (people love stats); Your plans for the future. If you fail, write about it too.
Epilogue
Work hard; Overnight success is a fairy tale; Constantly listen to your users; Start with an MVP and commit to progressive improvements and save yourself the time of starting something you won’t commit to.
I wish you the best of luck. Happy hacking! ❤
To learn more about me, please visit https://aboutdevs.com/andrerpena