Why we built SNDR

When you run platforms used by more than a million people, transactional email stops being a technical detail and becomes part of the product. A verification email that arrives two minutes late is a user who closes the app and never comes back. That is where the SNDR story begins.

The problem we could not ignore

Through 2025 we relied on foreign providers to send email from Jawlah and Asbghm. The dollar bill grew with every new user, but cost was not the biggest issue. The real problems were:

• Verification emails arriving late or landing in spam at peak hours.
• Templates that mishandled Arabic and right-to-left layout.
• Support that did not understand the market and rarely answered in time.
• No real visibility: why did this message bounce, and why was that one delayed?

The decision: build instead of buy

We started with a thin internal layer on top of AWS SES: sending queues in Redis, a full record of every message in PostgreSQL, and automatic domain authentication with SPF, DKIM and DMARC. Within weeks, verification emails went from minutes to seconds, and we knew the fate of every message in real time.

That was the moment we realised every startup in the region faces the same problem, and that what we had built for ourselves could be a product.

What makes SNDR different

• One clear API that takes you from sign-up to your first email in under ten minutes.
• Full observability for every message: sent, delivered, opened or bounced, with webhooks for each event.
• Native Arabic support across templates, documentation and technical support.
• Infrastructure built for scale, because it served a million users before it ever launched.

Takeaway

We launched SNDR in May 2026 after months of internal use. The lesson we keep relearning with every product: the best products come from problems you have lived yourself. If you are building something and need email that actually arrives, try SNDR and tell us what you think.