3
1 Comment

I Thought Shipping Features Meant I Was Making Progress

For a long time, I measured progress by how much I built.
A new feature? Progress.
A new page? Progress.
A weekend spent fixing bugs and adding functionality? Definitely progress.
My GitHub activity looked healthy. The product kept getting bigger.
But there was one problem.
I wasn't really getting anywhere.
Imagine a developer friend of mine.
He spent an entire weekend building a feature for his SaaS.
Friday night: planning.
Saturday: coding.
Sunday: debugging, polishing, testing.
By Sunday evening, he finally shipped it.
He was exhausted, but proud.
He checked the analytics the next morning.
Almost nobody had used it.
Actually, almost nobody had even looked at it.
And that's the part that hurts.
Not because the feature was badly built.
It wasn't.
It worked exactly as intended.
The problem was that nobody cared enough to use it.
I've been thinking about this a lot while building Featly.
Because developers have a very convenient way of measuring progress:
We count what we ship.
It's easy to look at a commit history and feel productive.
It's much harder to answer:
Did anyone use what I built?
Did it solve a real problem?
Did users come back because of it?
Did it change anything for them?
Should I even be building this?
And I think that's where a lot of developer-founders get stuck.
We become extremely good at solving problems that nobody asked us to solve.
We build the feature because we can.
We polish it because we're already invested.
We add another feature because the roadmap says so.
Then months later, we have a product with 30 features and very little usage.
That's a scary place to be.
Because the solution isn't necessarily building faster.
Sometimes the solution is to stop building for a moment and start paying attention.
That's one of the reasons I'm building Featly.
I want to understand what actually happens inside a product—not just collect numbers, but understand which features people use, where they drop off, what brings them back, and ultimately what those behaviours should mean for the product.
I'm still figuring out how far that idea can go.
But one thing I'm increasingly convinced of is this:
Shipping is an activity.
Progress is when what you shipped actually matters to someone.
And I'm trying to get better at telling the difference.
If you're building a SaaS: what's a feature you spent a lot of time building that barely got used?
I think there are a lot of those stories out there kindly share yours.

on September 8, 2026
  1. 1

    The distinction between shipping and progress is important.

    The harder part seems to come after the behavior shows up: figuring out which signals are actually strong enough to change what you build, rather than simply giving you another dashboard to look at.

    That feels like the real test of the idea.