I spent months shipping updates no one knew about. Here’s how I fixed it.
I'm a builder. I ship things. And for a long time, I had this embarrassing pattern:
Finish a feature → push to production → tell nobody → wonder why nothing changed.
I tried everything people recommend.
Social media first. But growing an audience takes months, money, and consistency. It's a long game, and I was trying to tell existing users about updates, not find new ones. Wrong tool for the job.
So I collected emails and sent newsletters. Open rates kept dropping until it felt like I was writing into a void. Then I built a changelog page, thinking at least it'd be there for people who cared. Nobody visited it.
Eventually I stopped communicating altogether and just kept building in silence.
The real problem wasn't any of those tools. It was that I was treating product communication like a separate job. Something to do after the real work. So it always got done badly, or not at all.
Last year I started talking to other founders about this. Turns out it's incredibly common. People ship solid products, but the updates vanish the moment they hit production. Users don't see the changelog. They miss the email. They never know you fixed the bug they complained about three months ago.
So they churn. Not because the product got worse. Because it felt like it stopped moving.
I built Bellotify to solve my own version of this. It's a notification bell and changelog widget you drop into your site with one script. Updates appear right where users already are — no separate page, no hoping they open an email, no modal interrupting their flow.
The idea was simple: make communicating an update so frictionless that you actually do it. And make it hard for users to miss.
It's still early. Talking to the first batch of users now and figuring out what this becomes.
Curious what others here do — do you have a system that actually keeps users in the loop, or is this something you also kind of wing? Would love to hear what's worked.
Site is bellotify.com if you want to take a look.
This is very relatable. I’ve had the same problem - shipping something, assuming users will somehow notice, then realising the update basically disappeared.
The point about product communication becoming a separate job really hits. Changelogs and newsletters sound simple, but unless they’re part of the actual product flow, they’re easy to neglect and even easier for users to miss.
The in-app bell approach makes sense because it meets users where they already are without being as intrusive as a modal. I’d be curious how you’re thinking about avoiding notification fatigue though - do you plan to let users filter by update type, like bug fixes vs new features vs important announcements?
Thanks for the thoughtful comment! I'm glad the problem resonated with you because that's exactly the experience that led us to build Bellotify.
And yes, I completely agree about notification fatigue. We've already added filters in the changelog so users can browse updates by category.
I'd be careful treating this as a product-communication problem too quickly.
The interesting question may not be whether users see updates.
It may be what users are actually deciding when they see them.
Those sound similar, but they can lead to very different conclusions about the problem, the buyer, and which signals deserve attention early on.
I wouldn't make that call casually from the current feedback.
I agree that visibility alone doesn’t guarantee meaningful understanding or action.
That’s why we added Visitor Engagement signals in Bellotify (opens, views, reactions, comments). The goal is not to assume “seen = cared”, but to start separating exposure, reaction, and intent.
Early on, you still need a baseline layer where updates actually reach users in-product. Otherwise you don’t even get the data needed to evaluate those differences.
Possibly.
The reason I stopped short earlier is that I don't think the interesting part is the engagement signals themselves.
I think there's a bigger decision sitting underneath how those signals end up getting interpreted.
That's one of those things that can quietly shape what gets built next and which feedback ends up looking meaningful.
I wouldn't try to unpack that properly in a thread.
If you're curious, drop your email and I'll put together the tighter version.