Laundry Heroes
منظومة غسيل عند الطلب في السعودية: تطبيق Flutter ثنائي اللغة، ولوحة تحكم تدير التطبيق وتشغّله، وموقع تسويقي — يعملون فوق Laravel API واحد، بطلب ودفع وتتبع مباشر داخل مسار واحد.
- الدور
- قيادة تقنية · تسليم مع فريق DevSparks
- الخدمات
- تطبيق Flutter (iOS + Android) · تصميم UI/UX منطلق من الهوية · Backend API بـ Laravel وMySQL · لوحة تحكم تدير التطبيق (React 19) · موقع تسويقي (Next.js) · مدفوعات Moyasar ورسائل Authentica · تحليلات Segment وMixpanel · تكامل Google Maps والإشعارات · النشر على App Store وGoogle Play
- التقنيات
- Flutter · Laravel · MySQL · React 19 · Next.js 16 · Redux Toolkit · Moyasar · Authentica · Segment · Mixpanel · Firebase FCM · Google Maps API
- العميل
- Laundry Heroes
- المجال
- خدمات عند الطلب
- المدة الزمنية
- 16 أسبوعًا · 2025
01 / سياق العمل
المشكلة المطلوب حلّها
خدمات الغسيل في السعودية كانت تعتمد كثيرًا على الطلبات عبر الهاتف وWhatsApp، من دون تسعير مباشر أو تتبع واضح أو رؤية تشغيلية موحّدة. أراد Laundry Heroes تقديم تجربة أسهل، وهو ما تطلّب خط منتجات رقميًا كاملًا: تطبيقًا ثنائي اللغة على iOS وAndroid، ولوحة تحكم للتشغيل اليومي، وموقعًا للعلامة — جميعها بهوية واحدة.
Laundry Heroes منظومة غسيل عند الطلب في السعودية تغطي العناية بالملابس والسجاد والألحفة، مع خدمتي الاستلام والتوصيل. اختارت العلامة المنافسة من خلال تجربة أكثر راحة في سوق يعتمد كثيرًا على الهاتف وWhatsApp، لذلك احتاج المشروع إلى إطلاق ثلاثة أسطح مترابطة فوق Laravel API واحد وقاعدة MySQL واحدة: تطبيق ثنائي اللغة على iOS وAndroid، ولوحة تحكم للعمليات اليومية، وموقع للعلامة — جميعها بهوية مرحة ومتسقة. ولوحة التحكم هي المكان الذي يُدار منه التطبيق فعليًا: يتحكم الفريق في الخدمات والتسعير والعروض والسائقين والطلبات وحسابات العملاء التي يعرضها التطبيق، من دون انتظار مطوّر أو تحديث جديد على المتجر.
02 / من النطاق إلى الإطلاق
كيف تحرّك العمل؟
أصبح المنتج أوضح عبر قرارات محددة ونسخ عاملة وملاحظات مستمرة، لا عبر انتظار كشف نهائي طويل.
07 خطوات
خطوة 01
بدأنا بالاكتشاف ورسم الخدمة كاملة — الطلب والاستلام والغسيل والتوصيل — من منظور العميل وفريق التشغيل، ثم حددنا ثلاثة منتجات تشترك في Backend واحد وهوية واحدة.
خطوة 02
صممنا هوية مستلهمة من أبطال القصص بألوان وردية وسماوية، وبنينا التجربة بالعربية أولًا مع تدفقات RTL كاملة لتمييز المنتج داخل فئة يغلب عليها الطابع الوظيفي.
خطوة 03
نمذجنا الطلبات والتسعير والسائقين والفواتير في MySQL وأتحناها عبر Laravel API واحد، ثم أضفنا الخدمات الخارجية التي يعتمد عليها التشغيل: Moyasar للمدفوعات، وAuthentica لرموز التحقق ورسائل حالة الطلب، وFirebase للإشعارات.
خطوة 04
حددنا لوحة التحكم كسطح إدارة للتطبيق نفسه، لا كشاشة تقارير بجانبه: قائمة الخدمات، والتسعير لكل قطعة، ومناطق التغطية، والعروض، والسائقون، وحالات الطلب، وحسابات العملاء التي يعرضها التطبيق تُدار كلها من هناك.
خطوة 05
بنينا الأسطح الثلاثة بالتوازي فوق هذا الـ API: تطبيق Flutter بطلب سريع وتتبع مباشر، ولوحة تحكم React للخرائط والتحليلات والفواتير، وموقع Next.js ثنائي اللغة.
خطوة 06
وثّقنا مسار العميل عبر Segment إلى Mixpanel، ليصل سلوك الطلب من التطبيق ولوحة التحكم والموقع إلى مكان واحد بدل ثلاث قراءات منفصلة.
خطوة 07
نشرنا على App Store وGoogle Play، ودرّبنا فريق التشغيل على لوحة التحكم، وحسّنا التدفقات من استخدام الخدمة في السعودية.
03 / القرارات التي شكّلت المنتج
قرارات المنتج الأساسية
قاعدة Flutter واحدة بدل تطبيقين منفصلين
- سياق العمل
- كان على التطبيق الوصول إلى App Store وGoogle Play ضمن خط منتجات يُسلّم خلال مدة المشروع البالغة 16 أسبوعًا.
- القرار
- بنينا قاعدة Flutter مشتركة لـ iOS وAndroid، مع دعم كامل للعربية وRTL إلى جانب الإنجليزية.
- لماذا
- أتاحت القاعدة المشتركة تنسيق الإطلاق على المنصتين وتقليل ازدواجية التطوير، بينما كان التطبيق ولوحة التحكم والموقع تُبنى بالتوازي.
تصميم عربي أولًا، لا ترجمة لاحقة
- سياق العمل
- كان من الممكن تصميم التطبيق بالإنجليزية ثم إضافة العربية لاحقًا، أو بناء اللغتين منذ البداية حول احتياجات السوق السعودي.
- القرار
- صممنا التطبيق بالعربية أولًا مع تدفقات RTL كاملة، وأطلقنا العربية والإنجليزية معًا.
- لماذا
- للعملاء في السعودية الذين يرون التسعير بالريال لكل قطعة ويتابعون الطلب خطوة بخطوة، كان يجب أن يكون RTL جزءًا أصيلًا من التخطيطات، لا إضافة لاحقة.
ثلاثة أسطح على Backend وهوية مشتركين
- سياق العمل
- كان يمكن تعريف تطبيق العملاء ولوحة التشغيل والموقع التسويقي وبناء كل منها كنظام مستقل.
- القرار
- حددنا ثلاثة منتجات تشترك في Laravel API واحد فوق MySQL ونظام هوية واحد، وبنيناها بالتوازي.
- لماذا
- تحافظ قاعدة البيانات العلائقية كمصدر واحد للحقيقة على اتساق الطلبات والسائقين والتسعير والفواتير بين التطبيق ولوحة التحكم، ووجود واجهة API واحدة يعني كتابة قاعدة التسعير أو الحالة مرة واحدة بدل إعادة تنفيذها في كل تطبيق.
لوحة التحكم كلوحة إدارة للتطبيق، لا كشاشة تقارير
- سياق العمل
- خدمة الغسيل تتغير باستمرار: أسعار لكل قطعة، وخدمات جديدة، ومناطق تغطية، وعروض، وسائقون يدخلون ويخرجون. لو ظلت هذه العناصر داخل الكود أو قاعدة البيانات وحدها، يتحول كل تغيير تجاري عادي إلى طلب تطوير، وإلى تحديث جديد على المتجر لأي شيء يعرضه التطبيق.
- القرار
- بنينا لوحة React كسطح إدارة للتطبيق نفسه، تُدار منها قائمة الخدمات والتسعير بالريال لكل قطعة والعروض ومناطق التغطية والسائقون وحالات الطلب وحسابات العملاء والإشعارات وصلاحيات الموظفين، عبر نفس Laravel API الذي يستهلكه التطبيق.
- لماذا
- يمتلك الفريق منتجه اليومي من دون وجودنا في المسار: تغيير سعر أو إضافة خدمة أو إيقاف منطقة تغطية ينعكس في تطبيق العميل مباشرة، ويعمل فريق التشغيل في مكان واحد بدل التنقل بين غرفة تحكم وقناة دعم.
Moyasar بدل بوابة دفع عالمية
- سياق العمل
- يتوقع العميل في السعودية وجود mada وApple Pay عند الدفع، بينما احتاج التشغيل إلى ربط التحصيل والاسترجاع بسجل الطلب نفسه.
- القرار
- دمجنا Moyasar كبوابة دفع، مع إبقاء حالة الدفع داخل Laravel API ومطابقتها مع الطلب عبر Webhooks.
- لماذا
- تغطي البوابة المحلية وسائل الدفع المستخدمة فعليًا في هذا السوق، وإبقاء حالة الدفع في الـ Backend يجعل أي استرجاع أو عملية فاشلة ظاهرة في لوحة التحكم بجوار الطلب المرتبط بها.
طبقة تتبع واحدة بدل تحليلات لكل سطح
- سياق العمل
- كان يمكن ربط التطبيق ولوحة التحكم والموقع كلٌّ بأداة تحليلات خاصة به، ما يترك ثلاثة تعريفات لنفس المسار.
- القرار
- أرسلنا الأحداث عبر Segment كطبقة تتبع واحدة، مع Mixpanel كوجهة لتحليلات المنتج، وAuthentica لرموز التحقق ورسائل الطلب.
- لماذا
- يحافظ مخطط أحداث موحّد عبر الأسطح الثلاثة على قابلية مقارنة مسار الطلب، كما أن المرور عبر Segment يجعل إضافة أداة أو استبدالها لاحقًا تغييرًا في الإعداد لا مشروع توثيق جديدًا.
04 / المنتج أثناء الاستخدام
ما تم بناؤه
واجهات حقيقية عبر تجربة العميل والتشغيل.
05 / كيف تم بناؤه؟
قرارات هندسية
تطبيق Flutter بقاعدة مشتركة لـ iOS وAndroid، مع دعم RTL كامل وتدفق طلب سريع يغطي الغسيل والكوي والتنظيف الجاف للملابس والسجاد والألحفة.
تتبع مباشر للطلب خطوة بخطوة، من الاستلام إلى التوصيل، على خريطة محدثة داخل التطبيق.
لوحة تحكم بـ React 19 تدير تطبيق الموبايل كاملًا: قائمة الخدمات والتسعير بالريال لكل قطعة، والعروض، ومناطق التغطية، وحسابات العملاء، وبيانات السائقين وإسنادهم، وحالات الطلب، وإرسال الإشعارات — عبر نفس Laravel API الذي يستهلكه التطبيق، فيظهر أي تغيير داخل التطبيق من دون إصدار جديد.
التشغيل اليومي داخل اللوحة نفسها: لوحة طلبات بالسحب والإفلات، وتتبع السائقين على Google Maps، وتحليلات ApexCharts، وتوليد فواتير PDF بضغطة واحدة، وصلاحيات تفصل بين المدير وفريق التشغيل.
موقع تسويقي ثنائي اللغة على Next.js ينقل الهوية البصرية نفسها إلى الويب.
Laravel API فوق MySQL كمصدر مشترك للحقيقة للطلبات والخدمات والتسعير لكل قطعة والسائقين والفواتير، تستهلكه الأسطح الثلاثة التي بُنيت بالتوازي خلال مدة المشروع البالغة 16 أسبوعًا.
مدفوعات Moyasar عبر Laravel API مع معالجة Webhooks، بحيث تبقى حالة الدفع والاسترجاع والتسوية مرتبطة بالطلب الخاص بها.
Authentica لتسجيل الدخول برمز تحقق على رقم الجوال ورسائل حالة الطلب، مع Firebase Cloud Messaging للإشعارات داخل التطبيق عند الاستلام والتوصيل.
Segment كطبقة تتبع واحدة على العميل والخادم عبر التطبيق ولوحة التحكم والموقع، مع Mixpanel كوجهة لتحليلات مسار الطلب.
06 / ما الذي تغيّر؟
النتيجة التي تم تسليمها
صدر التطبيق على App Store وGoogle Play من قاعدة كود واحدة، ويحمل تقييم 4.9/5 على App Store، ويتيح للعميل بدء الطلب من خلال تدفق مختصر.
تم تسليم ثلاثة أسطح خلال 16 أسبوعًا: التطبيق على iOS وAndroid، ولوحة التحكم، والموقع التسويقي — بالعربية والإنجليزية.
تدير Laundry Heroes التطبيق نفسه من لوحة واحدة: الخدمات، والتسعير لكل قطعة، والعروض، والتغطية، والعملاء، والسائقون، والطلبات، وحالة الدفع.
التغييرات التجارية المعتادة، مثل خدمة جديدة أو تحديث سعر، تصل إلى العملاء من لوحة التحكم، بلا دورة تطوير أو إصدار جديد على المتجر.
أتاح الدفع داخل التطبيق عبر Moyasar بديلًا عن تسوية كل طلب نقدًا أو بتحويل عند الباب.
نقلت المنظومة رحلة الطلب والدفع والتشغيل إلى تجربة رقمية موحّدة، بهوية تعكس مستوى الخدمة عبر جميع نقاط التواصل.
“فريق واحد سلّم التطبيق على المتجرين، والـ dashboard اللي بنشغّل منه المغسلة، والموقع — نفس البراند ونفس الجودة في كل حتة.”
هل تواجه تحديًا مشابهًا في منتجك؟
ابدأ بالمشكلة. يمكننا تحديد المنتج الذي تحتاجه ومسار عملي للوصول إلى الإطلاق.