الخلاصة التنفيذية
Lezzoo يقدّم أوضح مثال محلي على توسع منتج من توصيل الطعام إلى منظومة متعددة الخدمات. الموقع الرسمي يصف الطعام والبقالة والصيدلية وExpress والخدمات عند الطلب والتجارة والمحفظة والألعاب وJiran وميزات AI، إضافة إلى طبقات للتجار وB2B. وينشر أرقاماً مثل أكثر من مليون عميل و2,500+ بائع؛ يجب عرضها دائماً بصيغة بحسب Lezzoo لأنها أرقام الشركة.
الدرس السينيور: السوبر آب ليس Navigation فيه 14 أيقونة. هو هوية موحدة، دفع/رصيد، اكتشاف، إشعارات، صلاحيات، بيانات وأعمال تشغيلية مشتركة تسمح لكل خدمة أن تستفيد من الأخرى. إذا لم توجد خدمة أساسية ذات تكرار وDistribution، تتحول Mini Apps إلى منتجات ضعيفة داخل Container ثقيل.
رحلة التوسع
بحسب قصة الشركة، بدأ Lezzoo بالتوصيل ثم توسع إلى ضروريات وفئات أخرى، B2B، ألعاب واجتماعي ومدفوعات. هذا التسلسل مهم: Core use case متكرر أولاً، ثم خدمات تزيد التكرار أو تستثمر الشبكة الموجودة.
نموذج Flywheel المعلن يمكن قراءته هكذا:
مستهلكون وطلبات → تجار أكثر وبيانات طلب → أدوات تاجر/دفع → Supply chain وB2B → توفر أفضل → تجربة واستخدام أكثر.
إضافة الألعاب والاجتماعي تفتح حلقات Retention خارج لحظة الجوع، لكنها تضيف مخاطر Moderation ومحتوى واقتصاد مكافآت يجب ضبطه.
محفظة المنتجات
Core Commerce
طعام، بقالة، صيدلية، Express وتجارة. تشترك في الهوية والعنوان والدفع والتوصيل، لكنها تختلف في المخزون والبدائل وSLA.
Fintech
المحفظة يمكنها تقليل احتكاك الدفع، دعم Loyalty وإبقاء القيمة داخل النظام. لكنها ترفع مستوى الامتثال والأمن والمطابقة وخدمة النزاعات.
Engagement
ألعاب، Social feed وAI ترفع وقت وتكرار الاستخدام، لكن يجب قياس انتقالها إلى قيمة تجارية، لا DAU سطحي فقط.
B2B
أدوات التاجر وسلسلة التوريد قد تصنع Moat أعمق من تطبيق العميل؛ المنصة تصبح جزءاً من تشغيل البائع، لا مجرد قناة إعلان.
نموذج العمل
تفاصيل الإيراد حسب الخدمة غير منشورة في المصادر المستخدمة. في Super App، نماذج محتملة تشمل Commerce commissions، delivery/service fees، merchant tools، fintech revenue وفق التنظيم، إعلانات/ظهور، B2B margins وخدمات رقمية.
الخطر هو Cross-subsidization غير المرئي: خدمة تنمو في الاستخدام لكنها تستهلك دعم وبنية ولا تخلق احتفاظاً أو هامشاً. لذلك يحتاج كل Domain إلى P&L ومؤشرات، مع Platform costs مشتركة موزعة بوضوح.
التحليل التسويقي
Lezzoo يضع قصة محلية قوية: شركة من أربيل تبني للعراق، مع Y Combinator كإشارة ثقة. كما يستخدم الألعاب والمكافآت كوسيلة اكتساب وعودة، لا كزينة.
لمنتج جديد، لا تبدأ برسالة "كل شيء في تطبيق واحد"؛ هذه رسالة واسعة بلا دليل. ابدأ بوعد يومي محدد، ثم استخدم Cross-sell بعد إثبات الاستخدام:
- من توصيل الطعام إلى بقالة لنفس العنوان.
- من الطلب إلى Wallet/membership.
- من شبكة التجار إلى أدوات إدارة أو توريد.
معمارية Super App المتوقعة
استنتاج تحليلي، لا وصف لـStack Lezzoo.
Platform layer
- Identity/KYC levels، Profiles، Addresses وConsent.
- Wallet/Ledger/Payments وفق الترخيص.
- Notification، Search، Offers، Loyalty وExperimentation.
- Trust & Safety، Fraud signals، Support وحل النزاعات.
- Observability، Feature flags وRemote config.
Domain modules
كل خدمة تملك Data model وحالاتها وSLA، ولا تُحشر في جدول طلبات عام غير منضبط. عقد API ثابت يسمح بتضمينها داخل Shell موحد.
Frontend strategy
Modular app، Design system، Deep links وNavigation governance. Mini app framework قد يفيد لاحقاً، لكنه ليس شرط MVP. الأداء مهم: كل خدمة جديدة لا يجب أن تضخم تحميل المستخدم الذي يريد وجبة فقط.
Data
Event taxonomy مشتركة، مع فصل بيانات مالية وحساسة. Recommendation يجب أن تحترم Consent والسياق، لا تجمع كل شيء بلا غرض.
مخاطر السوبر آب
- تضخم المنتج وبطء الإطلاق.
- ضعف Discoverability داخل كثرة الخدمات.
- تضارب Ownership بين الفرق.
- Wallet/Fraud/Compliance.
- Moderation للمحتوى الاجتماعي.
- نظام مكافآت يخلق التزاماً مالياً أو إساءة استخدام.
- تعطل Platform مشترك يؤثر في عدة خدمات.
متى يكون Super App قراراً صحيحاً؟
نعم عندما لديك Core product متكرر، قاعدة موثوقة، أصول مشتركة حقيقية، وشريك/خدمة جديدة تحسن Economics أو Retention. لا عندما تريد عرض عدد ميزات كبير للمستثمر.
خارطة بناء واقعية
المرحلة 1: Vertical واحد + هوية/عناوين/دفع/دعم قابلة للتوسع. المرحلة 2: خدمة مجاورة تستعمل نفس الجمهور أو الشبكة. المرحلة 3: Loyalty/Wallet بعد فهم الاستخدام والامتثال. المرحلة 4: Merchant OS أو B2B. المرحلة 5: Engagement layers إذا أثبتت تأثيراً على Retention أو GMV، مع Safety.
KPIs
- Core service retention وContribution.
- Cross-service adoption خلال 30/90 يوماً.
- Incremental frequency، لا مجموع DAU فقط.
- نسبة المستخدمين متعددي الخدمات وجودة Cohorts.
- Wallet activation وFailed transactions/disputes.
- Merchant multi-product adoption.
- Crash-free sessions وحجم/زمن التطبيق حسب Device tier.
أسئلة شائعة
هل يجب بناء Microservices منذ البداية؟
لا. Modular monolith منضبط قد يكون أسرع وأأمن لفريق صغير. افصل الخدمات عندما توجد حدود Domain وفريق/حمل/موثوقية تبرر ذلك.
هل الألعاب مناسبة لكل Super App؟
لا. تحتاج اقتصاد مكافآت، محتوى، مكافحة إساءة وقياس Incremental value. قد تصبح تشتيتاً مكلفاً.
ما أول أصل مشترك؟
هوية موحدة، عنوان، سجل طلب، دعم وقياس أحداث. الدفع المشترك يأتي حسب الحاجة والتنظيم.
قرار SUMIX
نصمم Platform roadmap يبدأ من خدمة رابحة أو متكررة، ثم نضيف Domain يشارك أصولاً حقيقية. لا نبني "سوبر آب" بالاسم؛ نبني تراكم قيمة قابل للقياس.
CTA: حوّل فكرتك إلى خارطة Platform تدريجية → /services/mobile-app-development حل مرتبط: /solutions/delivery-app
المصادر
*تحليل مستقل. Lezzoo وعلاماتها ملك أصحابها. أرقام الشركة منسوبة إليها.*