The crippling problem of being able to build whatever you want

I currently have 143 different ideas in a backlog waiting to see the light of day, and it is a constant source of anxiety. Maybe you have a similar list of your own, and like me, tell yourself "if only I had the time to work on them".

I feel that we, as developers, programmers, and software engineers, face a unique problem when it comes to our spare time. We collectively possess the ability to bring our own ideas to life out of thin air, in exchange for nothing but time.

Once we hit a certain point of knowledge and understanding, it can become trivial to put together cool and interesting projects, open source libraries, and full-fledged SaaS apps. If it's so easy though, why do so many of us struggle to get projects out into the world?

In this article, I'm going to take a look at some of the common obstacles and origins of these issues, and wrap up with some solutions that helped me build my ideas faster. Let's get into it.

Limiting factors

Talking with people in other professions, like woodworkers or contractors or mechanics, they also have ideas for fun and interesting projects that they'd like to take on in their spare time. This isn't a unique thing to just software engineers or the tech circle.

These folks that possess the skills and knowledge to make their ideas come to life are usually bottle-necked by something physical: raw materials, specialty tools, or expensive equipment. They'll likely have to dip into their own pockets in order to get started on a project.

There are limiting factors, money mostly, and space, that greatly narrows down their focus of potential projects to work on.

This problem doesn't exist in the software field, or at least nowhere near to the same extent.

When building a website or app, arguably the largest financial barrier is cost of development. But when you are a developer, you possess unlimited quantities of that normally-limiting material.

It's like a woodworker who lives in a forest of pristine walnut trees or a mechanic who owns a used car lot. Being able to build the software you want cuts out the largest expense, so then you're bound by just one restriction: the amount of time you can reasonably spend working on a project.

This sounds great! For developers who enjoy building things on the side, if we are able to make it, we can make it.

But wait a minute... I have all of these ideas to choose from, which one should I start first?

The indecision

If I can build anything, then what should I pick to work on?

Depending on who you are, this could mentally cripple you to the point of exhaustion. Full stop.

I mentioned earlier that I have over 140 different ideas for side projects. Here's a little bit of fun math that I did in my head while writing this article.

If:

• Only 1 in 3 ideas are viable, interesting projects to build, and
• Each one takes approximately 2-3 months to get an MVP out, working in my free time

Then it would take me over 10 years to get through my current backlog of viable ideas. And that's assuming a whole bunch of things like:

• I stop adding my usual 1-2 ideas a week
• I don't get sick, injured, or have a major lifestyle change
• I don't have an increased workload

And that's just counting development to the point of releasing a minimum viable product. This doesn't include maintenance, support issues, devops, maybe some billing, occasional marketing, urgent security patches, and any other ongoing work that will have to be done if I want to support this project after launch.

And why wouldn't I? I took the time and effort to create something from scratch, I'd want to see it through til the end. I also don't want to stagnate and disappoint my users or other developers, and I should take pride in what I've built.

This leads to a new problem, compounding time based on the amount of projects you're maintaining.

Compounding interest

In the world of both open source and paid projects, you're bound to have maintenance requests, bug alerts, and other notices coming at you on a regular basis. If you're the sole developer and maintainer of said project, library, or application, then it's your time that goes into handling these items.

The more projects you release, the more potential time you lose with recurring support and maintenance. This can easily compound to a point where you're unable to dedicate time to building new projects, and will have to make the decision between dropping your support of an existing project, or not taking up a new one.

I feel like with each project I take on, I sit and watch as a scale weighs through the pros and cons.

• Will I come out of this experience in a positive light when the project is over, or will I be burnt out?
• What if this takes off and I feel obligated to maintain it for years to come?
• If I slow down or stop fixing these issues, will my community react negatively?

These might seem paranoid or excessive to think about for every project that I start, but honestly, I've seen each of the above points come true for multiple different projects throughout my years as an avid open source contributor.

I've talked enough about the negatives, how about some actions that we can take to actually address the problem. How can we, as intrepid developers, actually complete projects and get finished ideas out into the world?

Potential solutions

