A solo developer spent a month building an open-source IDE. They called it Dez. Built on top of Zed. Clean repo, version 0.4, ready for feedback. They posted it on Hacker News with a simple ask: “I am asking for guidance so I can move forward with a direction.”
Read that again. A month of work. And they still don’t have a direction.
This isn’t a criticism. It’s a pattern. And if you’ve ever built something from scratch, you’ve lived it.
You know the feeling. You get an idea at 2 AM. You start coding. The architecture feels right. The commits are flowing. You’re in the zone. And then you surface for air, show it to the world, and realize you never answered the one question that matters:
Why does this need to exist?
The top comment on that HN thread was brutal in its simplicity:
“What is the #1 problem it is meant to address that other IDEs don’t?”
Not “nice project.” Not “here’s a bug.” Just that. A question the developer couldn’t answer because, by their own admission, the intended user was “me for now.”
The graveyard of open source is full of projects with beautiful code and zero users.
We’ve all been there. You build something because you can. Because it’s fun. Because the act of creation is intoxicating. And that’s not wrong — passion is the fuel that gets projects off the ground. But passion without a problem is just a hobby wearing a startup costume.
Here’s what happens to projects like Dez. The developer keeps coding. Maybe a few people star the repo. One person files a bug. The developer fixes it. Weeks pass. The repo goes quiet. The developer moves on to the next idea. And Dez becomes another entry in the long list of “things I built that nobody used.”
Not because the code was bad. Because the “why” was never defined.
Think about every tool you use daily. VS Code. Figma. Notion. Each one started with a problem so sharp you could cut yourself on it. VS Code existed because Microsoft realized developers needed a fast, extensible, cross-platform editor that didn’t suck. That’s not a feature list. That’s a battle cry.
Dez doesn’t have that yet. And that’s the real risk — not technical debt, not missing features, not performance issues.
The biggest threat to your project isn’t bad code. It’s a missing answer to “why should anyone care?”
The developer who posted Dez did something most of us are too afraid to do: they admitted they didn’t know. They put their work out there and said, in effect, “I built this thing and I need help figuring out what it’s for.”
That vulnerability is rare. And it’s the exact moment where the project could go either way.
If they get the right feedback — if someone helps them find that sharp problem — Dez could become something real. A niche tool that solves a problem nobody else is solving. Maybe it’s the IDE for a specific framework. Maybe it’s the IDE for people who hate every other IDE. Maybe it’s something none of us have thought of yet.
But if they don’t find that answer? If they keep coding without clarity? They’ll ship version 1.0, post it on Show HN, get 50 upvotes, a few polite comments, and then watch it slowly fade.
I’ve seen this story play out hundreds of times. On HN. On GitHub. In my own career. The pattern is always the same:
Developer builds something cool. Developer asks for feedback. Community asks “what problem does this solve?” Developer doesn’t have a clear answer. Project dies.
The exception? When that fourth step becomes a turning point instead of a headstone.
Before you write another line of code, write one sentence that explains why anyone should care. If you can’t, stop coding and start thinking.
This isn’t just about Dez. It’s about every project sitting in your GitHub repos right now. The ones with great READMEs and no users. The ones with clean architecture and no stars. The ones you built because you could, not because anyone needed you to.
The best thing the Dez developer did wasn’t building an IDE in a month. It was having the courage to ask for help before it was too late.
Most developers wait until version 2.0 to realize they’re building the wrong thing. This developer asked at version 0.4. That’s not weakness. That’s the smartest move in the game.
So here’s the question for every builder reading this: What is the #1 problem your project solves that nothing else does?
If you can answer that in one sentence, you have a project. If you can’t, you have a hobby.
And there’s nothing wrong with hobbies. Just don’t confuse them with products.
FAQ
Q: Isn't it too early to demand a clear problem statement at version 0.4?
A: No. Version 0.4 means you've already committed a month of work. If you don't know what problem you're solving by now, another month of coding won't magically reveal it. The problem statement should come before the first commit, not after the first release.
Q: What should the Dez developer actually do next?
A: Stop coding features. Go talk to 10 developers about their IDE frustrations. Find the one pain point that VS Code, Zed, and JetBrains all ignore. Then rebuild Dez around that single problem. One sharp problem beats ten vague features.
Q: Can't passion projects become successful products organically?
A: Almost never. The rare exceptions — Linux, Redis, SQLite — succeeded because their creators had a crystal-clear problem they were solving for themselves that turned out to be universal. Passion without clarity is a hobby. Passion with clarity is a product.