The “Build More” Phase

I used to believe that the only way to grow as a developer was to keep building—constantly. The more projects I had, the better I’d become. At least, that’s what I told myself.

So I went all in.

Over the course of a year, I built 12 side projects. Some were small tools, others were more polished ideas. I experimented with different stacks, design styles, and problem spaces. Every time I shipped something, it felt like progress.

But looking back, most of those projects didn’t really go anywhere.

They didn’t get meaningful traction. People didn’t stick around. And more importantly, I didn’t stick around either. As soon as something was “done,” I moved on to the next idea. At the time, I thought I was being consistent. In reality, I was just being restless.

The Shift

The turning point came with my twelfth project.

It wasn’t the most complex thing I had built, but I approached it differently. Instead of rushing to launch, I spent more time understanding what I was building and why. I refined the idea, removed unnecessary features, and focused on making the core experience genuinely useful.

For the first time, I wasn’t thinking about how fast I could ship. I was thinking about whether this was something worth spending more time on.

That small shift changed everything.

The project didn’t go viral or blow up overnight, but it started gaining real traction over time. People used it, came back to it, and shared it with others. It wasn’t because the idea was revolutionary—it was because it actually worked well for the people it was built for.

What Actually Matters

That’s when it clicked for me.

The first 11 projects weren’t failures—they were practice. They helped me improve my skills and build confidence. But they also showed me a pattern: I was optimizing for output, not impact.

Building a lot helps in the beginning, but after a point, it becomes a way to avoid going deeper. Constantly starting something new is exciting, but it also means you never stay long enough to truly refine anything.

What made the difference wasn’t building more—it was staying longer.

Spending time improving the details, understanding the users, and making something that people would actually find useful.

If there’s one thing I’d take from all of this, it’s this:

Instead of asking, “What should I build next?”
Start asking, “What is worth continuing?”

Because eventually, growth doesn’t come from how many things you start.

It comes from what you choose to stick with.