كم تكلفة عمل تطبيق مثل هنقرستيشن أو مرسول أو طلبات؟ ما الذي ستبنيه فعلًا

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

ماذا ستبني فعلًا عندما تطلب «تطبيقًا مثل هنقرستيشن»؟

ستبني أربعة منتجات فوق نظام خلفي (Backend) واحد يعمل لحظيًا: تطبيقًا للعميل، وتطبيقًا للمندوب، وتطبيقًا للتاجر، ولوحة عمليات. الشاشات هي ما يراه الناس، أما المنطق الذي ينقل الطلب الواحد بين الأطراف الثلاثة وفريقك فهو معظم العمل.

هذا هو الحد الأدنى الذي أتوقع رؤيته في أي نطاق عمل جاد:

• تطبيق العميل: تصفح المتاجر والقوائم، والسلة، والدفع، والتتبع المباشر، وسجل الطلبات، والتقييم، والمساعدة.
• تطبيق المندوب: التسجيل والتحقق من الهوية، وحالة الاتصال، وقبول العروض أو رفضها، والملاحة، وإثبات التسليم، والأرباح.
• تطبيق التاجر: استقبال الطلبات وقبولها أو رفضها، ووقت التحضير، وإيقاف الأصناف النافدة، وتعديل القائمة، وتقارير المستحقات.
• لوحة العمليات: لوحة حية للطلبات، وإعادة الإسناد يدويًا، والاسترداد، وتسجيل التجار والمناديب، والمناطق ورسوم التوصيل، والعروض الترويجية، وسجل التدقيق.
• النظام الخلفي المشترك: توزيع الطلبات وإسنادها، بما في ذلك ما يحدث حين لا يقبل الطلبَ أي مندوب؛ والتتبع المباشر والخرائط؛ والمدفوعات عبر بوابة دفع محلية (مدى وApple Pay وSTC Pay والبطاقات) مع الاسترداد والتسوية مع التجار ومستحقات المناديب والعمولة؛ والإشعارات، والتقييم في الاتجاهين، وتذاكر الدعم المرتبطة بالطلب.

ونموذج العمل يعيد توزيع الثقل بين هذه الأجزاء؛ فمنصة تجمع المطاعم، وخدمة بقالة، ونموذج «وصّل لي أي شيء» القائم على المناديب، يضع كل منها التعقيد في مكان مختلف. لذلك يسبق حسمُ النموذج أيَّ تقدير للتكلفة.

ما الأجزاء التي تصنع التكلفة والمخاطرة؟

توزيع الطلبات، والمدفوعات، والتتبع المباشر، ولوحة العمليات تصنع معظم التكلفة وكل المخاطرة تقريبًا. شاشات الدخول والقوائم والدفع يمكن توقعها، أما كل ما ينسّق بين ثلاثة أطراف في الوقت الفعلي فلا.

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

لماذا تتضارب الأسعار المنشورة إلى هذا الحد؟

لأن كل شركة برمجة تطبيقات تسعّر نطاقًا مختلفًا، والرقم المنشور أداة تسويق لا تقدير. بل إن أدلة المورد الواحد يناقض بعضها بعضًا.

هذه أرقام الموردين لا أرقامي، فأنا لا أنشر أسعارًا. والتفاوت نفسه هو الدرس. نشرت Creole Studios دليليها عن السوق السعودي بفارق ثلاثة أسابيع، ومع ذلك لا تتطابق أرقامهما الرئيسية: من 150,000 إلى أكثر من 500,000 ريال لتطبيق توصيل طعام كامل في أحدهما، ومن 75,000 إلى أكثر من 280,000 ريال لتطبيق توصيل حسب الطلب، بما فيه النسخة الأولية، في الآخر. والأسباب ليست غامضة:

• «النسخة الأولية» تعني أشياء مختلفة. تصف TekRevol فئة النسخة الأولية لديها بأنها تطبيق للعميل ولوحة إدارة أساسية ومدينة واحدة ومنصة واحدة: لا تطبيق للمندوب ولا للتاجر، أي أنها ليست سوقًا ثلاثي الأطراف بعد.
• عدد الأجزاء والمنصات يختلف. iOS أو أندرويد أو كلاهما، وتطبيق للتاجر على جهاز لوحي أو لوحة ويب، وتطبيق مناديب خاص أو أسطول متعاقد معه.
• نموذج العمل يختلف. الأسطول المملوك يحتاج توزيعًا وورديات ومستحقات، والسوق القائم على العمولة يحتاج تقسيم المدفوعات وصرف المستحقات.
• بعض التكاليف خارج الرقم الأول. مرحلة الاستكشاف وتحليل المتطلبات، واختبار الجودة، والبنية التحتية، واستهلاك الخرائط والرسائل النصية، ومراجعات متاجر التطبيقات، ولوحة العمليات كثيرًا ما تغيب عن أول رقم تراه.

هل يكفي سكربت جاهز أو حل علامة بيضاء (White-label)؟

