تكلفة برمجة تطبيق موبايل بتتحدد على إيه؟

ابدأ من النسخة الأولى مش من السعر

سؤال «التطبيق هيتكلف كام؟» بيجيلي كتير قبل ما نتكلم عن اللي التطبيق هيعمله. السؤال مفهوم، بس لسه مالوش إجابة أمينة. تكلفة برمجة تطبيق موبايل هي في الأساس تكلفة مزاياه، زائد الحاجات اللي المستخدم مش بيشوفها: السيرفر ولوحة التحكم والنشر على المتاجر والاختبار.

عشان كده ممكن تلاقي عرضين سعر لـ «نفس التطبيق» بينهم فرق كبير. مطوّر تخيّل شاشة دخول وقايمة، وواحد تاني تخيّل 3 أنواع مستخدمين ودفع أونلاين وتتبع مباشر. هما ببساطة بيسعّروا تطبيقين مختلفين.

يبقى أول خطوة إنك تحدد النسخة الأولى لازم تعمل إيه يوم الإطلاق، وتكتب ده. المقال ده بيمشي على اللي بيكبّر القايمة دي أو بيصغّرها، وإزاي تحوّلها لعروض أسعار تقدر تقارنها.

أنواع المستخدمين: تطبيق واحد غالبًا بيبقى 4

نوع المستخدم يعني شخص ليه شاشاته وصلاحياته الخاصة. خد مثلًا تطبيق توصيل، اللي أغلب الناس بتوصفه إنه تطبيق واحد. غالبًا هيحتاج:

• جزء للعميل: يتصفح ويطلب ويدفع ويتابع الطلب ويقيّمه
• جزء للمندوب: يبدأ الشغل ويقبل الطلب ويمشي على الخريطة ويأكد التوصيل
• جزء للمحل أو المطعم: يستقبل الطلبات ويحدّث المنيو والمخزون
• لوحة تحكم للأدمن: يدير المستخدمين والطلبات والمرتجعات ومستحقات المناديب والتقارير

الشاشات والرحلات: عُدّ الرحلات مش الصفحات

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

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

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

السيرفر ولوحة التحكم: الجزء اللي مش باين

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

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

لو عندك ERP أو نظام كاشير أو موقع عنده API، التطبيق ممكن يتربط بيه بدل سيرفر جديد. ده بيوفّر كتير بشرط إن الـ API يكون موثّق وبيعمل اللي التطبيق محتاجه، فابعته بدري. وخدمات زي Firebase أو Supabase كمان بتختصر أجزاء متكررة زي تسجيل الدخول وتخزين الملفات.

الربط: الدفع والخرائط والـ SMS والإشعارات

كل خدمة خارجية بتزوّد إعداد واختبار، وغالبًا فاتورة شهرية. أشهرهم:

• الدفع: بوابة زي Paymob في مصر، أو Tap أو HyperPay أو Moyasar في الخليج، أو Stripe في أوروبا، محتاجة حساب تاجر واسترجاع فلوس وتعامل مع الدفع اللي بيفشل. أما المحتوى الرقمي والاشتراكات اللي بتتباع جوه التطبيق، فغالبًا لازم تمشي من نظام الشراء الداخلي بتاع Apple و Google، وده عليه عمولة.
• الخرائط: عرض خريطة حاجة بسيطة. البحث عن عنوان ومناطق التوصيل والطريق ومكان المندوب لحظة بلحظة، كل واحدة فيهم شغل زيادة، وخدمات الخرائط بتتحاسب على الاستخدام بعد الحد المجاني.
• الـ SMS وكود OTP: كل رسالة ليها تمن بيختلف من بلد لبلد. والإرسال باسم البراند بتاعك في السعودية أو الإمارات غالبًا محتاج تسجيل اسم المرسل، وده بياخد وقت.
• الإشعارات: Firebase Cloud Messaging مجاني، بس منطق مين يوصله إيه وإمتى، وشاشة في لوحة التحكم لإرسال الحملات، ده شغل حقيقي.
• الدخول بحساب Google أو Apple، والإيميلات، والتحليلات، وتقارير الأعطال، وشات الدعم: كل واحدة صغيرة، بس بيتجمّعوا.
• أنظمة الشحن أو المحاسبة أو الفاتورة الإلكترونية: دي بتعتمد على الـ API بتاع الطرف التاني، فهات التوثيق بتاعه قبل ما تطلب سعر.

