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.

In terms of companies doing this at scale, I'd point to Twilio or Stripe, and many others. Just because they are a huge startup doesn't mean the model is different for side projects. A lot of cities provide their data in ingestible formats so people can independently build things like transit apps as well.

You're providing the building blocks for others to hack on top, and by focusing down, you can really take your time to get that layer right. By cleaning the data and making it available in an ingestible format, somebody else can come in and do whatever creative thing they want with it.

A lot of people end up making APIs, but I'd say it's often the case that they would be better off doing the heavy lifting on the data layer and letting others build on top.

This is a very interesting suggestion and I love it honestly.......I built an API once for my internship and since we had extra time we ended up developing UI on web, android, and iOS but the company loved it solely for the API we built because it aggregated data much better allowing for more creative uses than we could have imagined for it.

I would absolutely contribute to others' projects and allow contributions into yours. When contributing to others' projects, you are adding value back into the machine in great ways, building contacts, and gaining experience. I'd advise when starting your own projects, just to make them worthwhile in and of themselves, with lasting value. They shouldn't be projects that you would abandon if they don't gain traction quickly.

Thanks for the compliment on the post. I hoped to provide genuine help based on my learnings. Empty motivation is pretty lame if you ask me.

I feel so grateful I read this! Views need data. All this time I have been trying to balance both out. I have been trying to be that Full Stack Mythical Unicorn - right now I am just a multi-trick pony. But for the side project I have been working on, the data it caters is fantastic and needs to be out there for anyone to see and use for their benefit. After this, I am going to focus on the API :) I think it will help me boost my resume - despite applying to mostly Front End roles, I think a dev who understands the backend and data generation is useful :D

Thanks for this post. I saw this at a point in my life where i am almost apathetic about programming due to the fact that all my side projects have been one steady sail down the sea of flops. I am currently working on a question generation web app for universities and as i continue, it feels like the project is already a failure even before completion. Hopefully i will use the points gathered from this post as strength to keep forging on.

Your "start it yourself" recommandation makes a lot of sense for me. Everytime I had a cool side-project I wanted to work on, I used to bring in a friend of mine on it and right afterwards I had no more interests in the project. That's something I don't do anymore though. I noticed that I really work on it only when I'm alone as I can whatever I want and take the time to learn what I need to learn.

Very nice conclusions.
Quite coincidentally, I have had similar thoughts in regards to starting strictly with API around any idea. And few days later I am reading about it here. Gotta give it a go next time. :)

Love this. Really resonate with the need to have something that is entirely your own. I wonder if it's because in my professional software job so many of the problems aren't tech problems, but more about convincing people about certain things. So it's nice to have a problem space that's purely technical.

Also, +1 on the API. Even in my everyday work when we're planning a new solution I always gravitate towards API first. It makes building the front-end easier and unlocks oppourtunities for the boundless creativity of our partner teams and customers. Of course many of my co-workers want to do the full-stack at once so it takes some convincing (which is one of those people challenges I mentioned earlier 🙃).

This really reminds me of myself. 17 years old but I can relate to the time from 12 years old till now.

Disappointing thing isn't patience for me, it was money. Never had enough to get something going as a prototype due to my struggles with my parents and my pride keeping me away from their financial help.
2 years later from the first project, the main winning feature showed up in Instagram.

However, ended up earning an internship to work on the second project with a team before starting college.

Money was a huge issue for me and my family growing up as well. But my background made the perseverance part much easier once I "made it" in the industry. The money issues with my family also fueled my impatience (and they continue to). I'm desperate to help my mom retire.

This was the best thing I could read right now. 100% relatable. Helping my mom retire is a large portion of my daily motivation and inspiration to wake up every morning and compete against my yesterday. Money kept me away from developing my talent in Software Engineering for some years, but I am happy that I have slowly been able to merge myself with the industry. Once I find a full-time job as a developer, I feel that will be the catalysis for me to hone my skills to a much higher level.

Do you mind me asking how you “made it” in the industry, please? Thank you.

I've had so many side projects that just fizzled away. Even ones I saw to technical "completion". Keeping up motivation is a very hard thing to do when alone. I think you might understate how much you need to love your own work. It's not enough to just be hyped at the start, you need so much momentum to roll through the lows of interest after a year or two. There are so many products, even free ones, where 1-2 years simply won't be enough to garner outside interest.

That said, it's obviously key to get outside interest early, if for nothing else but to keep you motivated. Unfortunately this introduces even more prioritization of your time.

I do think people shouldn't worry about the "competition" more than just a bit, but I wouldn't purposefully remain ignorant. A certain amount of research is only a positive. It can be tempting to mimic the work of others, so I'd recommend writing down your fundamental hypotheses before you do the research and be honest about whether they are true after you've examined the landscape.

One lesson in researching prior art is to pay attention to what people are doing in different domains, but with business and technical patterns you can borrow from. Rather than paying too much attention to the domain you're entering, pay attention to what folks in other domains are doing well that you can borrow from. The story that gets referenced with this concept is Ford paying attention to the best practices of the slaughtering industry, rather than the automotive industry, in order to improve the automotive industry with the assembly line. Ford references are sort of cliché, but I like that one.

Ultimately the value of any good idea will be realized well in the future, so use the current landscape for data, but don't get too caught up in it. Keep re-evaluating your fundamental assumptions and use those as your guiding line to avoid the contamination you're speaking of.