NotifyX

I kept rebuilding notifications for every project I worked on. Between setting up providers, workers and scheduling, they took time and usually became an afterthought. Web notifications were even easier to forget.

So I built NotifyX once and started using it across my projects. It has its own worker and scheduler, which makes notifications easy to set up from day zero, even for an MVP. The best part is that it's open source, so anyone can adapt it to their own needs.

I built the API, queue, workers and scheduler with Node.js, BullMQ, Redis, PostgreSQL and Prisma. FCM, APNS, HMS and Web Push sit behind the same API, so each app doesn't need its own implementation for every provider. I also wrote SDKs for web, Flutter and React Native.

Immediate messages and scheduled campaigns use the same delivery pipeline. That let me keep the repeated infrastructure in NotifyX rather than adding a separate worker and scheduler to each product.

Sending a message is only part of the work. A provider can time out, a device token can become invalid, or a worker can stop during a job. I added retries with backoff, removal of invalid tokens and a place to inspect permanent failures. Delivery states stay in PostgreSQL, and the React dashboard makes them visible without searching through logs.

The dashboard also brings together message composition, campaigns, reusable templates and application configuration. These are the tools I need around the delivery system to keep using it across different apps.

I started building it in 2024 while exploring what AI could help me do. Building a complete system with it felt amazing back then. I've been using NotifyX across multiple apps since, and I'm proud of how well it's held up. It just works.

Cardyiq, Sadeek, Asheerty, Orivo and Baseerah use NotifyX. Having this part ready has made it easier to include notifications at the beginning of a new project, rather than waiting until everything else is finished.

I'd add per-application rate limits earlier, so a busy app has less effect on the others sharing a deployment. I'd also define delivery receipts more clearly from the start. Building something reusable means paying attention to what happens when several products depend on it, not just getting the first message sent.