التحديث اللحظي والشغل من غير نت

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

الشات ميزة شكلها صغير. رسايل نصية بين شخصين حاجة، لكن ضيف صور ورسايل صوتية وعلامة «اتقرت» وجروبات ومراجعة محتوى، تبقى مشروع لوحده.

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

العربي والإنجليزي واتجاه الشاشات من اليمين

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

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

نصيحتي: حتى لو هتنزل بلغة واحدة، اطلب إن التطبيق يتبني جاهز للغتين. إضافة الاتجاه من اليمين بعدين معناها نرجع على كل شاشة.

التصميم: شكل قياسي ولا تصميم مخصوص؟

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

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

iOS وأندرويد: كود Flutter واحد ولا تطبيقين Native؟

غالبًا هتحتاج توصل لمستخدمين الآيفون والأندرويد الاتنين. تطبيقين Native يعني كود بـ Swift لـ iOS وكود تاني بـ Kotlin لأندرويد، وغالبًا مطوّرين أو فريقين. كل ميزة بتتبني مرتين وتتجرّب مرتين، ولازم يفضلوا متطابقين طول عمر التطبيق.

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

الـ Native منطقي لتطبيقات معتمدة جدًا على مزايا لسه نازلة جديد في النظام، أو على تعامل عميق مع الهاردوير. لكن لأغلب تطبيقات الشغل، زي الحجوزات والتوصيل والمتاجر الإلكترونية والأنظمة الداخلية، كود Flutter واحد هو الطريقة الأعقل لصرف الميزانية.

حسابات المتاجر والمراجعة

النشر ليه رسومه وقواعده. خلي بالك من دول:

• حسابات المطوّرين: Apple بتاخد اشتراك سنوي، و Google رسوم تسجيل مرة واحدة. افتح الاتنين باسمك أو باسم شركتك، مش باسم المطوّر.
• حسابات الشركات محتاجة رقم D-U-N-S في المتجرين، وده ممكن ياخد وقت. ابدأ بدري.
• حسابات Google Play الشخصية الجديدة لازم تعمل اختبار مغلق مع مختبرين حقيقيين لفترة محددة قبل النشر للكل. حسابات الشركات مش عليها الخطوة دي.
• المتجرين محتاجين لينك لسياسة الخصوصية، وفورم بيانات يطابق اللي التطبيق بيعمله فعلًا.
• لو المستخدم يقدر يعمل حساب، لازم يقدر يمسحه من جوه التطبيق. ولو فيه دخول بحساب Google أو Facebook على iOS، فـ Apple غالبًا بتطلب اختيار مماثل بيحافظ على الخصوصية زي Sign in with Apple.
• المراجعة غالبًا سريعة، بس الرفض معناه جولة تانية. ونص صفحة المتجر، والصور باللغتين، وحساب تجريبي للمراجع، كلهم محتاجين تحضير.

الاختبار على أجهزة حقيقية

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

وإنتو شغالين في المشروع، المفروض تقدر تنزّل نسخ تجريبية بنفسك، من TestFlight على الآيفون ومن مسار الاختبار الداخلي أو المغلق على Google Play. واسأل مين بيختبر، وعلى أنهي أجهزة، وهل فيه فترة ضمان قصيرة بعد الإطلاق لمشاكل المزايا المتفق عليها.

مصاريف التشغيل بعد الإطلاق

البناء بتدفعه مرة واحدة. أما دول فبيفضلوا طول ما التطبيق شغال:

• السيرفرات وقاعدة البيانات وتخزين الملفات، وبيزيدوا مع المستخدمين والصور والزيارات
• خدمات بتتحاسب على الاستخدام: الـ SMS والخرائط والإيميل، وساعات الشات أو الفيديو
• عمولة بوابة الدفع على كل عملية
• اشتراك Apple السنوي للمطوّرين
• تحديثات لنسخ iOS وأندرويد الجديدة: Google Play بيشترط استهداف نسخة أندرويد حديثة عشان التطبيق يفضل متاح للمستخدمين الجداد، و Apple كل فترة بتشترط إن النسخ الجديدة تتبني بـ Xcode حديث
• تصليح المشاكل والتعديلات الصغيرة وتحديث المكتبات
• دومين وصفحة ويب بسيطة لسياسة الخصوصية والدعم

