Skip to main content
With Dreamlit, there’s
  • No SDK to learn
  • No API calls to make (e.g. Twilio, SendGrid, MailGun, Resend)
  • No events to emit from your app code
Thanks to Dreamlit’s database-driven architecture. In fact, since Dreamlit is an end-to-end solution, you can even hand off notifications entirely to your non-coding colleagues like product managers and marketing teams. We handle the infrastructure, scaling, delivery, and monitoring of your notifications so you can focus on the fun stuff: advancing your core product.

​
Drawbacks of traditional approaches: coupling notification logic with app code

On first glance, it may seem like notifications is simple to add to your app. Just whip up a cron job and make a few API calls, right? However, as your application grows, notifications quickly become a bottleneck and a source of technical debt.
As your application grows, you might face:
  • Sudden spikes in traffic leading to increased notification load
  • Longer processing times affecting notification delivery
To handle scale effectively, you’ll need to implement:
  • Message queues to decouple notification sending from your core backend
  • Retry mechanisms with exponential backoff to handle transient failures
  • Parallelization for faster processing
  • Monitoring and failure alerting
  • Rate limiting to protect both your infrastructure and downstream services
  • Notification batching for improved throughput
  • Writing and hosting cron jobs for scheduled notifications
Pour one out if you’ve ever worked with email HTML. Email HTML ≠ web HTML, which means styling and layout do not behave the same way as they do in a web browser. Previewing your templates is non-trivial, often involving a separate dev server, or just sending them to yourself to see if they render correctly.Alternatively, you can build your templates on some third party notification service (like Loops, or Knock), and emit events to it to trigger those notifications. This isn’t ideal either for the reasons outlined in the next section.
  • It’s difficult to ensure type safety of the events emitted between your app and the notification service
  • You lose version control for notification templates and logic
  • It’s harder to test end-to-end, since you have a tight coupling between your app and a third party service
  • You need additional infrastructure to sync your data with the third party service (e.g. contacts/users sync).
  • Potential latency issues from external API calls
  • Added complexity in local development and testing environments
  • There’s a significant learning curve to learning how that service works
  • You have to coordinate between both engineering and product teams to get the desired outcome
Notifications are often processed inline with other business logic and backend requests.This means additional latency and more points of failures in potentially critical code paths, leading to a poorer UX with longer load times and increased error rates. Futhermore, this problem can compound on itself if your logic fans out to many notifications.With Dreamlit, your notification logic is fully decoupled from your application code.

​
Advantages of leveraging Dreamlit

With Dreamlit, it takes just minutes instead of days to add and manage notifications for your app. You can expect to get back weeks of engineering time every year.

​
How your team can do more, with less, with Dreamlit

Leverage AI agents

Use AI agents to “vibe code” your workflows. You can always drop down in the details when you need.Then before you publish, you can leverage the testing AI agent to verify that your workflow is working as expected. Just describe the test cases or let the system generate them for you - and it’ll check that your workflow passes all the tests, so that you can launch your vibe-coded workflows with confidence.

Hand off notifications to your product team

Empower your product team to manage notifications without needing to ask engineers to make changes.

Scale automatically

When you use Dreamlit, you inherit a durable, distributed architecture and a dedicated team to keep your notifications running. Some benefits include:
  • Retry logic. For temporary failures like network issues, we retry steps with exponential back-off.
  • Scheduling. We provision all the infrastructure needed to run and schedule your workflows. No more cron jobs.
  • Rate limiting. In case of bursty traffic, your infrastructure (like your database) won’t be overwhelmed.
  • Fan-out. For example, if an event requires notifying thousands of users, we optimize and parallelize.
  • Analytics tracking. Engagement is automatically logged, and if desired, you can , no need to configure a separate API webhook.
  • Multi-channel delivery.

​
How to ensure database schema changes don’t break notifications

There are several strategies you can use to ensure that schema changes (like renaming or dropping columns) don’t impact published workflows. For more details, visit the Supabase Configuration section.

​
Explore further

AI agents

Learn about the AI agents.

How it works

Learn about the architecture.

Quick start

Create your first workflow.

Security

Security is our top priority.