AutoMind
منصة خدمات سيارات عند الطلب في الإمارات، مبنية كأربعة أسطح مترابطة: تطبيق واحد يحمل دور العميل ودور الفني، ولوحة تشغيل، وموقع ثنائي اللغة — فوق Laravel API واحد، مع تقارير فحص يكتبها الذكاء الاصطناعي، وتوزيع طلبات بحسب نطاق التغطية، ودفع بالبطاقة بالدرهم.
- الدور
- قيادة تقنية · معمارية المنصة · تسليم مع فريق DevSparks
- الخدمات
- معمارية المنصة والبيانات · API بـ Laravel 12 وMySQL · تطبيق Expo للعملاء والفنيين · لوحة تشغيل بـ React 19 · موقع ثنائي اللغة بـ Next.js 16 · منظومة الفحص بالذكاء الاصطناعي · مدفوعات البطاقات عبر AFS/OPPWA · توزيع جغرافي للطلبات وإشعارات · نظام تصميم عربي أولًا بـ RTL
- التقنيات
- Laravel 12 · MySQL · Expo SDK 54 · React Native · React 19 · Next.js 16 · TypeScript · TanStack Query · Redux Toolkit · NativeWind · Google Gemini · Groq · AFS / OPPWA · Firebase FCM · Google Maps
- العميل
- AutoMind
- المجال
- خدمات السيارات
- المدة الزمنية
- 26 أسبوعًا · 2026
01 / سياق العمل
المشكلة المطلوب حلّها
وعد AutoMind هو أن يذهب الفني المعتمد إلى العميل بدل أن تذهب السيارة إلى الورشة. هذا الوعد لا يستقيم إلا إذا بقيت أربعة أشياء متسقة: ما يحجزه العميل، وما ينفّذه الفني فعلًا أمام باب البيت، وما يراه المكتب، وما تقوله الأرقام. احتاج المنتج إلى بنائها جميعًا كنظام واحد ثنائي اللغة بالدرهم الإماراتي، لا كتطبيق عملاء تقف خلفه أوراق ورشة.
AutoMind منصة خدمات سيارات تعمل في دبي وأبوظبي والشارقة: يذهب الفني المعتمد إلى العميل في البيت أو العمل أو على الطريق، للصيانة والفحص والغسيل والبطارية والمساعدة الطارئة. سلّمناها كأربعة أسطح فوق Laravel API واحد وقاعدة MySQL واحدة — تطبيق Expo ثنائي اللغة يحمل دور العميل ودور الفني معًا، ولوحة تحكم React 19 تُدار منها العمليات، وموقع Next.js 16 للتعريف والحجز — إضافة إلى منظومة الفحص بالذكاء الاصطناعي التي تحوّل قائمة فحص الفني إلى تقرير مكتوب عن السيارة.
02 / من النطاق إلى الإطلاق
كيف تحرّك العمل؟
أصبح المنتج أوضح عبر قرارات محددة ونسخ عاملة وملاحظات مستمرة، لا عبر انتظار كشف نهائي طويل.
07 خطوات
خطوة 01
بدأنا من العمل نفسه لا من الشاشات: تتبّعنا طلبًا واحدًا من حجز العميل إلى التوزيع، ثم عمل الفني في الموقع، فالإنهاء، فالدفع، وصولًا إلى وصول المال فعليًا إلى الشركة — واستخدمنا هذا المسار لتحديد ما يجب أن يعيش في الـ API بدل أن يعيش داخل أي واجهة.
خطوة 02
نمذجنا التشغيل كاملًا في MySQL — الطلبات وبنودها، وقوائم الخدمات والباقات، والفحوصات وصورها، والفنيون بمستنداتهم وحضورهم، والمناطق، وأكواد الخصم، والاشتراكات، ونقاط الولاء، والمخزون، والمصروفات، والرواتب، والمدفوعات — وأتحناها عبر Laravel API واحد مع فحص للأدوار والصلاحيات على كل مسار.
خطوة 03
بنينا المنتج على الموبايل كقاعدة Expo واحدة بمجموعتَي مسارات لكل دور، لتشترك تجربة العميل وتجربة الفني في نظام التصميم وعميل الـ API والترجمة وطبقة الإشعارات، بدل أن يتباعدا كمشروعين منفصلين.
خطوة 04
صممنا باللغتين من الشاشة الأولى: العربية والإنجليزية نِدّان في التطبيق ولوحة التحكم والموقع، مع RTL أصيل عبر I18nManager على الموبايل وصفحات موجّهة باللغة على الويب.
خطوة 05
حدّدنا لوحة التحكم كغرفة تشغيل يُدار منها العمل فعلًا — الطلبات بأنواعها، والفنيون ومناطق تغطيتهم، وقائمة الخدمات والتسعير، وأكواد الخصم، والشكاوى، والتقييمات، والموظفون والرواتب، والمصروفات، وحملات الإشعارات — لا كطبقة تقارير بجانب المنتج.
خطوة 06
أضفنا الذكاء الاصطناعي فوق نظام يعمل من دونه أصلًا: درجة الفحص حساب رقمي على قائمة الفحص، والتقرير المكتوب نداء نموذجَين على طابور يمكن أن يفشل أو يُعاد تشغيله أو يُعاد توليده من دون أن يوقف الفني.
خطوة 07
أدخلنا الجانب المالي أخيرًا وبقصد: دفع بالبطاقة عبر AFS/OPPWA تُسوّى حالته عبر Webhook، ونسبة الضريبة والخصم مُثبّتتان على كل طلب، والنقد الذي يحصّله الفني يُتابَع كرصيد محفظة تستطيع الشركة تسويته.
03 / القرارات التي شكّلت المنتج
قرارات المنتج الأساسية
API واحد وقاعدة بيانات واحدة خلف الأسطح الأربعة
- سياق العمل
- كان يمكن تعريف تطبيق العميل وتطبيق الفني ولوحة التحكم والموقع كأربعة مشاريع، لكل منها جزؤه من الـ Backend. وعندها تُكتب قواعد التسعير والحالات والصلاحيات أربع مرات.
- القرار
- بنينا Laravel API واحدًا فوق مخطط MySQL واحد كمصدر للحقيقة، وجعلنا كل سطح عميلًا له — بما في ذلك الموقع، الذي يقرأ الخدمات والأسعار الحية من نفس المسارات التي يستهلكها التطبيق.
- لماذا
- الطلب الواحد يمرّ بالعميل والفني والأدمن خلال الساعة نفسها. نموذج واحد مرجعي يعني أن تغيير حالة أو سعر أو صلاحية يُعرّف مرة واحدة، وأن أي سطح جديد يصبح عميلًا إضافيًا لا مصدر حقيقة جديدًا.
دوران في قاعدة كود واحدة، لا تطبيقان منفصلان
- سياق العمل
- يحتاج العميل والفني إلى شاشات مختلفة: الأول يحجز ويتابع، والثاني يقبل المهام ويسجّل حضوره ويحتسب القطع ويحصّل النقد. الطريق البديهي هو إطلاق تطبيقين.
- القرار
- بنينا قاعدة Expo واحدة بمجموعات مسارات محصورة بالدور، مع نظام تصميم وعميل API مشتركين، وشاشة بداية توجّه المستخدم إلى مسار العميل أو الفني بحسب دوره.
- لماذا
- المشترك بين الدورين أكبر بكثير من المختلف — الدخول، والترجمة، والثيم، والإشعارات، ونماذج الطلبات، والخرائط. قاعدة واحدة تُبقي هذا متسقًا بحكم البناء، فيُصلَح خطأ في RTL أو تجديد التوكن مرة واحدة، ويبقى عبء الإصدار والمتاجر عند تطبيق واحد بدل اثنين.
ثنائية اللغة وRTL كخاصية للمنصة، لا كشاشة
- سياق العمل
- يمكن بناء منتج إماراتي بالإنجليزية ثم ترجمته لاحقًا. وبهذه الطريقة تصل العربية كتخطيطات معكوسة تعمل غالبًا، ومحتوى يتطابق غالبًا، وBackend لا يتحدث سوى لغة واحدة.
- القرار
- جعلنا اللغتين من الدرجة الأولى من الطرف إلى الطرف: سجلات خدمات وباقات ومحتوى قابلة للترجمة في قاعدة البيانات، واحترام `Accept-Language` في كل نداء API، وRTL أصيل على الموبايل، وصفحات موجّهة باللغة مع hreflang على الويب.
- لماذا
- التجربة العربية يجب أن تكون المنتج نفسه لا نسخة معكوسة عنه — أي أن يكون اسم الخدمة والتقرير والإشعار عربيًا من المصدر، لا مترجمًا داخل الواجهة حيث يستفيد منه سطح واحد فقط.
الدرجة فورًا، والتقرير على طابور
- سياق العمل
- يقرأ الفحص الذكي قائمة فحص من أكثر من 200 نقطة وعشرات الصور التي يلتقطها الفني. تنفيذ ذلك داخل الطلب نفسه يعني انتظار الفني لنداء نموذج وهو واقف أمام العميل، ويعني أن ردًا سيئًا واحدًا يمنع إغلاق المهمة.
- القرار
- فصلنا الأمرين: الدرجة والتقديرات تُحسب رقميًا من قائمة الفحص لحظة إغلاقها، بينما يعمل التقرير المكتوب كمهمة على طابور من مرحلتين — نموذج رؤية يقرأ الصور على دفعات محدودة، ثم نموذج نصي يكتب التقرير مستندًا إلى قائمة الفحص وتلك الملاحظات.
- لماذا
- الرقم الذي يهم العميل يظهر فورًا ولا يعتمد على توفّر نموذج، بينما يأخذ التقرير السردي وقته، ويمكن أن تفشل دفعة منه وحدها، أو يعيد الموظفون توليده، من دون أن يقف أحد في انتظاره.
توزيع بحسب منطقة مرسومة، لا بثّ للجميع
- سياق العمل
- النسخة الأبسط من التوزيع تُشعر كل فني متاح وتترك السباق بينهم. في خدمة يقود فيها الفني إلى العميل، هذا يدفع المهام إلى من لا يستطيع الوصول، ويُضيع بصمت الطلبات التي لا يغطّيها أحد.
- القرار
- نمذجنا مناطق الخدمة كمضلعات تُرسم على الخريطة من لوحة التحكم، وربطنا كل فني بمنطقته، ووجّهنا إشعارات الطلب إلى الفنيين الذين تحتوي مناطقهم إحداثيات الطلب فقط — مع تعليم أي طلب خارج التغطية كـ«خارج نطاق العمل» ليراه الأدمن.
- لماذا
- التوزيع على أساس الجغرافيا لا التوافر يُبقي الإشعارات ذات معنى للفنيين، ويحوّل فجوة التغطية إلى حقيقة تشغيلية ظاهرة بدل طلب لا يلتقطه أحد أبدًا.
النقد في الميدان صار محفظة مرئية
- سياق العمل
- حين يدفع العميل نقدًا، يكون المال في جيب الفني لا في حساب الشركة. ومن دون سجل لذلك، يبقى الطلب المكتمل غير مدفوع إلى الأبد، ولا أحد يستطيع الإجابة عن سؤال: كم من أموال الشركة في الميدان اليوم؟
- القرار
- نمذجنا التحصيل النقدي كمحفظة للفني: التحصيل يُسجّل على الطلب، والرصيد هو ما على الفني، والتسليمات تُعلن ثم يؤكدها الأدمن، والتحصيل الجزئي مدعوم بدل تجاهله.
- لماذا
- هذا يُغلق الحلقة بين انتهاء الطلب ووصول المال إلى الشركة، ويجعل رصيد الميدان رقمًا في لوحة التحكم بدل شيء يُعاد تركيبه من الإيصالات في آخر الأسبوع.
قواعد المال مثبّتة على الطلب ومسوّاة من الخادم
- سياق العمل
- الأسعار وأكواد الخصم ونسبة الضريبة كلها تتغير مع الوقت، وقد تنجح عملية الدفع بالبطاقة بعد أن يكون التطبيق قد أُغلق. إعادة حساب الإجماليات أو الوثوق برد العميل كلاهما يفسد السجل بهدوء.
- القرار
- نثبّت السعر والخصم ونسبة الضريبة على كل طلب لحظة إنشائه، ونُبقي كل إجمالي على الخادم، ونسوّي مدفوعات البطاقة من Webhook الخاص بـ AFS/OPPWA — بينما لا يحمل العميل سوى معرّف دفع عام ويستعلم عن النتيجة.
- لماذا
- يظل الطلب قابلًا لإعادة الإنتاج طوال بقائه مخزّنًا، ولا يستطيع تغيير نسبة الضريبة أن يعيد كتابة فواتير الشهر الماضي، وتصبح حالة الدفع قرارًا بين البوابة والخادم لا بين الهاتف وما استطاع إرساله قبل انقطاع الشبكة.
04 / المنتج أثناء الاستخدام
ما تم بناؤه
واجهات حقيقية عبر تجربة العميل والتشغيل.
05 / كيف تم بناؤه؟
قرارات هندسية
Laravel 12 على PHP 8.2 فوق MySQL، مع Sanctum للتوكنات، وspatie/laravel-permission للأدوار والصلاحيات، وspatie/laravel-translatable لمحتوى العربية والإنجليزية، وspatie/laravel-activitylog كسجل تدقيق لإجراءات الأدمن.
قاعدة Expo SDK 54 / React Native واحدة بمسارات expo-router لكل دور، وTanStack Query لبيانات الخادم، وZustand للدخول والتهيئة، وNativeWind فوق ثيم موحّد، وبوابة بصمة عند التشغيل البارد.
مسارات العميل: معالج حجز من أربع خطوات، وسيارات ومواقع محفوظة، وتتبع مباشر للطلب، ودفع داخل التطبيق، وتقييمات، ونقاط ولاء تُستبدل بأكواد خصم ذات استخدام واحد، واشتراكات دورية تُنشئ الطلبات تلقائيًا، ومساعد ذكي يعرض الأسعار الحية.
مسارات الفني داخل التطبيق نفسه: المهام المتاحة والقريبة، والقبول والإنهاء مع محتوى العمل لكل بند وصوره، وتسجيل حضور وانصراف يومي، ومخزون السيارة مع تسجيل الاستهلاك، والمصروفات بإيصالاتها، ومحفظة نقدية بتسليماتها، والتقييمات، وتقارير الدخل.
منظومة الفحص بالذكاء الاصطناعي داخل Laravel: نموذج رؤية يقرأ صور الفحص على دفعات محدودة، كل صورة موسومة بنقطة الفحص التابعة لها، ثم نموذج نصي يكتب التقرير المهيكل من قائمة الفحص وتلك الملاحظات — على طابور، قابل للإعادة، ويعيد الموظفون توليده، مع حساب تكلفة التوكنات لكل تقرير.
كل فحص مكتمل يحمل UUID، فيُفتح التقرير عبر رابط عام من دون حساب — وهو الشيء الذي يحتاجه المشتري أو البائع فعلًا.
لوحة تحكم React 19 + Vite تغطي الطلبات بأنواعها (عادي، فحص ذكي، ما قبل الشراء، طوارئ)، والفنيين، ومناطق التغطية المرسومة على Google Maps، والخدمات والباقات، وأكواد الخصم، والعملاء، والشكاوى، والتقييمات، والموظفين والرواتب، والمصروفات، والإشعارات، والتقارير، وأدوار الأدمن بصلاحيات مفصّلة.
موقع Next.js 16 ثنائي اللغة على next-intl، بصفحات مُخدَّمة من الخادم لكل لغة مع hreflang، وأسعار خدمات وباقات حية من نفس الـ API، ومساري الحجز والطوارئ، ومساعد ذكي عبر Groq خلف مسار على الخادم.
Firebase Cloud Messaging عبر الواجهات الثلاث لانتقالات حالة الطلب، مع توجيه الإشعارات بحسب الدور ومنطقة التغطية بدل بثّها للجميع.
06 / ما الذي تغيّر؟
النتيجة التي تم تسليمها
تعمل AutoMind كمنصة واحدة: تطبيق العميل، وتطبيق الفني، ولوحة التشغيل، والموقع، جميعها تقرأ وتكتب نفس الطلبات والأسعار والصلاحيات.
يحجز العميل ويتابع خطوة بخطوة ويدفع بالبطاقة أو نقدًا ويقيّم الخدمة، ضمن مسار واحد ثنائي اللغة بالدرهم، في دبي وأبوظبي والشارقة.
يعمل الفني يومه كاملًا داخل التطبيق — المهام، والحضور، والقطع المستهلكة، والمصروفات، والنقد المحصّل — بدل إبلاغها عبر المكالمات والرسائل.
يعيد الفحص الذكي درجةً لحظة إغلاق قائمة الفحص، وتقريرًا مكتوبًا بعدها بقليل، قابلًا للمشاركة برابط من دون حساب.
النقد المحصّل في الميدان، وتسويات البطاقات، والضريبة، وخصومات الأكواد، واستبدال نقاط الولاء، تتطابق كلها داخل سجل الطلب نفسه، فترى الشركة ما لها بوضوح.
التغييرات التجارية المعتادة — سعر، أو خدمة أو باقة جديدة، أو منطقة تغطية، أو كود خصم، أو حملة إشعارات — تُنفَّذ من لوحة التحكم وتصل إلى العملاء بلا إصدار جديد.
هل تواجه تحديًا مشابهًا في منتجك؟
ابدأ بالمشكلة. يمكننا تحديد المنتج الذي تحتاجه ومسار عملي للوصول إلى الإطلاق.