Working on side projects helps me learn new technologies, improve as an engineer and designer, and exercise my creativity. Through building side projects (which range from the mildly useful to the completely inane), I’ve learned that momentum is paramount to getting things across the finish line (too often my GitHub repos become ghost towns because I can’t decide what technology to move forward with or visualize the final user flow).

I’ve got some valuable solo-project management skills that have helped me stay focused to maintain that precious momentum throughout. Take a look, IndieHackers, and tell me what you think in the comments below!

Asking "Why?"

First and foremost, ask yourself “why?” Identify the motivation behind working on this side project. Is it to learn new technologies and frameworks? To make something people want to use? To fill a niche in the market? Or just to troll your friend, Jake? (I’ve definitely never done that last one. Never.)

Your objective shapes your approach to working on side projects. For example, if you want to learn new technologies, then maybe you shouldn’t optimize onshipping a complete product. Conversely, if you want to make something people use, then just choose the stack you’re most productive in.

For me, trolling Jake is my motivation, so I stick to my stack of Koa and heavy, heavy jQuery (kidding, but not really).

Takeaway: Defining your motivation can help you pinpoint where your efforts need to go, in the precious time you have to work with your side project.

Writing it Down!

You probably don’t have to think very hard to imagine this: You’re sitting at your desk, working your day job… and then inspiration strikes you like a lightning bolt. (But in a good way.)

Everyone gets struck by inspiration at various times during the day. Get in the habit of writing down every random potential idea. Sometimes, it’s not even a full idea, but more like an exploration: write down a sentence that’ll inspire you to think of the full idea. Make sure the path from “thinking of the idea” to “memorializing it in an easily accessible way” is as frictionless as possible. Some people like to email themselves or chat Slackbot on Slack. Others like to chat with fellow IndieHackers and mysteriously say “just leaving this here for later, don’t mind me”.

I use nvALT (it’s a free, plain-text Mac app that I can summon with a hotkey and jumps right into a blank note) with a Simple Note backend (also free; they have an iPhone app so I can use it on the go). I have this giant note of just “ideas” (also a separate note of “blog ideas”):

This means that next time you have an empty morning or evening, you can review your ideas. Then, you can start planning the ones you like the most or are particularly inspired by.

Takeaway: Get in the habit of writing down your inspiration. Somewhere, anywhere; simply having a repository for your ideas can help immensely when you’re hunting for your next big product.

Wearing One Hat at a Time

One danger about side projects is wanting to jump into all aspects at once. You start creating wireframes, writing your server routing logic, and thinking about use cases. Stop! The amount of micro context switching and decision making will lead to mental and emotional fatigue, ultimately slowing you down.

Instead, do one thing at a time. This means wearing your Product Manager hat first and answering these questions:

  • what is the objective/end goal?
  • what are the main use cases? (ideally, you should start with only one use case)
  • what tools are available out there for me to use to build this?
  • who are my target users and how do I reach them on the inter webs?
  • what should I name this thing?!*

*For me, choosing a clever and hilarious name often motivates me to finish something in 1/10th the normal time. As such, I like to dwell on the name for a day or two. If I can’t find something great, I just go with a vague project name with the hopes that later I’ll uncover something awesome.

Other Product Management tasks include:

  • thinking about the ideal user flow
  • creating a loose mock up of what it should look like, etc.
  • researching the APIs, documentation, etc. and preparing that info so that when you begin development, the resources are readily available
  • loosely plan when you’ll wear your Engineer and Designer hats

Since I have a full time job, it’s easy to overlook these important steps when I come home in the evening. To keep myself on task, I like to add Google Calendar events with their descriptions as small, self-contained tasks to complete:

By writing it down in a calendar event, I can free up some of my mind to do other stuff, knowing that I can jump right into the tasks listed later when the time arrives.

Takeaway: Before you invariably rush off headlong into a new project, take some time to organize your efforts. Focus on one task at a time (ie. wearing one hat a time”), and make sure you take ample time with each hat.

Bonus Tip: Cutting Scope Aggressively

Since I like to optimize for shipping, it’s important to me to cut scope aggressively. This philosophy usually guides me to first write a library or CLI, from which I can make a web service with a front-end UI (though many things I make end up just being a CLI).

The cognitive overhead of thinking about how the final product should work, especially thinking about the pros and cons of the hundreds of ways an end-user can interact with your finished project, can often destroy momentum and halt productivity on your project. It’s important to think about your project in smaller pieces: how will Engineer-You want to interact with your library? How will App Developer-You want to interact with your API?

This approach means you’re breaking problems into smaller and simpler pieces, which are often more manageable than tackling everything at once.

