ابدأ بتحديد ما إذا كنت بحاجة إلى تطبيق
أغلى قرار يتعلق بالتطبيق يتخذ قبل كتابة أي سطر من الكود: بناء تطبيق من الأساس.
يجب على التطبيق أن:
- يُجد في المتجر
- يُثبت
- تُمنح له الأذونات
- يبقى على الشاشة الرئيسية التي يقوم مالكه بتنظيفها بشكل دوري
هذا قدر كبير من الاحتكاك يجب تجاوزه. يستحق ذلك عندما يقدم التطبيق شيئًا لا تستطيع الموقع تقديمه:
- القدرة على العمل دون اتصال — فريق الميدان، سائقي التوصيل، أي مكان به إشارة غير موثوقة
- الإشعارات الفورية — تلك المفيدة حقًا، وليس رسائل تسويقية
- أجهزة الجهاز — مسارات الكاميرا، أجهزة البلوتوث الطرفية، تحديد الموقع في الخلفية
- الاستخدام المتكرر — شيء يُفتح معظم الأيام، حيث يوفر ثلاث ثوانٍ يتراكم
إذا لم ينطبق أي من هذه الأمور، فسيصل موقع محمول سريع وبناء جيدًا إلى المزيد من الأشخاص مقابل مال أقل. نبلغ عملائنا بهذا بانتظام، وغالبًا ما يكون هذا أهم شيء يقال في المكالمة الأولى.
تكلفة التطبيق الحقيقية في المملكة المتحدة
"حاسبات تكلفة التطبيق" المنشورة هي أدوات تسويقية. ها هي النطاقات التي نعمل بناءً عليها، لوكالة بريطانية تقوم بالعمل بشكل صحيح:
| النطاق | النطاق النموذجي |
|---|---|
| منصة واحدة، مجموعة ميزات مركزة | £15,000 – £30,000 |
| متعدد المنصات، iOS وAndroid | £22,000 – £45,000 |
| مع مدفوعات، بيانات حية أو مزامنة دون اتصال | £35,000 – £70,000 |
| صيانة مستمرة، سنويًا | 15–20% من تكلفة البناء |
السطر الأخير هو الأكثر إغفالًا في الميزانيات، وهو ليس اختياريًا. iOS وAndroid كلاهما يصدران إصدارًا رئيسيًا سنويًا. Google ترفع متطلبات API المستهدفة سنويًا وتحذف التطبيقات التي تتخلف عن الركب. تطبيق بدون ميزانية صيانة لديه عمر تشغيل يبلغ حوالي عامين.
أي شيء يُعرض بسعر أقل من £8,000 هو إما قالب أبيض أو سعر ثابت سيتم إعادة التفاوض عليه بمجرد ظهور الأجزاء الصعبة.
أصلي أم متعدد المنصات
هذا هو القرار الأكثر تأثيرًا على التكلفة، لذا يستحق أن نكون واضحين بشأن المفاضلة بدلاً من معالجته كموضوع ذوق.
متعدد المنصات (Flutter، React Native) يعني قاعدة كود واحدة تنتج كلاً من التطبيقين. توفر ما يقرب من 30–40% من تكاليف البناء، وأكثر بكثير على المدى الطويل، لأنك ستحتاج إلى مجموعة واحدة من الميزات بدلاً من اثنتين. بالنسبة للغالبية العظمى من تطبيقات الأعمال — الحجز، الطلبات، لوحات التحكم، الأدوات الداخلية — لا يستطيع المستخدم التمييز.
أصلي (Swift، Kotlin) يعني قاعدتي كود وخبرتين مختلفتين في المنصات. هذا هو الخيار الصحيح عندما يعتمد التطبيق بشدة على الجهاز: معالجة مستمرة للكاميرا، تتبع الموقع في الخلفية، ARKit، أو رسوم متحركة معقدة لدرجة تصبح الطبقة الرسومية فيها مرئية.
السؤال الثانوي هو من سيقوم بالصيانة. إذا كان فريقك بالفعل يكتب بلغة React، فإن React Native يسمح لهم بمشاركة المهارات وبعض الكود مع تطبيق الويب الخاص بك، وهو ما غالباً ما يفوق الميزة التقنية لـ Flutter. إذا لم يكن لديك أي قدرة داخلية على تطوير تطبيقات الجوال على الإطلاق، فإن Flutter هو الرهان التقني الأكثر أماناً. في كلتا الحالتين، سوق التوظيف الذي ستستقطب منه الموظفين أهم من أي معيار تقني.
أين تختفي الميزانيات بهدوء
هناك خمسة أشياء تمثل معظم تجاوزات الميزانية التي نراها في المشاريع التي تأتي إلينا من جهات أخرى.
1. معالجة الوضع غير المتصل به كحالة هامشية
"يجب أن يعمل في الوضع غير المتصل" يبدو وكأنه ميزة. إنه في الواقع بنية تحتية. إعادة تجهيز التخزين المحلي وحل النزاعات في تطبيق مبني حول استدعاءات API الحية يشبه إعادة كتابة التطبيق بالكامل تقريباً. اتخذ هذا القرار في الأسبوع الأول.
2. إضافة الإشعارات الفورية في النهاية
تتطلب الإشعارات بنية تحتية للخادم، تدفقات الأذونات، التجزئة، وروابط عميقة تفتح الشاشة الصحيحة. عند إضافتها في النهاية، تصبح "إرسال نفس الرسالة للجميع"، مما يعلم المستخدمين على تعطيلها — مما يفقد التطبيق أداة الاحتفاظ التي بُني من أجلها.
3. عدم التخطيط لمراجعة المتجر
يتم رفض أول تقديماتك إلى Apple غالباً. ليس لأسباب دراماتيكية: سلاسل الخصوصية، شروط الاشتراك غير الواضحة، حذف الحساب المفقود، عرض iPad في تطبيق عالمي. الجدول الزمني الذي لا يسمح بجولة مراجعة أو جولتين هو جدول زمني سيتأخر علناً.
4.Backend يُعتبر بعد فوات الأوان
معظم التطبيقات هي واجهة أمامية لخدمة. إذا لم تكن هذه الخدمة موجودة، فأنت تطلب مشروعين. عندما تكون الخلفية موجودة بالفعل، فإن واجهة برمجة التطبيقات (API) الخاصة بها غالباً ما تكون مصممة لموقع ويب وتحتاج إلى إعادة تشكيل للتطبيق الجوال — نقاط نهاية أكثر تفاعلية، ترقيم الصفحات، وحمولات بحجم مناسب لاتصال جوال.
5.الاختبار على جهاز واحد رائد
هذا في الغالب مشكلة في نظام Android، ومشكلة كبيرة. التطبيق الذي يعمل بشكل جيد على جهاز رائد حديث قد يكون غير قابل للاستخدام على الهاتف من الفئة المتوسطة الذي يستخدمه جزء كبير من مستخدمي المملكة المتحدة. أضف إلى ذلك مديري بطاريات الشركات المصنعة الذين يقتلون العمليات الخلفية، ويصبح "الإشعارات توقفت عن العمل" هو أكثر تذاكر الدعم شيوعاً.
الجدول الزمني الواقعي
لتطبيق أعمال متعدد المنصات:
- النطاق والتصميم — 3 إلى 4 أسابيع. قائمة الميزات، التدفقات، وتصميم الواجهة يتم مراجعتها على أجهزة حقيقية.
- البناء الأساسي — 8 إلى 12 أسبوعاً في دورات مدتها أسبوعان، تنتهي كل دورة ببناء قابل للتثبيت.
- النسخة التجريبية — أسبوعان مع مستخدمين حقيقيين على TestFlight واختبار Play الداخلي.
- تقديم المتجر — 1 إلى 3 أسابيع بما في ذلك جولات المراجعة المتوقعة.
- ما بعد الإطلاق — 30 يوماً من الإصلاحات، ثم الصيانة.
حوالي أربعة إلى خمسة أشهر. ضغط الجدول عادة يعني إزالة النسخة التجريبية، وهو بالضبط الجزء الذي يكشف المشاكل التي كان سيبلغ عنها مستخدموك علناً في مراجعات المتجر.
ما يجب أن تسأله لأي وكالة قبل التوقيع
- من يمتلك الكود، وهل نحصل على المستودع؟
- هل حسابات المطورين مسجلة باسمنا أم باسمكم؟
- ماذا يحدث إذا رفضت Apple تقديم التطبيق — هل يتم احتساب ذلك؟
- ما هي تكلفة الصيانة السنوية، كتابياً؟
- على أي أجهزة محددة ستختبرون؟
- ماذا يحدث للتطبيق إذا توقفنا عن العمل معاً؟
الإجابات على هذه الأسئلة الستة تخبرك أكثر من أي معرض أعمال. إذا تسببت أي من هذه الأسئلة في التردد، فهذا هو جوابك.
الخطوات التالية
إذا كنت تفكر في تطبيق جوال، فإن المحادثة الأولى المفيدة ليست حول الميزات — بل حول ما إذا كان التطبيق هو الشكل الصحيح للمشكلة. يسعدنا إجراء هذه المحادثة وأخبارك إذا كان الجواب هو موقع ويب.
الأسئلة المتكررة
يكلف تطبيق مركّز يعمل على منصة واحدة عادةً ما بين £15,000 و£30,000. بينما يتراوح تطبيق cross-platform الذي يغطي كلاً من iOS وAndroid عادةً بين £22,000 و£45,000 حسب كمية العمل المطلوب في الخلفية. تقع التطبيقات التي تتضمن مدفوعات أو بيانات حية أو مزامنة دون اتصال في الطرف الأعلى من السعر. أي عرض يقل عن £8,000 هو عادةً قالب بوضع شعارك عليه.
من 12 إلى 20 أسبوعاً من تحديد النطاق الموقّع حتى الإصدار الأول لمعظم تطبيقات الأعمال، بالإضافة إلى 1 إلى 3 أسابيع لمراجعة المتجر. أكبر متغير ليس سرعة التطوير — بل مدى سرعة اتخاذ القرارات والمحتوى من جانب العميل.
يُناسب cross-platform باستخدام Flutter أو React Native معظم تطبيقات الأعمال ويوفر ما يقرب من 30–40% مقارنة بتطوير تطبيقين منفصلين. أما Native فيستحق التكلفة الإضافية عندما تعتمد على ميزات الجهاز الثقيلة مثل معالجة الكاميرا المتقدمة أو تحديد الموقع في الخلفية أو الرسوم المتحركة المعقدة والمستمرة.
غالباً لا. إذا كان مستخدموك سيزورونك مرة واحدة شهرياً، فسيكون موقع الويب المتحرك السريع أفضل لهم ويكلف أقل بكثير — لا أحد يقوم بتثبيت تطبيق يستخدمه بشكل متقطع. يستحق التطبيق مكانه عندما يحتاج إلى وصول دون اتصال، وإشعارات دفع، أو أجهزة طرفية، أو استخدام متكرر حقاً.
- تطوير التطبيقات
- mobile
- budgeting
- iOS
- Android