Bellotify
Stop losing customers who never see your updates.
Hi, I'm Hani, one of the two founders behind Bellotify.
We kept noticing that even though our users were shipping updates regularly, almost nobody was reading their changelogs. So we started asking why.
The same answer kept coming up: it looked too technical. Even when the update itself was simple, a list of bullet points and version tags read like a commit log, not something a regular user would want to open.
So we rebuilt the changelog template from scratch based on that feedback — clean, modern, and written for a non-technical reader instead of a developer. Along the way we also added reactions and comments, so users can respond directly to updates instead of staying silent, and analytics that show who's actually opening your changelog.
Has anyone else run into this — building something useful that nobody engages with simply because of how it looks?
We are the team behind Bellotify, a changelog and user notification widget for SaaS products.
While building it, we kept running into the same small frustrations that had nothing to do with our core product. Writing clean release notes from raw git commits. Generating a privacy policy before launch. Testing webhooks without spinning up an entire environment. None of it was complicated, but every tool we found for these tasks was either ad-heavy, slow, or gated behind a signup for no good reason.
So we started building them ourselves. One tool at a time, whenever we hit a wall.
We now have ten tools live at bellotify.com/free-tools:
AI Changelog Generator — paste raw git commits, get clean release notes
Privacy and ToS Generator — usable legal pages without a lawyer or a subscription
Roadmap Simulator — drag and drop Now / Next / Later board, exportable
Screenshot Wrapper — turn screenshots into device mockups for landing pages
SemVer Calculator — figure out your next version tag instantly
JSON Diff — compare two JSON objects visually
Webhook Tester — inspect incoming requests without any setup
Image Compressor, Favicon Generator, Whiteboard
Everything runs in the browser. No account, no ads, no paywalls. Your data never leaves your machine.
We are still adding to the collection. If there is a small repetitive task that keeps slowing you down and you have not found a clean solution for it, tell us — we will probably build it.
What tool do you wish existed but has not been built well yet?
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.
-
1
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?
-
1
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.
-
-
1
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.
-
1
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.
-
1
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.
-
-
Comment