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

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

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

ما الذي يحدد تكلفة تطبيق الجوال

تتبع التكلفة الجهد، ويتبع الجهد العوامل الآتية، مرتبة تقريبًا بحسب أهميتها.

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

iOS أو Android أو كلاهما. قاعدة شيفرة واحدة مبنية بـ Flutter أو React Native تكلّف عادة أقل من تطبيقين أصليين منفصلين، لكنها لا تكلّف نصفهما أبدًا: فالتصميم والخلفية والاختبار والنشر في المتجر أعمال مشتركة، والميزات الخاصة بكل منصة تحتاج إلى شيفرة أصلية. يتناول مقال [أصلي أم متعدد المنصات](/blog/native-or-cross-platform) هذه المفاضلة بالتفصيل.

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

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

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

دعم العربية والإنجليزية يعني تخطيطًا من اليمين إلى اليسار، وأيقونات معكوسة، وخطوطًا عربية، ونصوصًا تُكتب بالعربية أصلًا، والأفضل أن يُخطَّط لذلك منذ أول شاشة. راجع مقال [تصميم المنتجات ثنائية اللغة](/blog/designing-bilingual-rtl-products). والمحتوى يجب أن يُكتب أو يُنقل، ويتسع الاختبار مع كل مقاس شاشة وإصدار نظام تشغيل ولغة تدعمها.

كيف تُبنى التقديرات، ولماذا تختلف العروض

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

قبل أن تقارن المجاميع، تحقق هل يختلف العرضان في أي مما يأتي:

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

كثيرًا ما يخلو العرض الأرخص من بند يتضمنه غيره. قارن العروض ميزةً بميزة، لا مجموعًا بمجموع.

نطاق ثابت أم فريق مرن

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

في **الفريق المرن** تدفع مقابل طاقة الفريق، وعادة شهريًا، وتوجّه الأولويات كل أسبوع. وهو يناسب منتجًا ما زلت تتعلم عنه. أما ضعفه فهو أنه يحتاج إلى مالك للمنتج من جانبك، وليس له موعد انتهاء مدمج. ويقارن مقال [نماذج التسعير](/company/pricing-models) بين الأسلوبين بتفصيل أكبر.

وهناك حل وسط شائع، هو أن تحدد النطاق أولًا. عندنا هذا هو سبرنت الاستكشاف: نحو أسبوعين بنطاق ثابت، وينتهي بنموذج أولي قابل للنقر ونهج تقني ونمذجة تهديدات للمسارات الأساسية وخارطة طريق مكتوبة. بهذا يتحول «يعتمد» إلى خطة يمكن تسعيرها. وتجد أشكال التعاقد الثلاثة في [صفحة الأسعار](/pricing).

كيف تقلّص النطاق دون المساس بالجودة

ماذا تسأل في عرض السعر

العرض الجيد يتيح لك الإجابة عن هذه الأسئلة دون تخمين:

• ما الميزات المشمولة، مذكورةً واحدة واحدة؟
• ما المنصات وإصدارات أنظمة التشغيل واللغات؟
• كم من التصميم مفترض: الشاشات، والحركة المخصصة، والبحث، ونظام التصميم؟
• من يبني الخلفية ولوحة الإدارة، وأين تعمل؟
• ما الاختبار ومراجعة الأمان اللذان يجريان قبل الإطلاق؟
• ماذا يحدث عند تغيّر النطاق، وكيف يُسعَّر التغيير؟
• ماذا أتسلّم في النهاية: الشيفرة المصدرية، والتوثيق، والنشر في المتاجر، والوصول إلى كل حساب؟
• كم مرة سأرى برنامجًا يعمل فعلًا؟

اطلب أن تُسجَّل حسابات المطورين والشيفرة المصدرية وصفحات المتجر باسمك منذ البداية. لا يكلّف ذلك شيئًا في أوله، ويكلّف كثيرًا إن غيّرت الجهة المنفذة يومًا.

التكاليف التي ينساها الناس

• **الصيانة.** تُصدر Apple وGoogle إصدارات جديدة من أنظمة التشغيل كل عام، وتحتاج المكتبات إلى تحديث، وتتغير شروط المتاجر. والتطبيق الذي لا يُصان يتوقف عن العمل تدريجيًا. ضعها في الميزانية بندًا متكررًا لا تكلفة لمرة واحدة.
• **حسابات المتاجر.** برنامج المطورين لدى Apple له رسم سنوي، وGoogle Play له رسم تسجيل. وحسابات المؤسسات تتطلب التحقق من الكيان القانوني، وقد يستغرق ذلك وقتًا. راجع الشروط الحالية قبل تثبيت موعد الإطلاق.
• **عمولات المتاجر.** يقتطع كلا المتجرين حصة من المشتريات داخل التطبيق للسلع الرقمية. وانطباق ذلك عليك يعتمد على ما تبيعه.
• **الخدمات الخارجية.** الاستضافة وإرسال الإشعارات والخرائط والرسائل النصية والبريد والتحليلات وتقارير الأعطال كثيرًا ما تُحاسَب بحسب الاستخدام، فتكبر الفاتورة مع نجاحك.
• **صيانة المحتوى والترجمة.** كل شاشة جديدة تحتاج إلى نص عربي وإنجليزي.
• **الدعم.** لا بد من شخص يرد على المستخدمين ويفرز الأعطال.

ولنظرة أوسع إلى أثر أسلوب البناء في الفاتورة، اقرأ دليل [اختيار طريقة بناء منتجك](/guides/choosing-how-to-build-your-product)، أو اطّلع على نهجنا في [تطبيقات الجوال](/services/mobile-development).