I have a private GitHub graveyard. Repos that started with excitement, got a weekend or two of intense coding, then slowly faded into abandoned obscurity. Last week I went through them all. Here are six projects I started and never finished, and what each failure taught me.
1. A Habit Tracker App
This was going to be "the habit tracker that actually works." I had wireframes, a color palette, a domain name. I spent two weeks building a beautiful React frontend with smooth animations and a satisfying checkbox interaction. Then I realized I needed a backend, authentication, data persistence, push notifications, and recurring task logic. The fun UI work was maybe 20% of the actual project.
I never built the backend. The repo has a gorgeous frontend that talks to a mock API that returns hardcoded data.
Lesson: I was building the part I enjoyed, not the part the project needed. If your side project needs a backend, build the backend first. The UI is the reward, not the starting point.
2. A CLI Tool for Managing Dotfiles
I wanted to build a tool that would sync, version, and deploy dotfiles across machines. Wrote it in Go because I was learning Go at the time. Got the basic file copying working, then tried to handle edge cases. Symlinks. Platform differences. Files that need different content on different machines. Merge conflicts when you edit a dotfile on two machines.
The scope kept expanding. Every edge case revealed two more edge cases. After three weekends I had a half-working tool that was worse than just using a Git repo with a shell script. Which is what I switched to.
Lesson: Before building a tool, check if a simpler solution already exists. A 20-line bash script beat my 2000-line Go program.
3. A Markdown Blog Engine
The irony of this one is painful. I built a static site generator for my blog instead of actually writing blog posts. Spent weeks on the Markdown parser, syntax highlighting, RSS feed generation, and a custom template engine. It worked pretty well, actually. But by the time it was "ready," I'd burned all my creative energy on the engine and had nothing left for writing.
I eventually moved to a simpler setup and started actually publishing. The blog engine repo sits untouched.
Lesson: Building the tool is not the same as doing the work. Sometimes the boring, existing tool is the right choice because it lets you focus on what actually matters.
4. A Real-Time Multiplayer Game
WebSocket-based multiplayer word game. The technical challenge excited me. I got the real-time communication working beautifully. Two browsers could connect and see each other's actions in real time with minimal latency. The networking code was solid.
Then I had to design the actual game. Turns out I'm a developer, not a game designer. The gameplay was boring. I tried adding features to make it more fun but I was just throwing mechanics at the wall. Without a clear game design vision from the start, no amount of good networking code could save it.
Lesson: Technical feasibility is not the same as product viability. "Can I build it?" is a different question from "Should I build it?" and "Will anyone care?"
5. A Personal Finance Dashboard
I wanted a single dashboard showing all my financial accounts. Started building it, then discovered that connecting to bank APIs is a regulatory nightmare. Plaid exists but costs money for production use. Screen scraping bank websites is fragile and possibly against their terms of service.
I pivoted to a manual-entry approach, but at that point I was just building a worse version of a spreadsheet. Abandoned it and went back to Google Sheets.
Lesson: Validate the hard part first. If your project depends on external APIs or data access, make sure that access is actually feasible before building everything else around it.
6. An NFT Marketplace for Developers
This was my most recent abandoned project. A marketplace specifically for developer-created generative art NFTs. I built the smart contracts, a basic frontend, and IPFS integration. Technically it worked. But by the time I had something deployable, the NFT market was cooling down and I'd lost conviction in the idea.
I still think the code was good. The market timing just wasn't there, and honestly, I'm not sure the world needed another NFT marketplace.
Lesson: Timing matters for market-dependent projects. If you're building something that depends on a trend, ship fast or don't ship at all.
The Common Thread
Looking at all six, the pattern is clear. I'm drawn to technically interesting problems and I lose interest when the work shifts from "interesting engineering challenge" to "tedious but necessary product work." The backend for the habit tracker. The game design for the multiplayer game. The content for the blog engine.
I don't think abandoned side projects are failures, exactly. Each one taught me something. But I'm trying to be more honest with myself now about whether I want to build a product or just explore a technology. Both are valid reasons to code on the weekend. But confusing one for the other is how you end up with a graveyard.