We avoided email by design. It’s noisy, it arrives at the wrong time, and it creates an unwanted historical trail for issues that may have already been resolved. More importantly, many of our commercial clients run only one or two awards a year. If we announce a feature in January and they don’t build a form until September, that information is forgotten. Release notes are useful reference material, but they’re not an effective real-time alerting mechanism.

The question was how to communicate important information to admins exactly at the moment they’re using the product.

The problem

The core technical challenge within Nucleus has always been that it’s deployed across multiple AWS instances, with each client having their own environment. That made platform-wide messaging complicated. I’d avoided pushing for this previously knowing the complexity involved, but after repeated feedback from clients I went back to the team to explore whether cross-instance communication was finally feasible.

The concept I proposed was straightforward. A message is created in one central broadcast instance. Admins see the alert the next time they log in. Alerts can be dismissed individually. Old alerts remain accessible in a simple list for reference. And alerts automatically expire after seven days so the UI stays clean.

The message system had to have a light footprint. Something that helped without becoming another source of noise.

The solution

Because of the 2025 admin redesign, we already had most of the UX components we needed: dismissible banners, table structures, tags, switches, and a flexible left-hand navigation. I asked the designer to prototype a new Alerts section that would remain non-intrusive but still make unread alerts obvious.

For the architecture, we decided to use our demo environment as the broadcasting instance. When a support team member adds an alert there, it writes a row into the Alerts table of every client instance. Each instance then displays the alert independently, allowing admins to dismiss or mark it as read without affecting others.

The seven-day expiry was deliberate. I didn’t want alerts clogging up the UI or being used as a permanent record of when there were issues with the system. This kept things light and tidy, focused on current information rather than historical reference.

The impact

The result is a simple but powerful communication layer. The support team can now reach administrators in context, without clogging inboxes and without overwhelming clients who aren’t actively using the platform. Since launch, we’ve used it for release notifications, known issue alerts, and scheduled maintenance warnings, reaching admins at exactly the right moment without a single email sent.

It’s a small piece of infrastructure, but it’s solved a problem we’d been working around for years.