Now, almost 20 years later, I find I want to preserve something from the old days before it all looked like, well, gestures around wildly. It would be a relief not to maintain the site anymore. But I feel like I'd be disappointing a lot of people, as well. I have no idea how long I'm going to keep this going.
Thank you! :-)
(PS. maybe just freeze it so it's up but don't spend / spend minimal time on maintenance, if that's possible?)
(PPS. maybe integrate with some of those "send a postcard" sites so that people can also send actual physical cards using your designs? or buy them (high-res PDF for printing)
Here’s my own “graveyard” of projects just from the last few months: https://mesmer.tools/ that immediately got the highest domain ranking I have of all my sites(38), even ones making money
The critical thing is what the author says:
> always make sure that you're doing them for yourself, and for the right reasons
For me my side projects are generally something to have fun with and something to learn new things with. When you're finding it a slog or you feel like you've learnt what what you need to it's fine to just dump it.
Actually finishing something is of course nice and for beginners in particular there's a lot of value in going from that it's mostly there just some loose ends to tie off stage to the actually done stage but you don't have to always do this (or indeed just do it in some select cases).
Too many "tales of side-projects that grew into successful businesses" can narrow your understanding of what it actually means. I agree that it's OK to abandon a side project, but it is a much deeper reflection.
A gaussian splat converter that I made and abanonded became incredibly useful a few months later when I needed to do a visualisation for a really specific environment
I did find it to be a funny twist that, in the act of building the app, he taught himself the thing that the app was supposed to teach him when it was done.
You never know when your abandoned side project is somebody else's treasure. I guess open source + let somebody vibe code to completion is the right way.
If you are doing this for your own entertainment and learning, take it as far as pleases you. I have plenty of half finished things. I like picking one and doing some 'gardening' when I feel like it. Sometimes when I have low energy and I need to snap out of that, I just start doing simple stuff. Maybe I'll update dependencies on a project I haven't touched for ages. Or there's a bit of documentation that annoys me and I fix it. I'll see what needs doing, can use improving, etc.
There's a system to my madness where sometimes I find a use for disconnected bits of software in a business context. And sometimes that never happens and that's fine too. I abandon things as well. Mostly if I don't enjoy working on something, it just gets less and less of my attention. I have well over a hundred github projects at this point. Only a few of them have any traction at all. But once in a while I'll get a random issue report or PR on one that I haven't touched in years and that's all it takes for me to pick up where I left off.
It was a project that started innocently enough, but its domain is unbelievably complex. Recovering MIPS relocation spots from a Ghidra database sounds like an easy enough task, until you're confronted with behemoth functions that span thousands of instructions and undocumented psABI extensions that produces edge cases from Hell.
But then, someone contributed a PoC COFF exporter to go along with the PoC x86 ISA analyzer and after that the Windows video game decompilation picked it up, spreading by word of mouth. I've spent a ridiculously long time fixing bugs and learning about MSVC on-the-fly (quipping "there are lies, damned lies and the Microsoft Portable Executable and Common Object File Format Specification." on the decomp.me Discord server at one point). Then other architectures started creeping up in PRs, first x86_64 and later PowerPC. It's a bottomless pit of toolchains and platforms minutiae that demand perfection to pull off and would drive anyone stark raving mad.
It was bad enough that I let it sit for months at a time, only for someone to message me and fall back into it, then discover it got even more popular while I was away. I also somehow got invited to present a poster about it at ACM CCS 2025 in Taiwan, an absolutely insane story (how many hobbyists are invited to present something at a world-class academic conference on cyber-security?) that while very enlightening also physically wiped me out.
Copilot saved this project and I really mean it. Preparing artifacts, writing tests, performing investigations and large-scale refactorings: hours of grueling, soul-crushing menial work that I no longer have to subject myself to. Features that looked impossible like generating debugging symbols became within reach. The ironclad regression test suite happened to provide the perfect feedback loop. I still review the code and design, but I no longer burn myself out on this madness.
Now I usually just add a static landing page, some screenshots how it looked like and turn of the backend (Example: https://getbirdfeeder.com) which makes me feel better about it.
What also needs to be shipped quickly and numerously? Oh, I remember, unsolicited commercial email...
It's OK to abandon your side-project - https://news.ycombinator.com/item?id=39500386 - Feb 2024 (79 comments)
I did simplify the ecard send/receive mechanism - there's been four or five different iterations of the app, and validating emails was nightmarish. As of a few months ago I just let people create and copy-paste 'links with messages', which has made my life considerably easier.
I did print 1000 boxes of postcards years ago - in about 2012, I think. they turned out looking really beautiful, in print. It's a funny story, actually, because I put them on Amazon and forgot all about them, entirely (I was working a full-time job at the time at a university). I still have a few hundred boxes left I've been giving away to people.
I've had a few people contact me in the interest of facilitating that service, but they seemed kinda slimey. I think you're right; I should probably set up print-on-demand. But again, side projects, huh?!
Now when I put something aside I know there's a chance I might pick it up again in ten years. There wasn't much evidence of that when I was twenty-five.
It's been one of the best things for me about middle age.
You don't want to open source it? Don't. You want to open source it but not build a community? Don't build a community. You don't even have to answer to requests.
You don't even have to disable the PR on your forge.
You don't even have to explain clearly in the README how you envision it and show any kind of commitment.
You do you, open sourcing is already nice.
It's sad, when projects are abandoned and a whole bunch of users would be willing to (partially) maintain it, but the key holder implicitly or explicitly decided that nobody else should have access.
Forks are not he same: It's very hard to get enough traction with existing users and the discoverability is terrible.
I especially appreciate the honesty about the upcoming pricing. Do you plan/want to make it a business?
Does it use Sqlite or something on the backend, or is it all it's own? Do you know if it runs on Linux?
Edit: My answers based on a quick review (please correct if I'm wrong). It uses Postgres (cool!) and definitely runs on Linux (I see Dockerfile in there). UI is through the browser?
A fork solves that. And potential maintainers willing to work together on a fork can open an issue and talk about it. The reality being that more often than not, people think that they are willing to keep maintaining it, but in practice they just won't.
These factors can always be reversed. And (whisper it) a bit of vibe-coding can also help unstick a project that ground to a halt because the next step was dull implementation rather than exciting creation.
I'll tell you. I forget stuff.
So when I pick up that Openweather tool after three years of not touching it to quickly change the output a bit, I can be pretty sure the overly robust scaffolding around the project won't let me break anything.
Pro tip for enjoying your life at work: this also applies to you work projects. Once you realize this, you can have a lot more fun at work and even coerce work projects to be more like your for-fun/side projects. Of course this is detrimental to the company as a whole, but your company almost definitely does not care about you and you might as well extract as much enjoyment as possible.
If your coworkers are actually passionate about programming (i.e. not drones or PM brains running flowchart to increase quarterly profit), you can even make work more enjoyable for them.
Things like unconventional language choices, over-engineering of systems, unusual coding styles, obscure protocol/library use, and of course a ton of NIH can really spice up a mundane codebase.
Even stretching an "easy" module into a masterfully crafted program and going 4x over estimation can be fun sometimes (without any of the bad design choices suggested above).
Yes I stand by this bad advice, and it's allowed me to play with so much technology I would never otherwise touch at day job.
Really yearning for crafted code that meets every one of your perfect coding style guide and preference with green checks across a huge set of static analysis tools and a large test suite, go for it!
Tired of conforming to your ultra strict style guide at work and code reviews that go in endless circles nit picking about use of spacing or whatever? Let loose and stop having to care/worry so much about the details.
For years I wrote a technical blog intended just for my own reference, as the small effort required to write it up, create images and so on felt good. It was also a good point to think about what I had _actually_ done - sometimes this made me realise small mistakes or missing details.
I would urge anyone who wants to "play with so much technology" to do so on your own side projects and proof of concepts rather then in enterprise engineering that you're paid for.
(and yes I accept most POCs end up being fast tracked to production anyway)
Another way to avoid that feeling is changing your mindset around what's "abandoned" vs "completed". "Completed" doesn't have to mean "published project and made it FOSS" or whatever, it could literally be "Scratched an itch to play around with library X's APIs" or something, or just "Wanted to see if it was possible".
Nowdays I "complete" every single of my side-projects, some of them in some hours, because "completed" no longer has to mean "it's public and people can use it", mentally this feels a lot better :)
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.
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. If the order is wrong, or you miss a preposition, the sentence might no longer makes sense. For example, "Tom gives the book to Anna" sounds natural whereas, "Tom the book to Anna gives" doesn't. 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. To return to the same example sentences in Latvian, "Toms dod grāmatu Annai" (emphasis added to highlight the functional endings). Literally translated back to English, this sentence would be something like "Tom-subject gives book-object Anna-towards".
Linguistically, cases are a pretty cool system because you no longer need to care about word order. As a learner though, this is a problem because you do need to care about all of the various endings for each word you learn. Latvian has seven cases in total, two grammatical genders (each with three separate conjugation patterns), 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 🚀
I wanted to keep my app simple. Whilst I had a lot of other grammar to learn, I was only focusing on noun conjugations and that would help me whittle the initial concept down to an MVP. 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 to keep track of how I'd performed in past quizzes.
The tech stack would be simple too. At the time of planning, Svelte 3.0 was the new shiny so I decided to use it for my UI. I knew that I wanted to host everything on Netlify, so for the backend I'd write a couple serverless functions to present the questions and check the answers. The main list of nouns could be served from a static JSON file and, as I'd be the only user, I could safely persist previous quiz results and a high-score to local storage. I wouldn't need a database right now.
As for how I would actually check answers, that would take a bit of research. After extensively reading about the conjugation patterns and how the various types of nouns are classified, I decided that my simplest option would be to build a system that leaned heavily on Regex to strip noun stems and append the appropriate suffixes.

With a decent plan in place, I started to code.
After a full week of evenings working on the project, I put the finishing touches to the MVP. I deployed everything to Netlify and started my initial testing.

The UI was simple but passable and worked well on mobile devices. Quiz questions progressed smoothly and the session would end after three wrong answers, as designed. In between quizzes, the dashboard was correctly displaying stats for hits and misses on each word and the overall high-score was persisting between sessions. 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 that I hadn't anticipated. 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.
I racked my brain for possible ways to make the quiz more fun but, 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.
Over the last week 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.
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.
This is not all to say that we should dismiss the reasons these projects get abandoned – introspection is still important – but I find that focusing on the progress made can feel more constructive in the long-term. After abandoning my Latvian project, I dipped back into some of the other stalled side-projects languishing on my laptop. Where I'd previously grumbled over a string of failures and wasted time, I could now refocus on what had gone well. On one project, I could see where I'd first learned how to make an API in Go. Elsewhere I was impressed at how I had figured out how to work with GIS map data in Postgres. In another derelict directory, I saw not much more than a broken animation - one that I would later revisit and evolve into this website.
I still regularly work on side-projects but my perspective and motivations are different now. My advice to a beginner dev struggling with their side-projects would be to always make sure that you're doing them for yourself, and for the right reasons. Instead of approaching your first project purely as a means to make it big or to impress recruiters, see it firstly as a means to learn and explore what's possible. Once you've built up enough experience (i.e. abandoned a few projects) the rest usually follows. Side-projects should be creative and fun. If you find that shipping your project is starting to cause you stress or, worse yet, leaving you feeling burned out, then don't hesitate to cut it loose. Chances are that, if you look close enough, it has already brought you plenty of value.