حل العلامة البيضاء قد يختبر الطلب في منطقة صغيرة، لكنه لن يحمل تشغيلًا حقيقيًا طويلًا. أنت تستأجر منتج غيرك بترخيص، والأجزاء التي تجعل التوصيل يعمل في السعودية هي بالضبط الأجزاء التي لا تملك تغييرها.

حتى TekRevol، التي تسعّر حلول العلامة البيضاء بين 12,000 و40,000 دولار، تقدمها وسيلةً للتحقق من السوق، وتحذّر من أنك لا تستطيع إطلاق ميزة تميزك على خارطة طريق يملكها غيرك. ومن واقع خبرتي، هذه هي المواضع التي تنكسر فيها السكربتات الجاهزة (Clone scripts) حين تبدأ الطلبات الحقيقية:

• التوزيع ساذج. قاعدة «أقرب مندوب متفرغ» تتجاهل وقت التحضير، فيصطف المناديب عند المطابخ بينما تنتظر طلبات أخرى.
• المدفوعات مصممة لسوق آخر. وسائل الدفع المحلية عبر بوابة محلية، والاسترداد الجزئي، والتسوية مع التجار تُضاف لاحقًا، إن وُجدت أصلًا.
• العربية فكرة لاحقة. الواجهات من اليمين إلى اليسار، والبحث بالعربية، وأسماء الأصناف التي تخلط العربية بالإنجليزية تنكسر بطرق لا يكشفها العرض التجريبي.
• لم يراجع أحد الكود. أنت على وشك أن تضع عناوين العملاء وأرقام هواتفهم في برنامج لم تفحص أمانه.
• الجهة التنظيمية أسرع من المورد. حين تتغير قواعد التحقق من المناديب تحتاج التعديل هذا الربع، لا وفق جدول إصدارات المورد.

وإن بدأت بحل جاهز فحدد له تاريخ انتهاء، واقرأ الترخيص لتعرف من يملك الكود وكيف تُصدَّر البيانات، واحفظ سجلاتك بصيغة تستطيع أخذها معك.

ماذا تتضمن النسخة الأولية لمدينة واحدة، وما الذي يؤجَّل؟

مدينة واحدة، وقطاع واحد، وبضعة أحياء متجاورة، وأربعة تطبيقات في حدها الأدنى، وتدخّل يدوي ممكن في كل ما لم يُؤتمت بعد. لا تؤتمت مهمة إلا بعد أن يصبح أداؤها باليد مؤلمًا.

مثال افتراضي: مؤسس في جدة يبدأ بالمطاعم وحدها، في عدد قليل من الأحياء المتجاورة، مع بضع عشرات من المطابخ الشريكة. سأحصر نطاق نسخته الأولية فيما يلي، ولا شيء غيره:

• تطبيق عميل واحد متعدد المنصات يعمل على iOS وأندرويد، بالعربية أولًا ثم الإنجليزية.
• تطبيق مندوب فيه التحقق من الهوية، وحالة الاتصال، وقبول العروض، وتحويل الملاحة إلى خرائط Google أو Apple، وإثبات التسليم بالصورة.
• تطبيق ويب للتاجر يعمل على جهاز لوحي غير مكلف: قبول الطلب، وتحديد وقت التحضير، وإيقاف الأصناف النافدة.
• لوحة عمليات فيها لوحة حية للطلبات، وإسناد وإعادة إسناد يدويان، واسترداد يتطلب اختيار سبب محدد وموافقة شخص ثانٍ، وسجل تدقيق.
• توزيع قائم على قواعد: أقرب مندوب متفرغ مع مراعاة وقت التحضير، ومهلة زمنية، ثم تحويل الطلب إلى موظف توزيع.
• بوابة دفع واحدة تغطي مدى وApple Pay والبطاقات، وقرار مدروس بشأن الدفع عند الاستلام، لأن النقد ينشئ أرصدة لدى المناديب يجب مطابقتها كل يوم.
• إشعارات فورية، ورموز تحقق لمرة واحدة (OTP) عبر الرسائل النصية، وتقييمات بسيطة، وتذاكر دعم مرتبطة بالطلب.
• سجلات تشغيل ومراقبة من الإصدار الأول، ليجيب أي فرد في الفريق خلال دقائق عن سؤال: ماذا حدث لهذا الطلب؟

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

ما الأنظمة واللوائح السعودية التي تغيّر المعمارية؟

نظام حماية البيانات الشخصية (PDPL) يحدد كيف تخزّن البيانات الشخصية وتحتفظ بها وتنقلها، والهيئة العامة للنقل (TGA) تحدد جزءًا كبيرًا من جانب المناديب. ما يلي إرشاد هندسي وليس استشارة قانونية؛ راجع الموقف النظامي مع محامٍ سعودي. وقائمة التحقق الهندسية الكاملة في دليل نظام حماية البيانات الشخصية للتطبيقات.

