Behind the scenes: the bell that does not shout, rebuilding an application’s notifications

Our first useful notification arrived drowned in everything requiring nothing. Five comments in one session, one simple cause, and a rebuild delivered the same day: the story of an avalanche we created ourselves.

On August 31, 2026, the first real use of our notification bell produced five comments in one session (internal team notes). The inbox labelled all existing activity as new and listed approval requests for every product at once. We rebuilt it the same day.

A bell that was right too often

The original idea held up: when an agent team works while you do something else, there must be a place saying what happened and what awaits your decision. The first version said everything. Every product ever opened, every document pending for weeks and every abandoned trial surfaced in the same list, at the same level as the only thing that mattered. Two causes combined. The inbox read all pending approvals while the workshop shows only one at a time. And nothing remembered what you had already seen before the update, so the entire past arrived at once, labelled new.

Three decisions in one evening

First: for the open product, the bell shows only the current approval request blocking progress, never the stack. Second: notifications survive application closure, because an alert disappearing when you quit is useless to someone working in evenings. Third: one sorted panel, this product first, then events elsewhere. We added ‘Clear completed items’, tidying closed events without touching pending decisions. These three decisions share one feature: they remove information from the screen. We hesitated because a removed notification is one someone will someday seek. The answer was to move rather than delete: what no longer appears in the bell remains in the activity feed, filterable by product, and that feed populates when the application opens rather than after the first work.

One response, one banner

A subtler defect cost just as much user trust: each agent response could stack several information banners in the conversation. A response now shows at most one banner. The action button on transient messages, black by default because it had not been styled, returned to the application's colour palette. These fixes change no product capability: they change how much noise you must cross to find the line requesting your decision, the same problem described in our second beta feedback pass.

The defect found in a screenshot

The day after publishing, a screenshot revealed a remnant: a brand brief written independently by Léa appeared as a pending decision in every old test product, and the line led to Home instead of Studio. Fixed and republished the same day. We wanted to number the fix 0.1.15.1: impossible, a version number has three numbers, so it became 0.1.16. The other lines surfacing from old projects were real approval requests left open: the answer is archiving trials, not silencing the bell.

The rule we now impose on ourselves

Every new event source passes through the same entry point, never a second route. That is the only guarantee a notification cannot exist twice, evade sorting or contradict the activity feed. The general lesson goes beyond us: a notifying system must first know what you have already seen. Without that memory, the first update turns everything existing into alerts, and users learn to ignore the bell in one evening. We were lucky with timing: the defect appeared internally before reaching our two testers, who would have received the same barrage on updating.

What it tells you about a tool

When testing software that works in your absence, open its notification inbox after two weeks, not day one. Count lines calling for your decision and those reporting a past fact. If the ratio leans the wrong way, you will stop looking, and the product loses its only channel for saying work awaits your approval. For us, that decision remains the point where everything stops until you answer, making the bell's clarity non-negotiable.