There's a few techniques I've found over the years that have helped me more consistently move projects into the finished basket on a more frequent basis. Let's check them out.

Organize your ideas.

This is arguably the most important thing, period. If you're someone like me, new ideas spring up at you all the time. Inspiration for new projects come in the forms of a friend complaining about an existing app, a Tweet asking for a service that doesn't exist, or even passing shower thoughts.

It's best to get these out of your head, and down onto a stationary media. For me, that's a Kanban board.

I have four columns for my ideas: Backlog, Promising, Working On, Monitoring, and Archived. If I think of an idea, I create a new card in the Backlog and dump as much info as I can into it. Framework to use, pain points that I could encounter, potential domain names, you get the picture.

Then, I do nothing.

I don't immediately drop everything to pick up this new shiny project. Instead, I let it marinate outside my mind. If I keep coming back to it days or weeks later, I move it into the Promising column. The next step could be weeks, months, or sometimes years away.

Don't spread yourself thin.

I always have a voice in the back of my head saying "you can squeeze in an extra project, don't worry!". It's a liar. If I decided to take on a new project while trying to balance everything else, something will suffer. There's only so much quality time and work that I can deliver in a day.

So, I don't pick up anything else until I have the bandwidth to sit down and focus on it. This usually means making the conscious, mindful decision to hold off on any new ideas until something I'm already working on makes it out of the Working On column.

This is where the root of a lot of my frustrations used to lie. I believed that if I wanted to focus on something else and not stretch myself thin, then I needed to be completely finished with what I was already working on, 100% done.

But that led to eventual disdain for the projects I was once excited for, so I decided to try something a little different.

Release fast and get feedback.

Instead of waiting for a project to be fully complete when I'm working on it, I now tend to release as early as I can. By getting the bulk of the development work in a "good enough" spot as fast as possible, I maximize my available time that I have to work on projects and can start getting feedback as soon as possible.

This usually means throwing the project up on GitHub or a purchased domain, writing some halfway-solid documentation, and sharing it out to Twitter, Reddit, and if I'm feeling particularly brave, Hacker News.

This might make a lot of people nervous, and it's understandable. The internet, and especially the tech side of it, can be a pretty uncaring place. But, it can also be pretty great.

At this point, one of two things usually happens for my projects:

1. I start getting some solid feedback. People are interested in the project or checking it out on their own, and I'm seeing comments, opened issues, and messages.

2. No one cares and no one really pays attention. This sucks, honestly, and is a pretty terrible feeling. But... it hurts a lot less when you don't sink countless hours into a project perfecting it, only to get a similar response.

If I find out early that I didn't hit a mark with it, I can move on from this project and start something new! If I start getting some feedback though, the project moves onto the Monitoring phase.

Iterate and set expectations.

Alright, I've got people interested in what I've built, and now I have some actionable feedback coming through, now what?

For me, at this point the project enters the Monitoring phase. The core functionality is there and valid, and now it's up to me to work on features, fix bugs, or approve pull requests. Keep in mind though, depending on just how popular your project gets, this could spiral out of hand. So it's best to set expectations.

Let your community and users know how often they can expect new releases, or how often issues are looked at. You don't have to be a superhero when it comes to response time, and it's an easy way to get burnt out. For me, my goal isn't to make maintaining a project a full-time job in itself, so for a lot of my work I've balanced reponsiveness for new features and issues over working on new projects.

My users don't seem to mind much and are happy when new releases come through, but you'll have to gauge that for yourself.

You don't have to use the above like a roadmap and implement everything I've talked about for your own projects and workflow. Every person's different and what works for me might not work for you. Feel free to pick and choose any of these ideas that sound like they might help you out in your current situation, or scrap them altogether and make something new!

Wrap up

I've started and stopped this article multiple times because I just really didn't know exactly what I wanted to say, it never felt like I was getting my thoughts across well enough. So really, this is just a rant about my particular circumstances and how I've felt creating and maintaining paid and open source projects throughout years of my life.

Just know that if you're experiencing something similar, a conflict between the time you have to dedicate and the desire to build, that you're not alone.