Trendy
Miswag needed a loyalty platform that didn't exist — one that could power multiple retail brands with completely different reward structures from a single codebase. The entire specification fit on one Figma whiteboard. I architected and delivered a live demo in four months, and the full platform in nine. احتاجت Miswag إلى منصة ولاء لم تكن موجودة — واحدة تمكّن علامات تجارية متعددة من تشغيل برامج مكافآت مستقلة بهياكل مختلفة كلياً من كودبيس واحد. كانت المواصفة الكاملة مرسومة على لوحة Figma واحدة. بنيت معمارية المنصة وسلّمت عرضاً تجريبياً حياً في أربعة أشهر، والمنصة الكاملة في تسعة.
The Situationالسياق
A loyalty platform built from nothingمنصة ولاء بُنيت من الصفر
Trendy started as a greenfield project with no existing infrastructure — and, initially, no formal specification beyond a single Figma whiteboard. The business goal was clear: a multi-tenant SaaS that would let different Miswag brands run independent loyalty programs — each with their own tiers, reward rules, and campaigns — from a single codebase. Working from that whiteboard alone, I had a live demo running by January 2025, four months after kickoff. The platform needed to handle point accumulation, tier progression, campaign scheduling, and partner integrations across tenants without any code changes per tenant. بدأ Trendy كمشروع جديد تماماً بلا بنية تحتية موجودة — ودون مواصفة رسمية في البداية سوى لوحة Figma واحدة. كان هدف الأعمال واضحاً: منصة SaaS متعددة المستأجرين تتيح لعلامات Miswag المختلفة تشغيل برامج ولاء مستقلة — بمستوياتها وقواعد مكافآتها وحملاتها الخاصة — من كودبيس واحد. انطلاقاً من تلك اللوحة وحدها، أطلقت عرضاً تجريبياً حياً في يناير ٢٠٢٥، بعد أربعة أشهر من الانطلاق. احتاجت المنصة إلى معالجة تراكم النقاط وتقدم المستويات وجدولة الحملات وتكاملات الشركاء عبر المستأجرين دون أي تغييرات في الكود لكل مستأجر.
The Challengeالتحدي
A rewards engine that business teams could ownمحرك مكافآت تملكه فرق الأعمال
The hardest problem wasn't the multi-tenancy itself — it was the reward rules engine. Loyalty rules are deeply conditional: earn X points when a user from tier Y buys product category Z during campaign period W, unless they've already redeemed today. Hardcoding rule logic means every new campaign variation requires a developer. At the scale Miswag planned, that's unsustainable. The challenge was building a system where business teams could define new reward conditions without touching the codebase. لم تكن المشكلة الأصعب هي التعدد في المستأجرين بحد ذاته — بل كانت محرك قواعد المكافآت. قواعد الولاء معقدة وشرطية: اكسب X نقطة عندما يشتري مستخدم من مستوى Y فئة منتج Z خلال فترة حملة W، إلا إذا استرد اليوم بالفعل. تضمين منطق القواعد يعني أن كل تنويع جديد للحملة يتطلب مطوراً. على النطاق الذي خططت له Miswag، هذا غير قابل للاستدامة. كان التحدي بناء نظام يتمكن فيه فرق الأعمال من تعريف شروط المكافآت الجديدة دون لمس الكودبيس.
Key Decisionsالقرارات المحورية
Three choices that shaped the architectureثلاثة قرارات شكّلت البنية
Miswag Expression Language (MEL) for reward rulesلغة Miswag التعبيرية (MEL) لقواعد المكافآت
Rather than a decision table or hardcoded conditions, I designed MEL — the Miswag Expression Language — a minimal expression language that non-technical admin users could use to define reward rules directly in the Filament admin panel. This decoupled business logic from deployment cycles entirely. Admins define rules; the engine evaluates them at transaction time. This single decision unlocked the platform's long-term flexibility and removed engineering from the critical path for every new campaign. بدلاً من جداول القرار أو الشروط المُضمَّنة في الكود، صممت MEL — لغة Miswag التعبيرية — لغة تعبير مصغّرة يستطيع المسؤولون غير التقنيين استخدامها لتعريف قواعد المكافآت مباشرةً في لوحة Filament. هذا فصل منطق الأعمال عن دورات النشر كلياً. المسؤولون يعرّفون القواعد؛ المحرك يُقيّمها عند وقت المعاملة. هذا القرار وحده فتح مرونة المنصة على المدى البعيد وأزال الهندسة من المسار الحرج لكل حملة جديدة.
SQS for async batch processingSQS للمعالجة غير المتزامنة
High-volume loyalty events — purchases, point accumulations, tier upgrades — don't need synchronous responses. I routed all non-critical processing through SQS queues, keeping API response times fast regardless of backend load. This also made the system resilient to traffic spikes: queue depth absorbs burst traffic without adding infrastructure to the critical path, and failed jobs retry automatically with exponential backoff. أحداث الولاء عالية الحجم — المشتريات، تراكمات النقاط، ترقيات المستويات — لا تحتاج إلى ردود متزامنة. وجّهت جميع المعالجة غير الحرجة عبر قوائع SQS، مما يُبقي أوقات استجابة الـ API سريعة بغض النظر عن الحمل الخلفي. كذلك جعل النظام مرناً أمام ذروات الحركة: عمق القائمة يمتص حركة الاندفاع دون إضافة بنية تحتية للمسار الحرج، والوظائف الفاشلة تُعاد محاولتها تلقائياً بتراجع أسي.
OpenAI GPT for campaign content generationOpenAI GPT لتوليد محتوى الحملات
Rather than having admins write notification copy and campaign descriptions manually — which was error-prone and slow — I integrated GPT to generate first-draft content from structured campaign parameters. Admins review and publish rather than write from scratch. This cut campaign setup time significantly and reduced ops burden, particularly for non-English-speaking admin teams running Arabic-language campaigns. بدلاً من كتابة المسؤولين لنسخ الإشعارات وأوصاف الحملات يدوياً — وهو ما كان عرضة للأخطاء وبطيئاً — دمجت GPT لتوليد مسودة المحتوى الأولى من معاملات الحملة المُهيكلة. المسؤولون يراجعون وينشرون بدلاً من الكتابة من الصفر. هذا قلّص وقت إعداد الحملات بشكل ملحوظ وخفّف العبء التشغيلي، خاصةً لفرق الإدارة غير الناطقة بالإنجليزية والتي تُدير حملات باللغة العربية.
Resultsالنتائج
Shipped and scalingمُطلقة وفي توسّع
9 mo٩ شهر
Live in May '25
First Demo in Jan '25إطلاق مايو '25
أول عرض يناير '25
200 K+٢٠٠ ألف+
Active usersمستخدم نشط
300 K+٣٠٠ ألف+
Transactions / monthمعاملة شهرياً
0٠
Dev needed per new rule typeمطور لكل نوع قاعدة جديد