إزاي تكتب طلب يجيب لك أسعار مظبوطة

• اسم التطبيق وهدفه في سطر، وهو لمين وفي أنهي بلاد
• أنواع المستخدمين، زي العميل والمندوب والأدمن
• الرحلات الأساسية لكل نوع: المستخدم يقدر يعمل إيه بالظبط
• لوحة التحكم: فريقك محتاج يعمل إيه فيها كل يوم
• الربط المطلوب واسم الخدمة لو عارفه: الدفع والخرائط والـ SMS وأي API موجود
• اللغات والمنصات: عربي وإنجليزي، iOS وأندرويد، ولوحة تحكم على الويب
• التصميم: هوية بصرية أو شاشات جاهزة، وتطبيقات عاجباك وليه
• اللي مش داخل في النسخة الأولى
• الموعد المطلوب، والميزانية اللي في دماغك لو حابب تقولها
• إن حسابات المتاجر والسيرفرات والكود هيبقوا باسمك

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

واكتب المزايا على هيئة المستخدم يقدر يعمل إيه. «شات» ممكن تعني أي حاجة. لكن «العميل والمندوب المسؤول يقدروا يبعتوا رسايل نصية طول ما الطلب شغال، من غير صور في النسخة الأولى» دي حاجة تتسعّر.

سعر ثابت ولا بالوقت؟

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

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

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

علامات تخلي بالك منها في عرض السعر

دي علامات أنا شخصيًا بقلق منها، أيًا كانت شركة البرمجة أو المطوّر اللي هتختاره:

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

تقسيم المزايا على مراحل، وتبدأ منين

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

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

النسخة الأصغر أرخص، وبتوصل للناس أسرع، وبتديك بيانات حقيقية تقرر بيها الخطوة الجاية.

تعمل إيه دلوقتي؟ اكتب الصفحة بالبنود اللي فوق، وعلّم على كل ميزة «دلوقتي» أو «بعدين»، وابعتها لـ 2 أو 3 مطوّرين أو شركات برمجة. قارن كل واحد سألك إيه وعرضه شامل إيه، مش الرقم النهائي بس. ولو حابب أبص على طلبك، ابعتهولي من صفحة التواصل وأقولك أنا كنت هبني إيه الأول.

أسئلة شائعة

تكلفة عمل تطبيق موبايل بكام؟

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

هل Flutter أرخص من برمجة تطبيقات Native؟

لنفس النطاق غالبًا آه، لأن كود Flutter واحد بيطلّع تطبيق iOS وتطبيق أندرويد. بس لسه فيه إعداد لكل منصة ونشر على المتجرين واختبار على النظامين. الـ Native ممكن يكون منطقي لتطبيقات معتمدة جدًا على مزايا جديدة في النظام أو على الهاردوير.

برمجة تطبيق جوال بتاخد وقت قد إيه؟

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

إيه مصاريف التطبيق بعد الإطلاق؟

السيرفرات والتخزين، وخدمات بتتحاسب على الاستخدام زي الـ SMS والخرائط، وعمولة الدفع، واشتراك Apple السنوي، وتحديثات لنسخ iOS وأندرويد الجديدة. وكمان تصليح المشاكل والتحسينات الصغيرة. اطلب إن دول يتكتبوا في عرض السعر.

هل التطبيق لازم يكون ليه سيرفر ولوحة تحكم؟

تقريبًا أي تطبيق فيه حسابات أو طلبات أو حجوزات أو محتوى بيتغيّر محتاج سيرفر، وفريقك محتاج لوحة تحكم يدير منها. خدمات زي Firebase أو Supabase ممكن تقلل الشغل في التطبيقات الأبسط. ولو عندك نظام عنده API، التطبيق ممكن يتربط بيه.

مين المفروض يملك حسابات المتاجر وكود التطبيق؟

إنت. افتح حسابات المطوّرين على Apple و Google باسمك أو باسم شركتك، وضيف المطوّر كعضو في الفريق. واتأكد إن العقد بيقول إن الكود والسيرفرات ملكك.