Maybe you are like me and attended a coding bootcamp and as a result of that experience fell in love with working on personal coding projects? Investing time in a coding project lets you experiment with new technologies, learn new skills and improve upon your existing knowledge. There is a lot less at risk when you migrate a change to your personal project’s database than when you do so to your production database at work. Personal projects are the best, and you fully intend to keep it up once you start working as a full time developer, but then… Life happens.

It’s just not so easy to find the energy and the time to put into that project when you come home after a long day at the office. The best part, in my opinion, to working in software development, is you get to use your brain all day. But, those hours of thinking come at a cost. It’s mentally exhausting. You just got home after battling the rush hour commute and a full day of work and now you want to delve into that new React Context API?

Over the past several months I have dreamt, built and launched a side project while maintaining a full time developer job and making time for family and personal time. I am far from alone in this and many people, far more experienced than I, have found ways to keep all those balls in the air. Yet, in the hopes that this might be helpful to someone, I share some of my tips for making this sustainable:

1. Be Realistic In Your Goals

When you are at work you are accountable to business needs and a business time table. Your boss is viewing the overall business plan from her perch and works with you to set a time schedule to accomplish the tasks in a way that moves the work forward. Sometimes (okay, maybe often) you find yourself in a time crunch at work. Things need to get done by a certain time.

This is not the case with your own project. Maybe you wanted to launch the beta by a certain date, but you don’t have to, if by doing so, you drive yourself crazy and stay up until even the largest size coffee in the morning can’t get you moving. It’s okay to take your time in getting your project up and running. This also goes for features you’d like to add once it’s launched.

For example, I wanted to add a blog post topic tag feature to my project. I understood the mechanics of doing so in the Rails backend and in my React frontend. I sketched out how I wanted to display the topic in the blog post snippets. To accompany this feature, I also wanted to add a search by topic feature to the front page. However, every evening when I sat down to create it, I found myself tired. I was learning a new skill at work and by the time I got home I was exhausted. All I wanted to do was watch some Netflix.

At first I was disappointed in myself for not rousing the energy required, but then I remembered this is my project and the only time table I am accountable for is my own. It’s okay if it takes longer. Eventually, I spaced out the tasks over a period of a couple weeks and got most of it done. I still need to create that search feature, but that’s okay, that’ll get done too.

2. Be Your #1 Audience

Do you have dreams that this project will make it to the top of the app store? Will you retire on the income from this project? Those are really cool aspirations, but don’t necessarily stake your time and future on it. Why are you spending all this time on this project?

The best way to be motivated to put in the work on something you’re not getting paid for and something that takes up your weekends and weeknights is if you love it. Do you feel passionate about the need your project is addressing? Is it something you think about often? Talk about around the dinner table? Annoy your colleagues about during breaks at work? If yes, then you are on the right track!

I have always been passionate about Israel. It’s a topic that’s close to my heart and the idea of living there one day is inspiring to me. I have many friends who have made that move and love hearing about their decision and life journey. The notion that a people after millennia of fleeing from persecution, could now freely immigrate to a country of their own, for the first time in nearly 2,000 years, is mind boggling. I wanted to create a space where those who are on the journey and those considering the journey could share their thoughts in blog post form without judgment in a welcoming space. Facebook and WhatsApp groups exist for these conversations, but neither form of social media, is appropriate for long form blog post. So that’s why I created Rechov Aliyah.

3. It’s Also Okay If You Are Your Only Audience

You create a project because you think it fills a need in a certain space. You invest lots of time in creating it. You launch it. And… no one signs up, or only a few people sign up. The rush of users does not materialize. Do you feel a bit of let down? A little bit of disappointment? That is absolutely normal, but at the end of the day, you also created this project for yourself. Through it you learned new ways of doing things, you expanded your skill set. You took an idea that was in your head and in your heart and brought it to life. How awesome is being a developer that you have the ability to do that?

User acquisition takes a lot of work. Remember Google Plus? Are you still using it regularly? Didn’t think so. Why not? Some of the most skilled developers in the industry worked so hard on that. Ultimately, though, it takes a lot for people to gravitate towards a new content sharing site. You need a mass of people to come. How do you get that mass? By getting a mass of people to come. How do you get that mass? By getting a mass of people to come. Sound like a Catch-22? It’s because it is.

So, having said that, be okay if you end up being your primary (or only) user. Appreciate the craft of what you built and are continuing to build. Share it with your friends and family and maybe people will start using it, but try not to wrap your emotional experience around whether that happens or not. You’ll be happier if you don’t.

Rechov Aliyah continues to get a steady stream of visitor traffic and it gets a user or two signing up every couple weeks. I even had a couple blog posts contributed not by me. But, I haven’t had that mad rush of new users and new content, yet, I’m not depressed about it and happy to have created it for myself and hopefully one day others who will find it useful and helpful, or not, and that’s okay too.

4. You Can Stop Whenever You Want

Remember this is not a job.

The moment your project transitions from consistently being something that provides you joy and positive challenge to dread is the time to consider dropping it. Unless you have amassed some active users there is little downside to just putting it aside. You can always come back to it later. What happens though if you have gotten some new users who are regulars? How do you transition from it? Think about the user -> contributor -> partner pipeline.

Is there a contributor who could be brought on board to partner with you on the project? Someone who also loves what you created and has some technical skills? Ask her if she would like to work on a small task in the project, onboard her into the project. See if you can work well together. Maybe this is someone who can transition into leadership of the work?

No one from your users who can fill that role? Don’t be afraid of tagging your repository on Github looking for contributors. Maybe you’ll find someone that way. The Practical Dev has monthly posts where people can share their open source projects they are looking for help on. That might be a good place to search for a partner also.

However, if after all of that, you still can’t find someone and you have active users and you can’t even imagine looking at that project’s codebase again without feeling instant angst then gracefully shut it down. Share it with your users, give them time to transition their work to another space, and set a date for closure. You don’t owe it to anyone to work on a personal project you started forever, but you do owe some time to users who took the leap and became active to find a new home for their content.

I hope these tips that I learned over the past few months feel helpful. Do you have some tips for how to maintain a personal coding project while working full time? Please share!