It's OK to abandon your side-project (2024)

The web industry is full to the brim with tales of side-projects that grew into successful businesses and, like many of us, I'll often find myself tinkering away on an idea or three after I've finished with my day-job. Whilst it's definitely an enticing prospect, working on a side-project is not always sunshine and Lambos though – sometimes they just don't work out. If you're reading this, there's a chance that you might have recently abandoned (or are considering abandoning) a side-project. Many of us have been there. Hell, the neglected side-project has become something of a developer-meme at this point.

That said, I often get emails from beginner developers looking for advice and one of the growing themes I've noticed recently is concern that they they aren't shipping their side-projects as quickly or numerously as they would like. That anxiousness is totally understandable. When the prevailing wisdom of developer hustle-culture is "always be shipping" and tech-interviewers will routinely measure candidates by the output of their extra-curricular coding, those abandoned side-projects might not feel so funny anymore. That doesn't sit right with me. We hear about all the side-project success stories, but what if we talked more openly about the ones that tanked? Many of us do retrospectives at work, but personal projects don't get the same treatment. Instead, why don't we shine a light on all the time we spent on projects that didn't go anywhere? The seemed-like-a-good-idea-at-the-time abandonware; the graveyard of node_modules folders still haunting our development environments.

I'd like to talk about a side-project I worked on a while ago; one that I abandoned the same day it was deployed.

The background.

My partner is Latvian and, a few years back, I set out to learn her language. Being from a small country, detailed learning resources for the Latvian language are a bit sparse but I made decent progress regardless. That was, until I discovered that Latvian has grammatical cases. If you've never encountered a "case" before, here's a little primer:

A language like English uses word order and prepositions such as "for", "to" or "in" to add meaning to each word in a sentence. Cases change this up a bit. Instead of relying on word order and helper words, the end of each word itself changes to show what it is doing within the sentence. Latvian has seven cases in total, two grammatical genders, and nouns can be singular and plural. The TL;DR is that's something like 84 possible endings to memorize.

So, cases can be a lot for a first-language English speaker. Thankfully though, I'm also a developer and therefore I'm hardwired to think that I can solve everything with code. What if I could build a quiz app to help me learn noun endings? This smelled like a side-project 🚀

The approach.

I wanted to keep my app simple. The quiz mechanism would present a series of Latvian nouns and the user would be required to conjugate the noun to the appropriate ending. To keep things interesting, the quiz would allow the user to make three mistakes before ending and I'd throw in a simple high-score system.

The tech stack would be simple too. I used Svelte 3.0 for my UI and hosted everything on Netlify, using serverless functions to present the questions and check the answers. As for how I would actually check answers, I decided to build a system that leaned heavily on Regex to strip noun stems and append the appropriate suffixes.

The realisation.

After a full week of evenings working on the project, I deployed everything to Netlify. The UI was simple but passable. Happy that everything was working as planned, I cracked a beer and started training word endings.

It quickly became clear that my app had a really big problem: The quiz was far too easy. Worse still, if I didn't make 3 mistakes, the quiz would keep going indefinitely. It just wasn't fun to use. Eventually, the penny dropped: The issue couldn't actually be solved in code. It turns out that, in devising and coding all of the logic needed to test the various noun endings, I had passively learned the rules needed to form them.

I had worked long evenings to research and build an app – with a target audience of one person – and I didn't really need to use it anymore. Oops.

Maybe the real treasure is the code we wrote along the way.

Out of all of my abandoned side-projects, this was the one that made me think differently. Even if I would never actually use the end 'deliverable', working on the project still indirectly achieved what I'd set out to do. That led me to an important realisation: we talk a lot about abandoned side-projects as "failed", but their success is really a matter of perspective.

Despite what some tech recruiters might have you believe, the success of a side-project doesn't need to be defined by a beautiful, shipped product. We work in a practical medium and any build experience, good, bad or abandoned, is still valid experience. If you are able to remove the pressure to ship and instead approach them like throwaway prototypes, side-projects become a great scratch pad for experimentation. As I found when building my Latvian app, even the act of writing code itself can be a successful tool for solving problems.