Why I Built SideHunt: Rethinking How Side Projects Get Discovered

Like a lot of builders, I’ve launched projects that quietly disappeared.

Not because they were bad.

Not because people didn’t need them.

But because after launch, there was nowhere meaningful for them to stay visible.

That frustration is what led me to build SideHunt.

This wasn’t a “let’s build another directory” idea.

It came from repeatedly seeing the same pattern:

Builders spend weeks (sometimes months) creating side projects, only for those projects to get a few hours of attention before disappearing into the noise.

And the more I thought about it, the more I realized the problem wasn’t the projects.

It was discoverability.

The Problem I Kept Seeing

The internet has never been better for building.

With AI-assisted development, better frameworks, and faster deployment pipelines, launching products has become dramatically easier.

But product discovery hasn’t evolved at the same pace.

The current launch ecosystem often rewards:

• Existing audience size

• Launch-day timing

• Social amplification

• Momentum-driven visibility

That works well if you already have distribution.

It’s much harder if you’re an independent builder quietly shipping useful things.

I kept asking myself:

Why should discoverability depend so heavily on launch-day noise?

That question eventually became the seed for SideHunt.

What I Wanted SideHunt to Solve

When I started building SideHunt, I wasn’t trying to compete with established launch platforms.

I was trying to solve a very specific problem:

How can side projects stay discoverable beyond launch day?

I wanted SideHunt to feel like a place where builders could showcase their work in a way that creates longer-term visibility.

A place where projects don’t disappear after the initial post.

A place designed around sustained discovery rather than temporary spikes.

That became the core idea behind SideHunt.

Building SideHunt Changed How I Think About Distribution

One unexpected thing I learned while building SideHunt is this:

Distribution isn’t something you “do after shipping.”

It’s part of product design itself.

As builders, we obsess over:

• Features

• UX

• Performance

• Technical architecture

But often treat discoverability as an afterthought.

Building SideHunt forced me to think differently.

It made me realize that discoverability is infrastructure.

If users can’t consistently find a product, even great execution struggles to matter.

The Bigger Lesson for Indie Builders

Building SideHunt taught me something I think many indie makers are realizing:

Shipping is becoming commoditized.

What differentiates products now isn’t just what they do.

It’s how effectively they get discovered by the right people.

This is why “build in public” matters.

Not because public updates are inherently valuable.

But because they create discovery loops.

They create surfaces where people can encounter your work repeatedly.

That’s the thinking I’m trying to bring into SideHunt.

What I’m Still Figuring Out

I’m still learning.

SideHunt is very much an evolving product.

I’m actively thinking through questions like:

How should discovery be ranked?

What helps projects stay visible over time?

How do we reward quality over hype?

How do we make discovery fairer for smaller builders?

These are hard problems.

And honestly, that’s what makes building this interesting.

Why I’m Sharing This on Peerlist

I’m sharing this because Peerlist has one of the most thoughtful builder communities out there.

A lot of us are solving similar problems from different angles.

If you’ve ever felt like your side project deserved more visibility than it got, you’ve probably felt the same frustration that led to SideHunt.

This is my attempt to explore that problem.

And I’d genuinely love feedback from fellow builders.

Because I don’t think the future of product discovery is about louder launches.

I think it’s about building better systems for meaningful discovery.

That’s what I’m trying to build with SideHunt.