Why Do I Keep Killing My Side Projects?

--- title: Why Do I Keep Killing My Side Projects? published: true description: Two projects, two deaths. At some point, you need to stop blaming circumstances and start asking harder questions. tags: sideprojects, career, productivity, programming tags: sideproject, career, productivity cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mjz456n9hmitex1za1vp.jpeg canonical_url: https://enderahmetyurt.com/why-do-i-keep-killing-my-side-projects/ --- I recently shut down Bloudme. It was my second personal project, which started as an RSS reader and quietly died. Before that, there was Podiscover — a social media platform for podcasts. Two projects, two deaths. At some point, you need to stop blaming circumstances and start asking harder questions. This isn't a piece that starts with "what I learned from failure" and ends optimistically. This is an attempt to understand a pattern. ## Two Projects **Podiscover** was born out of a real void. At the time, there wasn't a dedicated social platform for podcast discovery. The timing was technically perfect too. Rails and Hotwire were new, and I wanted to both learn and create something. It started well but building a social platform alone is a brutal undertaking. I couldn't find anyone to help me with the UI side. I didn't fully understand the market I was trying to target. I was alone and eventually got bored. **Bloudme** was different in scope but similar in spirit. A deliberately old-school RSS reader: share RSS links, the system pulls them every three hours, and you read them whenever you want. Simple. But simplicity wasn't enough for me. I constantly wanted to add more. Meanwhile, nobody was using it. It was burning through the money. My motivation evaporated. ## The Pattern When I put the two side-by-side, the same sequence emerges: **Genuine need → Technical excitement → Solitude → Doubt → Death.** Both projects started with something I genuinely wanted to see exist in the world. Both offered an excuse to explore new technical fields. And both died not because the idea was bad, but because the distance between "I did it" and "someone cared" was too wide and too quiet. There are a few specific modes of failure worth naming. **I confuse technical curiosity with product belief.** Learning Hotwire was a legitimate reason to start Podiscover. But learning a framework isn't the same as being tied to a market. Once the novelty of the technology wore off, I didn't have a deeper reason to continue. **I do it alone, and solitude kills motivation faster than any technical problem.** I'm an introvert. Solo development comes naturally to me. But there's a difference between working alone by choice and having no one to share your progress with. No co-founder, no early user giving feedback, no one saying "it's great, keep going." Silence becomes a decision. **I skip the validation and go straight to building.** In both cases, I started coding without a single person promising to use what I was making. The market signal was zero, but the terminal was open, so I wrote. This is the classic developer trap: coding is comfortable, talking to people isn't. **I let even small costs fuel suspicion.** Running Bloudme wasn't expensive. But when you combine "nobody's using it" with "and it's costing me money," the rational conclusion writes itself. Cost isn't really the issue. It's a symbol. ## Things I'm Not Sure About I don't know if this pattern is a lack of perseverance or an ability to spot dead ends early. Maybe killing Podiscover and Bloudme was the right decision both times. Maybe the real mistake wasn't abandoning them — it was starting without the conditions for success. I also don't know if I really want to build a product or if I want the identity of someone who builds products. Those are two very different things. > The first requires talking to users, iterating over tedious things, and tolerating long plateaus. The second only requires a GitHub repository and a launch tweet. ## What Would I Do Differently? I'm not swearing off side projects. But next time, I want to change the inputs, not just expect different outputs. **Start with a person, not a repository.** Before writing a single line of code, find someone who will actually use that thing and give honest feedback. **Separate learning from building.** If the goal is to learn Hotwire or try a new Rails feature, do an experimental project. If the goal is to make something people use, choose the boring technology you already know. **Set a cancellation criterion beforehand.** Instead of slowly losing motivation over months, decide from the start: "If I don't have 10 active users by week 8, I'm stopping." Make quitting a decision, not drifting. **Find someone.** It doesn't have to be a co-founder. Just someone who cares enough to check in. A weekly "how's it going?" from someone who understands what you're doing changes everything. ## Sad but True Two consecutive dead projects is a data point. If it happens a third time with the same pattern — solo development, no users, death of motivation — it's not bad luck. It's a system that produces a predictable outcome. The projects didn't fail because I wasn't technically proficient. They failed because I optimized the part I enjoyed (building) and skipped the important part (connecting with users). It's not a project problem. It's a me problem. And knowing this is either the first step toward fixing it, or another form of complacent self-awareness that changes nothing. --- *I write about Ruby, Rails, and software development every Thursday. You can follow me at [enderahmetyurt.com](https://enderahmetyurt.com).*