لماذا بنينا SNDR
قصة تحوّل مشكلة داخلية في تسليم رسائل التحقق إلى منتج مستقل يستخدمه مطورون في المنطقة.

عندما تدير منصات يستخدمها أكثر من مليون شخص، يصبح البريد الإلكتروني التعاملي جزءاً من المنتج نفسه لا مجرد تفصيل تقني. رسالة التحقق التي تتأخر دقيقتين تعني مستخدماً يغلق التطبيق ولا يعود. هكذا بدأت قصة SNDR.
المشكلة التي لم نستطع تجاهلها
في 2025 كنا نعتمد على مزودين أجانب لإرسال البريد من جولة واسبقهم. الفاتورة بالدولار كانت ترتفع مع كل مستخدم جديد، لكن التكلفة لم تكن المشكلة الأكبر. كانت المشكلة أن:
- رسائل التحقق تصل متأخرة أو تذهب إلى البريد المزعج في أوقات الذروة.
- القوالب لا تتعامل مع العربية واتجاه RTL بشكل صحيح.
- الدعم الفني لا يفهم خصوصية السوق ولا يرد في وقت مناسب.
- لا نملك رؤية كاملة: لماذا ارتدت هذه الرسالة؟ ولماذا تأخرت تلك؟
القرار: نبني بدل أن نشتري
بدأنا بطبقة داخلية بسيطة فوق AWS SES: طوابير إرسال في Redis، سجل كامل لكل رسالة في PostgreSQL، ومصادقة تلقائية للنطاقات عبر SPF وDKIM وDMARC. خلال أسابيع انخفض زمن وصول رسائل التحقق من دقائق إلى ثوانٍ، وأصبحنا نعرف مصير كل رسالة لحظياً.
عندها أدركنا أن كل شركة ناشئة في المنطقة تواجه المشكلة نفسها، وأن ما بنيناه لأنفسنا يمكن أن يكون منتجاً.
ماذا يميز SNDR
- واجهة واحدة واضحة تنتقل بك من إنشاء الحساب إلى أول رسالة في أقل من عشر دقائق.
- مراقبة كاملة لكل رسالة: أُرسلت، وصلت، فُتحت، أو ارتدت، مع Webhooks لكل حدث.
- دعم أصيل للعربية في القوالب والتوثيق والدعم الفني.
- بنية جاهزة للنطاق الواسع لأنها كانت تخدم مليون مستخدم قبل أن تُطلق.
الخلاصة
أطلقنا SNDR في مايو 2026 بعد أشهر من التشغيل الداخلي. الدرس الذي نكرره في كل منتج: أفضل المنتجات تولد من مشكلة عشناها بأنفسنا. إن كنت تبني منتجاً وتحتاج بريداً يصل فعلاً، جرّب SNDR وأخبرنا برأيك.
مقالات ذات صلة

الذكاء الاصطناعي في منتجاتنا: من الفكرة إلى الإنتاج
كيف نقرر أين يستحق الذكاء الاصطناعي مكانه في المنتج، وكيف ننقله من تجربة إلى ميزة يعتمد عليها المستخدمون.
اقرأ المزيد
كيف نبني منصات تتحمل مليون مستخدم
المبادئ الهندسية التي نطبقها من اليوم الأول حتى لا يكون النمو مفاجأة مؤلمة.
اقرأ المزيد