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.
Top comments (16)
This hits very close to home - having started and abandoned several projects over the years. I usually find myself interested in the problem and once I've worked out that, building the boilerplate staff (register/login, pricing/subscriptions, dashboards and CRUD, terms & privacy pages etc) - with seems to be like 80% of what's involved, and that's before we consider marketing/promotion - drains the motivation quickly.
But I'm an introvert like yourself, so speaking to people and putting myself out there is really difficult, and I find myself repeating the same pattern - but I'm slowly coming to grips and accepting this.
I'd beat myself up for months (I haven't done enough, focused on the wrong thing, should have been working instead of playing the xbox at the weekend, it's not good enough to charge money for yet). And sure, I want some of my side projects to make a little money, but I've realised the build is the part I enjoy, in particular building to scratch my own itch, and nothing kills my projects quicker than putting that on the back burner and spending the majority of my time promoting/marketing them.
I know, it's not an attitude that will have me living off these projects, but it has let me be more comfortable with my "failures" and stop beating myself up as much.
I'm guessing I'm not alone in this, and I wanted to share this as sort of a "don't be so hard on yourself, and enjoy what you're doing" message to those in the same boat.
Maybe join an existing open source project instead? You've got other people "who care" then, and the project would also have 'users' ...
Exactly my thoughts! Joining open-source projects gives both the feeling that you are doing something "useful" for people and the community that cares about the product.
Indeed - "win-win" situation!
It sounds like you are building products even if you don't have the users, but that's clearly not enough otherwise you wouldn't be considering them failures. What does success mean to you? Is the goal full-time entrepreneurship and eventually living off of your side projects?
That's a great question, and honestly one I haven't fully answered for myself yet.
I don't think the goal is full-time entrepreneurship or living off side projects. It's more about the creative need to build things outside of work — and the frustration when those things don't connect with anyone.
Maybe success for me is simpler than I thought: something I build that at least one person finds useful enough to keep using.
I'm almost finished with the project I'm working on now, and (unlike some other projects I've worked on in the past) my motivation is unswerving. Why? Because I am myself the user — it's something I've wanted to have for a long time. I'll publish it and talk to some people about it, maybe make a blog post, but if no one ever uses it but me, the effort will still be justified.
This is actually the healthiest framing I've heard. "I am the user" removes so much pressure. I think I've been building for an imaginary audience instead of solving my own problems first.
This is probably the single approach that doesn't lead to frustration and burnout. One person once told me:
In the end, it's not about the destination, but about the journey that we should embrace and enjoy.
"Do it for yourself" sounds simple but it's surprisingly hard to internalize. Thanks for sharing that — it's a good reminder to check why I'm actually building something before I start.
As the hacker (not attacker) community puts it: "Scratch your own itches."
Thank you for sharing your doubts! I admire how self-reflective and honest you are; that's a really valuable skill 💛
Even though my projects are not programming-related (I am a writer), I see the same patterns in my behaviour:
Need for writing → Excitement → Doubt → Death
I tend to focus too much on what people will think and whether it is even good enough to publish anywhere. This drains all joy and energy for the project, so I kill it. I'm frustrated for some time, and then I start another project – such a vicious circle.
Still not sure what to do about it. I am now learning to enjoy the road instead of thinking about the destination, but it's a really hard mental work to break old patterns.
"Need for writing → Excitement → Doubt → Death" — this is painfully familiar, and honestly it's comforting to know it's not just a developer thing. Breaking old patterns is slow work. Good luck with yours.
So much resonates here! Appreciate you being vulnerable about it.
Thanks for saying that. It felt a bit uncomfortable to write, so I'm glad it landed well.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.