السؤال الخاطئ يأتي أولاً
"هل نبني موقعًا إلكترونيًا أم تطبيقًا؟" هذا هو السؤال الذي نسمعه في كل مكالمة أولى تقريبًا. إنه السؤال الخاطئ. إنه يتخطى خطوة.
السؤال الصحيح هو: ماذا يحتاج هذا المنتج أن يفعل، ولمن؟ الموقع التسويقي، وتطبيق الويب المخصص، وتطبيق الويب التقدمي (PWA) تحل مشكلات مختلفة. اختيار الخيار الخاطئ لا يهدر الميزانية فقط — بل يحبسك في بنية معمارية مكلفة التفكيك بعد ستة أشهر، عادةً مباشرة بعد أول جولة من ملاحظات المستخدمين الحقيقيين.
هذا هو الإطار الذي نستخدمه مع العملاء قبل كتابة أي سطر برمجي، إلى جانب نطاقات صادقة لتكلفة كل خيار ومدته الزمنية في عام 2026.
ثلاث مهام مختلفة، لا ثلاث درجات لنفس المهمة
تتعامل الفرق مع هذه الخيارات كسلّم: الموقع التسويقي في الأسفل، وPWA في الأعلى، والتطبيق في المنتصف. هذا غير دقيق. فهي ليست نسخًا أكثر أو أقل تطورًا من بعضها البعض. إنها تجيب عن أسئلة مختلفة.
الموقع التسويقي. المهمة: تحويل الزائر إلى عميل محتمل أو عملية بيع. يعتمد على المحتوى، وهو عام في الغالب، بلا حسابات مستخدمين (أو حساب بسيط مُضاف لمحتوى محجوب). يُقاس النجاح بمعدل التحويل وسرعة التحميل وترتيب محركات البحث. يُبنى على نظام إدارة محتوى (CMS) أو إطار عمل للمواقع الثابتة، ونادرًا ما يحتاج منطقًا خلفيًا مخصصًا يتجاوز النماذج والتحليلات.
تطبيق الويب المخصص. المهمة: تمكين مستخدم مُسجَّل الدخول من إنجاز عمل حقيقي — إدارة المخزون، مراجعة المطالبات، حجز المواعيد، تشغيل التقارير. هنا يكمن منطق العمل: الصلاحيات، وسير العمل، والتحقق من صحة البيانات، والتكاملات مع نظام إدارة علاقات العملاء (CRM) أو نظام تخطيط موارد المؤسسات (ERP) الخاص بك. يُقاس النجاح بزمن إنجاز المهمة ومعدل الأخطاء، لا بعدد مشاهدات الصفحة.
تطبيق PWA. المهمة: منح تطبيق الويب شعور التطبيق الأصلي — أيقونة قابلة للتثبيت، ووصول دون اتصال للشاشات الأساسية، وإشعارات فورية — دون دورة مراجعة متجر التطبيقات أو قاعدتَي شيفرة منفصلتين. إنه ليس فئة رابعة بقدر ما هو وضع تسليم يُضاف فوق تطبيق ويب. أنت لا تبني "تطبيق PWA" بدلاً من تطبيق ويب؛ بل تبني تطبيق ويب وتقرر كم من طبقة PWA (عمّال الخدمة، والتخزين المؤقت دون اتصال، ومطالبات التثبيت) يستحق الإضافة.
كيف تختار فعليًا
اطرح هذه الأسئلة الأربعة بالترتيب:
- هل يُسجِّل المستخدم الدخول لإنجاز عمل متكرر، أم أن الزائر يقرأ ويغادر؟ عمل متكرر ← تطبيق ويب. قراءة ومغادرة ← موقع تسويقي.
- هل يحتاج المنتج للعمل باتصال ضعيف، على هاتف، بعيدًا عن مكتب العمل؟ فنيو الميدان، وموظفو المستودعات، وسائقو التوصيل — نعم. موظفو المعرفة المكتبيون على اتصال مستقر — عادةً لا، وطبقة PWA هنا عبء إضافي لست بحاجة إليه بعد.
- هل الظهور في نتائج البحث جزء من كيفية وصول الناس إليك؟ إن كانت الإجابة نعم، فيجب أن يعيش ذلك المحتوى على موقع تسويقي سريع وقابل للزحف — لا أن يُدفن خلف جدار تسجيل دخول تطبيقك، ويحتاج إلى الأساسيات التقنية (أساسيات تحسين محركات البحث: م حتوى مُقدَّم من الخادم، وروابط نظيفة، وبيانات منظّمة (schema) تعمل بشكل صحيح) مبنيّة منذ أول إيداع برمجي، لا مُضافة بعد الإطلاق.
- هل تحتاج كليهما؟ معظم شركات B2B تحتاج ذلك: موقع تسويقي لتوليد العميل المحتمل، وتطبيق ويب خلف تسجيل الدخول حيث يتواجد العميل الفعلي الذي يدفع. هذان بناءان، لا بناء واحد — والتعامل معهما كمشروع واحد سبب شائع لتجاوز مشاريع الويب ميزانيتها الأصلية.
إذا كنت تبني النوع الثاني — التطبيق الذي يستخدمه عملاؤك فعليًا — فهذا حيث يقضي فريق تطوير الويب لدينا معظم وقته، لأن هذا هو المكان الذي تتركز فيه التكلفة والمخاطر فعليًا.
ما الذي يحدد التكلفة فعليًا
التكلفة لا تتعلق أساسًا بعدد الصفحات أو "عدد الميزات". بل بأربعة أمور:
تعقيد نموذج البيانات. تطبيق CRUD بعدد قليل من أنواع الكيانات البسيطة بناءٌ مختلف تمامًا عن تطبيق بصلاحيات قائمة على الأدوار عبر أنواع كيانات عديدة مع سجلات تدقيق (audit trails). كل علاقة إضافية تضاعف مساحة الاختبار، لا المخطط فقط.
التكاملات. كل نظام خارجي تتصل به — Stripe، أو Salesforce، أو واجهة برمجة تطبيقات شركة شحن، أو قاعدة بيانات داخلية قديمة — يضيف وقتًا حقيقيًا بحسب مدى توثيق واستقرار واجهة ذلك النظام. الأن ظمة الداخلية غير الموثقة من أكبر مصادر تأخر الجداول الزمنية التي نراها، لأنك لا تكتشف الحالات الاستثنائية إلا عندما تكون بصدد التكامل فعليًا.
متطلبات الوقت الفعلي والعمل دون اتصال. لوحة تحكم تُحدَّث عند تحميل الصفحة رخيصة التكلفة. أما لوحة تحكم بتحديثات فورية عبر websockets، أو واجهة جوال تحتاج للعمل دون اتصال ثم المزامنة لاحقًا، فتضيف وقت هندسة حقيقيًا فوق البناء الأساسي للشاشات المتأثرة.
نضج التصميم. إذا بدأت من ملف Figma بكل حالة (فارغة، تحميل، خطأ، حالة استثنائية) مُصمَّمة مسبقًا، يتحرك البناء بسرعة. أما إذا جرى التصميم بالتوازي مع التطوير، فتوقع إعادة عمل — تُبنى الشاشات وفق مواصفات تتغير من تحتها.
أقدمية الفريق وموقعه يؤثران على السعر بالساعة، لكنهما نادرًا ما يفسران أكبر التقلبات في التكلفة الإجمالية للمشروع. العوامل الأربعة أعلاه هي التي تفعل ذلك.
جداول زمنية واقعية لعام 2026
هذه نطاقات تقريبية لبناء واحد مُحدَّد النطاق جيدًا — لا لمجموعة كل ما قد تحتاجه مؤسسة كبيرة — استنادًا إلى مشاريع حدّدنا نطاقها مؤخرًا:
- الموقع التسويقي (عدد قليل من الصفحات، مبني على CMS، بلا خلفية برمجية مخصصة): بضعة أسابيع.
- تطبيق ويب مخصص بتعقيد قياسي (تسجيل دخول، بضعة أنواع كيانات أساسية، تكامل أو اثنان): ربع سنة تقريبًا.
- تطبيق ويب مخصص بتعقيد عالٍ (صلاحيات متعددة الأدوار، عدة تكاملات، ميزات فورية): بضعة أرباع سنة أو أكثر.
- إضافة طبقة PWA إلى تطبيق ويب قائم (تخزين مؤقت دون اتصال للشاشات الأساسية، مطالبة تثبيت، إشعارات فورية): بضعة أسابيع، بحسب مقدار ما يحتاجه التطبيق للعمل دون اتصال مقابل مجرد كونه قابلاً للتثبيت.
أي شخص يقدم رقمًا ثابتًا دون السؤال عن نموذج بياناتك وتكاملاتك وحالة تصميمك إنما يُخمّن.
النمط الذي نراه غالبًا
الخطأ الأكثر شيوعًا ليس اختيار الصيغة الخاطئة — بل اختيار صيغة واحدة وتكليفها بالمهمتين معًا. تبني شركة موقعًا تسويقيًا أنيقًا، ثم تحاول إضافة لوحة تحكم للعملاء فوق قاعدة الشيفرة نفسها لأنها "مبنية بالفعل". بعد أشهر، تتصارع لوحة التحكم مع نظام إدارة المحتوى على التحكم في التوجيه (routing)، وكل تحديث للمحتوى يهدد بكسر ميزة تعمل بعد تسجيل الدخول.
الحل غالبًا هو الفصل بينهما منذ البداية: موقع تسويقي خفيف مُحسَّن للسرعة والبحث، وتطبيق ويب منفصل مُحسَّن لتجربة ما بعد تسجيل الدخول، يتشاركان نظام تصميم واحدًا لكن لا يتشاركان قاعدة شيفرة واحدة. يكلّف ذلك أكثر قليلاً في البداية. لكنه يوفر عليك إعادة بناء لاحقًا.
الخلاصة
لا تبدأ بـ"موقع أم تطبيق". ابدأ بما يفعله المستخدم فعليًا ومقدار ما يحتاج منه للنجاة من اتصال سيئ. حدّد نطاق الموقع التسويقي والمنتج الذي يعمل بعد تسجيل الدخول كقرارين منفصلين، حتى لو بناهما فريق واحد. وعند تسعير بناء مخصص، اسأل عن نموذج البيانات والتكاملات قبل أن تسأل عن عدد الصفحات — فمن هناك يأتي الرقم الحقيقي.
إذا كنت في مرحلة تحديد نطاق أحد هذه المشاريع وتريد إجابة مباشرة عن التكلفة والمدة الزمنية لحالتك تحديدًا، تحدث معنا قبل أن تكتب طلب العروض (RFP).