Takeaway: Small pieces are more manageable than big chunks. Don’t think about the final product all the time; cut your scope to fit your task at hand. Remember, one hat at a time!

Empathizing With Your Users

How your user (whether that is yourself or a specific audience you have in mind) uses your project should determine how it is structured. There is a ton of literature out there that defines the design exercise of coming up with storyboards, etc. so I won’t enumerate them here.

The key thing to remember is that these user flows can guide you in manipulating necessary data so that your users to accomplish their jobs.

Working on a library? What are the minimum arguments necessary, with the fewest calls, for your user to do her job?

How about an API? What job is your developer accomplishing with your API? How does that determine what routes to provide and what parameters to expose?

Building a web or mobile app? How does the UI need to communicate enough so that your user can easily navigate it without confusion or frustration?

In terms of actual design for a web app, I typically have a loose idea of how the final product will look at this stage. But I don’t write any CSS or margin: 0 auto; until the very end. Plus I rely heavily on Twitter’s Bootstrap, since I’m familiar and quick with it.

By this time, I would break apart engineering tasks to discrete TO-DO’s, then write those down (usually in a GitHub issue). This way, when I start developing, I don’t have to revisit these decisions, which could impede my momentum.

Takeaway: Approach your project as if you were the first user (in fact, you might even be the first user). Empathize with their needs and issues, and use this information to help govern your next steps. Write them down so that when you revisit, you aren’t slowed down by going through the whole process again.

Writing First, Refactoring Later

If you’ve ever had to write an essay or blog post, you know that sometimes, it’s not easy. Something I’ve learned about writing that has helped me is to not write and edit at the same time.

The act of writing (creating content) and editing (refining and removing content) uses two parts of your brain. Doing both at the same time can be counter-productive: three hours and two cups of coffee later, you’re still wordsmithing the same sentence.

Same goes with writing code. If you’re goal is to ship, then who cares (right now, at least) that you’re copying code and not being DRY. Put that tenth callback in that single 400-line index.js file, get it to work, then refactor that later when you have your “Editing” hat on. (Remember, one hat at a time!)

If you’re interested in continuing to improve and/or maintain your code, then, for future you’s sake, revisit it later, clean it up, and make it human readable.

Takeaway: In the effort to preserve momentum, don’t worry about editing your code until after you’ve poured it all out of your brain. Editing while writing can significantly slow down your process, and in turn destroy your motivation. Writing Hat and Editing Hat should be separated.

Bonus: Learn About Your Users

If you do plan to put your side project in front of other people, then it helps to add some cursory tracking for analysis later. My go-to is Segment with Google Analytics enabled. (Both are free!)

This allows you to measure traffic and usage on your app, as well as find out where traffic is coming from (if it’s a web app). You can also setup key conversion events to measure your funnel, see where people are dropping off, etc., so you can improve your product.

If you want to be more thorough with your analytics and have the intent to grow your side project, here is a great article on using a $9/month marketing stack. (Yeah, NINE whole dollars.)

Disclaimer: I work for Segment, so it’s my preferred tracker.

Takeaway: When planning to show others this side projects, consider tracking the info for a later analysis. It could come in handy further down the road.

Shipping it!

This is the most difficult part of the side project development lifecycle; when you’ve built it to 90%, it works mostly and looks half-decent. Again, this ultimately depends on your goal: if you just want to make something your friends can use, show it to them for feedback; or if you’re trying to get it listed on Product Hunt, then take the extra week to polish the design, write tests, ensure analytics are in place.

Typically, I have a user in mind when I build something. I would find out where those users like to hang out on the Internet (what tools they normally use, what forums they browse, which subreddits they read, what Slack channels they’re in, what newsletters or blogs they read) and share the finished product there. If I were serious about customer development, I would try to get as much feedback as possible.

The main idea is to consider your motivations and then optimize for them. If you’re optimizing for shipping, then being intentional about planning, researching, designing, and building will help maintain focus and, more importantly, momentum, that can help get the finished product out the door and in front of your users.

Takeaway: Shipping your side project ultimately depends on your goal and your intended users. Locate your target audience online, and find out where they like to kick it (ie. subreddits, social media groups, newsletters, blogs). Share it there, and gather feedback.

Wrapping Up

Hopefully, these tips and tricks will help you keep your side project’s motivation engine chugging along, and free of costly distractions. Preserving motivation is one of the most important aspects of a projects idea-to-ship journey. My greatest hope is that after shipping, you can trade in all of your side-project’s myriad hats for a single, glorious Post-Ship Success Hat.