تطوير المواقع والمنصّات: قدرة داخل فريقك، لا مشروع تشتريه

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

الموقع التعريفي (Corporate / Brochure) هو الأبسط من حيث الوظيفة وأخطر من حيث الانطباع. غرضه أن يبني ثقة خلال أول عشر ثوانٍ، ويقدّم خدماتك بوضوح، ويترك القارئ يعرف كيف يتواصل معك. هنا تكون السرعة وجودة المحتوى والظهور في بحث جوجل أهم بكثير من أي ميزات معقّدة. ومع ذلك فهو أكثر ما يتغيّر: خدمة جديدة، صفحة هبوط لحملة، تحديث أسعار، نص يعاد كتابته.

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

المنصّة (Platform / SaaS) هي تطبيق ويب كامل: تسجيل دخول، صلاحيات، قواعد بيانات، عمليات تجارية حقيقية. سوق توظيف، نظام حجوزات، منصّة تعليمية، أداة إدارة عملاء: كلها منصّات تتطلّب تفكيرًا معماريًا منذ اليوم الأول، لأن الخطأ في الأساس يكلّف أضعافًا لاحقًا. والمنصّة بطبيعتها خارطة طريق مفتوحة، لا نطاقًا يُغلق ويُسلَّم.

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

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

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

الفارق بين موقع "موجود" وموقع "يعمل" هو الأداء. مؤشرات Core Web Vitals من جوجل (سرعة التحميل، استقرار العناصر، سرعة الاستجابة) ليست ترفًا تقنيًا، بل عامل ترتيب مباشر في نتائج البحث. والأداء يتآكل بصمت: صورة ثقيلة يرفعها فريق التسويق، سكربت تتبّع جديد، حزمة تكبر مع كل ميزة. الموقع الذي لا يقيسه أحد أسبوعيًا يبطؤ تدريجيًا دون أن يلاحظ أحد حتى يهبط الترتيب.

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

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

الخلاصة العملية: الموقع لم يعد بطاقة تعريف رقمية، بل قناة بيع وثقة وتشغيل تحتاج يدًا هندسية كل أسبوع. ولهذا وحدة التسليم في كادر ليست "موقعًا"، بل فريقًا يملك القدرة ويبقى عليها: مهندسو full-stack و UI/UX و QA بقيادة Tech PM من كادر، بتقدير مكتوب قبل كل مهمة، وموافقتك قبل تجاوزه، وتقرير أسبوعي بما أُنجز وما التالي.

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

• من يوظّف المهندسين ومن يشرف عليهم؟ في كادر المهندسون موظفون لدى كادر ويعملون تحت إشرافها من مركزنا الهندسي في عمّان. أنت لا تدير أفرادًا ولا تتحمّل عبء التوظيف، بل تشتري تسليمًا مُدارًا ونتائج.
• ما الذي يحكم العلاقة كتابةً؟ اتفاقية إطارية (MSA) وبيان عمل (SOW) يُتفق عليهما قبل بدء العمل، وفيهما النطاق والصلاحيات وشروط الملكية الفكرية. أي جهة لا تضع هذا كتابةً قبل السطر الأول من الكود ستضعه لاحقًا في نقاش غير مريح.
• ما الإيقاع الأسبوعي؟ اسأل تحديدًا: هل هناك Sprint أسبوعي ينتهي بـ demo لما بُني فعلًا؟ ومن يقود الفريق؟ في كادر يقوده Tech PM يترجم أولوياتك إلى مهام، ويصلك تقرير أسبوعي بما أُنجز وما استُهلك وما التالي. الصندوق المغلق حتى التسليم هو أول علامة خطر.
• كيف يُضبط النطاق دون تفاوض متكرّر؟ تقدير مكتوب قبل أي مهمة، وموافقتك قبل تجاوزه. هذا يستبدل عقد النطاق المغلق بشيء أفضل: أولويات تعيد ترتيبها في بداية كل Sprint دون أن تدفع ثمن التغيير مرتين.
• ما الذي يحدث لو غادر مهندس؟ استمرارية التسليم مسؤولية الجهة لا مسؤوليتك. اسأل عن التوثيق، ومراجعة الكود، ومعرفة موزّعة داخل الفريق. الجهة التي تعتمد على شخص واحد تبيعك مخاطرة لا قدرة.
• ما الذي يحدث بعد الإطلاق؟ من يصلح الأعطال ومن يحدّث الحزم ومن يراقب الأداء؟ الموقع كائن حي يحتاج رعاية، لا منتجًا يُسلَّم ويُنسى. إن لم يكن ما بعد الإطلاق داخل الاتفاق، فأنت تشتري نصف الحل.

