Ben's Five Keys to Creating a Successful Side Project

Ever since I got into software (HTML when I was about 12), I have always needed to work on something that was deeply my own. So if I had my own personal project, that got all my attention. If I was working on a school assignment, or a professional development task, I have always found myself gravitating toward the side projects.

I have learned a lot from my projects, always doing things just a bit better than the last time. It was the learnings over time that really gave me clarity on my most successful side project, this website, dev.to, and @thepracticaldev. After lots of other projects that were promising, but ultimately fizzled out for one reason or another, I (informally) put together some criteria for the next project I would undertake. By any measure, it has been a successful formula, and I would like to share it with you.

Success can be measured in a lot of ways. I think this is useful advice that covers a lot of different concepts of "success"

The initial insight

While reminiscing on a project I did in college, I realized that it would have been a huge success had I just kept it up. Like, definitely. The project ultimately fizzled out for a number of reasons, but mostly impatience. A project I started in my bedroom was becoming a big deal, but mismanaging it, I ultimately let it fizzle out. At the time I had this thought that I had to grow grow grow and that if I was not scaling out the venture, it was going to fail. This was flawed thinking. Even the most modest growth would have compounded over time if I were able to keep the project fresh and interesting.

With some spare time, and the desire to write stable software and build an lasting something-or-other, I set out some criteria to build on what worked in the past. This time, however, it was not going to fizzle out.

🔑 Make it your own

It has got to be you. If you cannot proudly talk about what you are building and love pouring yourself into it, it better be something that you can "finish" soon. If it is a project that has to last, it better damn well be something that reflects your interests and passions. Time will turn your project into a success if you keep at it and keep being honest with yourself, but if you cannot sustain your fundamental interest in the topic you are building around, it will fizzle out.

🔑 Give yourself constraints

You are always going to want to change course when things are not quite working, or expand your idea to pump up some part of the success or make things easier, but please fight that urge and give yourself rules to abide by. For me, with the success of @thepracticaldev , I had to continuously fight the urge to do things that would require more people. By giving myself the constraint that things had to be done by me, I got better at pruning ideas and building my own administrative features to scale up my efforts. My core criteria was that I had to build a well-oiled machine, not try to hire help to maintain a hectic process.

This constraint has been critical. This is fundamentally what has made this thing scalable. Constraints are beautiful things, and they come in all shapes and sizes. But whether the constraints exist around your processes or your technology, find them and love them. You can grow past them over time, but live with them until it hurts and never break a constraint lightly.

🔑 Eliminate the time constraint

The one time constraint that I truly believe must be eliminated from the get-go for a successful side project of this kind is the time constraint. You have to think of this as something that will live on forever. You cannot be in a hurry. The book Originals really gave me permission to not rush things. As a side note, I would definitely recommend this book for parts, but some of it was thoroughly uninteresting.

You need to establish a workflow so that your project does not rot. Let a project lose forward momentum and it may fizzle. The loosened time constraint is key to establishing a healthy asynchronous workflow to last, but you need to maintain the discipline to keep it up without a deadline or a hurry. Rush when you need to rush and stay close to the idea by journaling about your insights, even if you cannot implement them immediately.

🔑 The project needs to evolve over time

Start with something basic and (probably) uninteresting to the rest of the world.

Even if your end goal is creative and exciting, don't build that. This can be a tough hurdle, because your first version of something may not be all that different or interesting, but you will learn so much just by getting some quick wins and launching anything. It will be frustrating because when you explain what it is you are working on, it will sound pretty uninteresting. But this needs to be part of the process. I think you need to be understanding of the idea that nobody is going to care about your project either way and you just need to keep plugging until it blossoms. Do not rush it, even when you wish people could see your future vision.

From a technical perspective, innovating less at first, but giving yourself a platform to launch from is key. Your code will be much better if you follow established patterns, and you will find places to nibble at the norms until eventually you have build something uniquely yours and truly awesome.

🔑 Start it yourself, eventually find help

I'm not dead-set on the "start it yourself" part, but that definitely worked for me. I am an independent worker, but that may not work for you. I would encourage starting alone withs side projects, though. It is a good constraint to ensure the project fits your strength and there are no issues in terms of motivation, time commitment, success metrics, etc. Even one additional person can put a wrench in all of this. Just take that into consideration. Certain social relationships, like a spousal one, may have an easier time overcoming expectation imbalances.

Eventually, there is a find help inflection point, and you will have to discover that for yourself. Do not jump to this part prematurely. This was my biggest mistake in several previous side projects. Living with the one-person constraint for as long as I could, and eventually finding a great complement to the project, in Jess Lee really made this whole thing succeed. She is a friend and we get along, but we have totally different skill sets. The project had already taken off by the time I got to bringing her in, but this was the first major inflection point in ensuring that this project was going to make it.

Closing thoughts

I hope this was a helpful read. This has been such a fulfilling project and I cannot wait to see it grow more. There has been another recent inflection point of sorts where Jess and I have more help on the project. That's a work in progress, but it's been very exciting. The future is bright for this so-called side project. I hope you can find a project you are willing to pour years of your life into and find satisfaction with.

Please do not be pressured into making it commercial. There are so many fulfilling open source projects that could benefit from the thoughts I have outlined here. Creating a venture that is designed to eventually make money is all well-and-good, but once that becomes a pressure, the ability to eliminate the time constraint is quick to break down. Just be aware of that dynamic.

P.S. If I were starting another side project today, I would strongly consider making it a project focused on building a public API around something. People often jump to building the full stack with a user interface, but if you have an area of interest, I highly recommend building and maintaining an API-only service. Find something in the world that is not well-modeled in software, take the time to build and maintain an ingestible API. Also, make your project open source sooner rather than later. This project will eventually be open source, but I regret not doing that from the get-go.

If you have any feedback, please feel welcome to leave a comment below.