• النظام يصل إليك في الخارج. تنص المادة الثانية على تطبيقه على أي عملية معالجة لبيانات شخصية تتعلق بالأفراد تتم في المملكة، بما في ذلك معالجة البيانات الشخصية المتعلقة بالأفراد المقيمين في المملكة من أي جهة خارجها؛ فالاستضافة أو فريق التطوير خارج المملكة لا يُخرجانك من نطاقه.
• الوصول عن بعد يُحتسب. الدليل الاسترشادي لتقويم مخاطر نقل البيانات الشخصية إلى خارج المملكة، الصادر عن الهيئة السعودية للبيانات والذكاء الاصطناعي (سدايا) في فبراير 2025، والذي تصفه بأنه ليس وثيقة نظامية ملزمة، يذكر «الوصول عن بعد» ضمن صور النقل إلى خارج المملكة. فإن كان مهندسو المورد يستطيعون الاستعلام من بيانات الإنتاج من الخارج، فاعتمد صلاحيات في حدها الأدنى، وبيانات مقنّعة خارج بيئة الإنتاج، وسجلات وصول.
• مهلة الـ72 ساعة. تُلزم اللائحة التنفيذية جهة التحكم بإشعار الجهة المختصة خلال مدة لا تتجاوز 72 ساعة من علمها بحادثة تسرّب من شأنها الإضرار بالبيانات أو بأصحابها (المادة الرابعة والعشرون). ولن تفي بهذه المهلة دون سجلات تبيّن ما الذي جرى الوصول إليه ومتى.
• التتبع والإسناد الآلي يستدعيان تقويم الأثر. تذكر المادة الخامسة والعشرون، ضمن الحالات التي قد تستوجب تقويمًا مكتوبًا للأثر، عمليات المعالجة التي تتطلب بطبيعتها مراقبة مستمرة لأصحاب البيانات، واتخاذ قرارات مبنية على المعالجة الآلية. وتتبع المناديب لحظيًا والتوزيع الآلي قريبان من الحالتين.
• هوية المندوب ميزة في المنتج. ألزمت قرارات الهيئة العامة للنقل في يناير 2024 الشركات العاملة في توصيل الطلبات بتطبيق خاصية التحقق من الوجه لسائقيها، وقصرت عمل غير السعوديين على شركات النقل الخفيف، بحسب وكالة الأنباء السعودية (واس). لذلك يحتاج نموذج بيانات المندوب إلى الجهة التي يعمل لديها، لا إلى رقم هاتفه فقط.
• الترخيص والربط متطلبات وليسا أوراقًا. نشرت صحيفة عكاظ في سبتمبر 2025 أن اللائحة التنفيذية الجديدة لنشاط توصيل الطلبات تحظر ممارسة النشاط دون ترخيص، وتُلزم الشركات الراغبة في الترخيص بربط أنظمتها التقنية بالمنصة الإلكترونية للهيئة، وتشترط التحقق عبر منصة «نفاذ» عند تسجيل السائقين السعوديين، وتمنع إسناد أكثر من طلبية لسائق الدراجة في الوقت نفسه، وتوجب إطلاع العميل على تفاصيل السعر وآلية الإلغاء قبل تأكيد الطلب. كل بند منها مهمة في قائمة العمل الهندسي؛ راجع النص الرسمي الساري مع الهيئة قبل تثبيت النطاق.

كيف تحصل على تقدير يمكن الدفاع عنه بدل مدى سعري واسع؟

اكتب النطاق قبل أن يسعّر أحد: وثيقة متطلبات تحسم النموذج والمسارات وحالات الطلب والمتطلبات غير الوظيفية. ثم قارن العروض بهذه الوثيقة الواحدة، لا بما تقوله كل شركة برمجة عن نفسها.

1. اختر النموذج: منصة تجمع التجار مع مناديب شركاء، أو أسطول مملوك، أو توصيل حسب الطلب.
2. اكتب التطبيقات الأربعة، وحدد لكل منها ما يدخل الإصدار الأول وما يؤجَّل.
3. اكتب مخطط حالات الطلب، بما فيه الإلغاء والاسترداد الجزئي وغياب المناديب.
4. ضع أهدافًا قابلة للقياس: عدد الطلبات في ساعة الذروة، وتكرار تحديث موقع المندوب، والخطأ المقبول في وقت الوصول المتوقع، ونسبة جاهزية النظام.
5. سمِّ كل تكامل: بوابة الدفع، والخرائط، والرسائل النصية، ومنصة الهيئة العامة للنقل، و«نفاذ»، وأي نظام نقاط بيع لدى التجار.
6. حوّل البنود النظامية أعلاه إلى متطلبات، لكل منها مسؤول باسمه.
7. أرسل الوثيقة نفسها إلى شركتين أو ثلاث شركات برمجة لتسعيرها بندًا بندًا، واطلب من طرف لا يتنافس على المشروع مراجعة العروض بحثًا عن أجزاء مفقودة وافتراضات متفائلة.

كتبت عن إعداد هذه الوثيقة في دليل وثيقة متطلبات النظام (SRS)، وعن جانب العقد في قبل أن توقّع مع شركة برمجة. ومن يراجع العروض، شريكًا تقنيًا كان أو مراجعًا مستقلًا، فليتحقق أولًا من أن لوحة العمليات داخل السعر؛ فحين يبدو عرض تطبيق توصيل رخيصًا، تكون هي غالبًا الجزء الغائب.