إن وجدت جهة تجيب عن هذه الأسئلة الستة بثقة وتفصيل، فأنت على الأرجح أمام فريق تقني يمتدّ لشركتك لا مجرد مورّد مشاريع. والفرق بينهما هو الفرق بين قدرة تكبر معك وموقع تعيد بناءه بعد عام.

لا يبدأ الفريق من القالب، بل من سؤال: ماذا نريد أن يفعل هذا النظام لعملك؟ بعد أن يُفهم الهدف (بيع، حجز، توظيف، بناء ثقة) تُختار التقنية المناسبة له، لا العكس. هذا الترتيب وحده يفصل القدرة المنتجة عن العمل المكلّف. والقرار وأسبابه يُكتبان في SOW قبل أن يبدأ العمل، لا بعده.

تقنيًا، تُبنى الواجهات غالبًا على Next.js و React. هذا الاختيار ليس موضة: Next.js يتيح توليد الصفحات مسبقًا (SSR/SSG) فتأتي للزائر جاهزة وسريعة، ما ينعكس مباشرة على Core Web Vitals وعلى ترتيبك في جوجل. والنتيجة صفحة تصل جاهزة على شبكة الجوال، لا صفحة بيضاء تنتظر تحميل سكربتات ثقيلة.

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

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

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

أخيرًا، التكاملات. النظام نادرًا ما يعيش وحده: بوابات دفع محلية (مدى، Apple Pay)، أنظمة فوترة، رسائل واتساب، أدوات تحليل، أو ربط مع نظامك الداخلي عبر API. تُبنى هذه الجسور بشكل نظيف بحيث يتدفّق العمل تلقائيًا بدل العمل اليدوي المتكرّر. أما شروط ملكية الكود وحقوق الملكية الفكرية فتُحدَّد في MSA و SOW ويُتفق عليها قبل بدء أي عمل.

والإيقاع فوق كل هذا: Sprint أسبوعي ينتهي بـ demo لما بُني فعلًا، وتقدير مكتوب قبل أي مهمة، وموافقتك قبل تجاوزه، وتقرير أسبوعي بما أُنجز وما استُهلك وما التالي. الأولويات تبقى بيدك وتعيد ترتيبها في بداية كل Sprint.

تختلف احتياجات الأعمال، ومعها يختلف ما يبنيه الفريق. القدرة نفسها واحدة، والمخرجات التي تنتجها تشمل:

• مواقع تعريفية للشركات والعلامات: واجهة تبني الثقة وتعرّف بخدماتك وتظهر في بحث جوجل، مصمّمة للسرعة وللانطباع الأول، وتتوسّع كلما أضفت خدمة.
• متاجر إلكترونية متكاملة: كتالوج منتجات، سلة وشراء، دفع محلي (مدى و Apple Pay)، إدارة مخزون وطلبات، مبنية حول معدّل التحويل لا الشكل وحده.
• منصّات وأنظمة ويب (SaaS): تطبيقات كاملة بتسجيل دخول وصلاحيات وقواعد بيانات: أسواق، حجوزات، أنظمة تعليمية، أو أدوات إدارة مخصّصة لعملك.
• لوحات تحكّم وإدارة: واجهات خلفية تدير الطلبات والمحتوى والمستخدمين، وتحوّل بياناتك المتناثرة إلى تقارير وقرارات.
• صفحات هبوط حملات (Landing Pages): صفحات سريعة ومركّزة على هدف واحد، مصمّمة لحملاتك الإعلانية لتحويل النقرة إلى عميل.
• تطبيقات ويب تقدمية (PWA): تجربة قريبة من التطبيق تعمل من المتصفّح، مع سرعة وإمكانية تثبيت على الجوال دون متجر تطبيقات.

السؤال الأهم ليس "أي نوع أبني؟" بل "أي نموذج فريق يناسب وضعي؟". القاعدة بسيطة: إن كان لديك نظام حيّ يعمل ويحتاج صيانة وتعديلات متفرّقة بلا خارطة طريق مستمرة، فـ ساعات كادر (/services/hours) هي المناسبة. وإن كانت لديك خارطة طريق تحتاج فريقًا يعمل عليها كل أسبوع، فـ فرق كادر (/services/squads). وإن كنت تبني قسمًا هندسيًا طويل الأمد بعدة تخصصات، فـ مركز كادر للتطوير (/services/offshore).

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