Build Maintainable Side Projects

3 minute read

I’ve been building businesses online since I was 16 years old, and during that entire time, I had a terrible history of keeping my projects online and working properly. Whenever I had a new and exciting idea for my previous projects – and more importantly their users – it was forgotten and left behind. From GrowlerFill to Ferries App, I’ve left many unhappy users in my wake.

For a long time, I felt really guilty about this. For the last three years, I chose not to build any side projects and just focused on building the SpringboardVR product to be the best it can be. But recently, SpringboardVR has grown and matured, and with that, my role as CTO has evolved as well. I’m no longer a hybrid Backend Developer, Lead Developer, and CTO. Instead, the CTO role is consuming more and more of my time. As a result, I am losing my connection to programming and running out of excuses for trying out new technologies. All of this is culminating in the desire to start looking at building some small side projects again – and causing me to take a hard look at what caused my previous failures.

A few years ago when the USB-C specification was becoming popular, I purchased my first USB-C phone and laptop. It sparked an idea for a new side project. My friend Jamie and I decided to build a database of USB-C devices to help people figure out how devices and cables work together. We were pretty far down the path of building it – we had a basic API in place, a beautiful frontend, and then it was time to start inputting our data. We went through the usual options for trying to source data… Is there an existing API or dataset we can leverage? Can we scrape it from somewhere? Can we cheaply source it from real humans using something like Mechanical Turk?

After our research, we realized that the knowledge we needed for this project was too technical, disparate, and new to be automated in any meaningful way. We would have to go through hundreds of Amazon product listings, hardware listings for phones, tablets, and laptops, and manually combine all this information into our own database. And worse, we would have to continue doing this for the foreseeable future to keep things up-to-date. This was the death of the project for me and what sparked this realization – you must account for maintainability when coming up with side projects.

Along with my usual metrics for building a side project – Will I use it personally? Is there a way to monetize it? – I’m adding a new one… How maintainable is it?

Maintainable doesn’t just mean automating your source of data. It means how many hours per month you’re willing to put into keeping your product online, working, and making your users happy.

If it’s an iOS or Android application, you have to update it with every new software release because they change the requirements and limitations for applications. This may seem like a non-issue when you’re starting out, but just wait until you’re trying to remember how your build system works for a 4-year-old project that you never touch.

If it’s a database-driven app like my USB-C database, how many hours per month will it take to keep the dataset fresh and functional? Can you hire someone part-time to handle it, or do you have to take care of it all yourself?

For any side project you build, it will require a certain number of hours per month to answer support emails, help customers get set up, and keep the infrastructure running smoothly. Even if you use a Platform as a Service for your infrastructure, build a beautiful onboarding system, and offer a detailed knowledge base, there will still be something you’re going to have to assist with now and then.

Two new businesses I am advising on currently – ChatFox and CRO Notes – are perfect examples of products that have a very low maintenance burden. Both these have founders who have primary jobs that keep them busy, so they need products that can run themselves for the most part. Thus far, each has been incredibly easy-to-maintain – but they’re both just one external API change away from requiring a whole lot of maintenance work.

Updated:

Comments