تطوير ويب يحمل العمل، لا الهوية البصرية فقط.

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

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

نبني غالباً حلولاً خاصة بـ React وNode، مع نظام محتوى Headless حيث يحتاج المحرّرون النشر بأنفسهم. السبب هو الأداء والأمان وألّا تُقيَّد منصة تنمو بما تدعمه قالب جاهز. وإذا كان موقع ووردبريس قائم يعمل ويحتاج تحسيناً فقط، نقول ذلك بدل إعادة بنائه بلا سبب.

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

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

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