موقع، أم تطبيق ويب، أم تطبيق جوال؟ ماذا تبني في 2026 وأين تتعثر المشاريع
الجميع متفقون على أن الشركة تحتاج «تطبيقاً». لكن نوع التطبيق، موقعاً كان أم تطبيق ويب أم تطبيق جوال أصلياً، يغيّر الميزانية بمرتبة كاملة. دليل بلغة واضحة للاختيار، مع تحديد المزالق.

«نحتاج تطبيقاً» هي أغلى جملة غامضة في عالم تقنية الأعمال. بحسب ما تعنيه فعلاً، قد تكلّفك بضعة آلاف من الدراهم أو بضع مئات الآلاف. وقبل أن يسعّر لك أي مطوّر شيئاً، هناك سؤال يحتاج جواباً: ما الذي تبنيه بالضبط، ولمن، ولماذا؟
ثلاثة أشياء مختلفة تماماً
- الموقع يعرّف بك: من أنت، وماذا تبيع، وكيف يصل إليك العميل. مهمته أن يُعثر عليه في البحث، وأن يفتح بسرعة، وأن يحوّل الزائر إلى اتصال أو طلب.
- تطبيق الويب ينجز عملاً: بوابات، ولوحات متابعة، وأنظمة حجز، وأدوات داخلية. يعيش خلف تسجيل دخول، ويعمل في المتصفح على أي جهاز.
- تطبيق الجوال يسكن متاجر التطبيقات وشاشة الهاتف الرئيسية، ولا يستحق مكانه إلا حين تحتاج ما ينفرد به الهاتف: الإشعارات، والكاميرا، وتحديد الموقع، والعمل دون اتصال، أو حضور يومي في يد المستخدم.
القرار في فقرة واحدة
ابدأ بالموقع، فكل شركة تحتاجه وهو المرساة لكل ما بعده. وابنِ تطبيق ويب حين يحتاج المستخدمون أن ينجزوا شيئاً لا أن يقرأوا فقط. تطبيق الويب يعمل على كل جهاز من اليوم الأول، ولا ينتظر موافقة متجر، ويتحدّث لحظياً. أما تطبيق الجوال الأصلي فأضفه حين تكون الإشعارات أو العمل دون اتصال أو حساسات الهاتف أو عادة الاستخدام اليومي جزءاً حقيقياً من القيمة. أما «منافسنا لديه تطبيق» فليس سبباً، وأرقام تنزيلاتهم كفيلة بإحراجهم.
أصلي أم متعدد المنصات؟ بصراحة
إن كنت تحتاج تطبيق جوال فعلاً، فنادراً ما تحتاج اليوم قاعدتي كود منفصلتين. أطر العمل متعددة المنصات مثل Flutter وReact Native تعطيك قاعدة كود واحدة تخدم iOS وAndroid بدل قاعدتين منفصلتين، بأداء لا يفرّق فيه مستخدم تطبيقات الأعمال. وكم يوفّر ذلك يعتمد على التطبيق نفسه؛ الوفر في بناء قاعدة واحدة وصيانتها بدل اثنتين. ويبقى البناء الأصلي الخالص متفوقاً في الألعاب والرسوميات الثقيلة والتكامل العميق مع العتاد، وهي حالات لا تقترب منها معظم الشركات.
ما الذي يحدد الميزانية فعلاً
ليست المنصة، بل نطاق العمل. تسجيل الدخول، والمدفوعات، ودعم العربية والإنجليزية باتجاه كتابة سليم، والربط مع نظام ERP، ولوحة الإدارة: كل بند من هذه عمل حقيقي مهما كان الطريق الذي تختاره. والانضباط الذي يبقي الميزانيات عاقلة بسيط: نطاق إصدار أول يُسلَّم خلال شهور، يُتفق عليه كتابةً بشروطه التجارية قبل أن يبدأ العمل، وكل ما عدا ذلك في خارطة طريق لا في العقد الأول.
المزالق الأربعة
الأول: بناء تطبيق جوال بينما كانت الحاجة تطبيق ويب، فتتضاعف الكلفة لتطبيق لا يثبّته أحد. الثاني: موقع جميل بلا تحليلات ولا ميزانية سرعة ولا أساسيات تحسين الظهور في محركات البحث، فيخرج غير مرئي وبطيء. الثالث: كود مصدري يبقى عند الوكالة، والعلاج أن تشترط في العقد انتقال الكود والتوثيق إليك. الرابع: غياب خطة صيانة، فالبرمجية بلا مالك تتحلل مع تحديثات المتصفحات والمتاجر. والمزالق الأربعة كلها يمكن تفاديها في مرحلة التصميم، ولهذا نصرّ على التصميم قبل البناء. وإن كنت في بداية الطريق، فمكالمة قصيرة تكفي لتحديد أي الثلاثة تحتاج فعلاً.
ما الذي تطلبه فعلاً؟
أشّر على ما يحتاجه المنتج حقاً. التقدير يتحرك لأن كل بند منها عمل حقيقي لا خانة تُملأ، ورؤية ذلك أنفع عادةً من الرقم نفسه.
الافتراضات مكتوبة لتناقشها: أربعة أسابيع أساساً لأي إصدار، ثم تُجمع الأسابيع المكتوبة أمام كل بند تختاره، ثم يُعرض المجموع بنطاق من 85% إلى 135% منه، لفريق صغير متفرّغ يعمل دون انقطاع. ولا تشمل الاكتشاف، ولا دورات التصميم، ولا موافقات مؤسستك. هي طريقة لترى حجم ما طلبته، لا عرض سعر ولا سعراً ولا التزاماً بموعد تسليم. أما المدة والكلفة في عمل حقيقي فتُحدَّدان بعد فهم النطاق، ويصلانك في عرض مكتوب.
ابدأ بحوار
استشارة أولى مع مستشار، لا مع مندوب مبيعات، حول سؤالك في تقنية المعلومات أو الأمن أو الأنظمة.
