ووردبريس ولا موقع مخصص؟ اختار صح من الأول
مقارنة عملية بين الاتنين حسب حجم شغلك وخططك، مش حسب رأي المبرمج.

السؤال ده بيتسأل كتير، والإجابة الصادقة: مفيش اختيار أحسن — فيه اختيار أنسب لحالتك.
ووردبريس يناسبك لو
- عايز تعدّل المحتوى بنفسك من غير مبرمج.
- موقعك أغلبه صفحات ومقالات.
- ميزانيتك محدودة وعايز تبدأ بسرعة.
- محتاج إضافات جاهزة (متجر، حجز، نشرة بريدية).
الموقع المخصص يناسبك لو
- عندك طريقة شغل مختلفة والنظام لازم يتبعها.
- محتاج سرعة عالية جداً — المخصص أسرع بفرق واضح.
- هتربط بأنظمة تانية بشكل معقد.
- الأمان أولوية (بيانات عملاء أو مدفوعات).
الفرق في التكلفة على المدى الطويل
ووردبريس أرخص في البداية بس بيحتاج تحديثات وصيانة مستمرة، وكل إضافة بتضيف خطر أمني. المخصص أغلى في البداية وأهدأ بعدين.
الخطأ الشائع: البدء بووردبريس عشان أرخص، وبعد سنة إعادة بناء كل حاجة مخصص. لو عارف إنك هتكبر، ابدأ صح.
قارن بالدليل مش باسم التقنية
الاختيار الصح بيتحدد بالمخاطر والملكية والتغييرات المتوقعة خلال سنتين، مش باسم التقنية وحده. قيّم كل بديل على نفس المتطلبات: سرعة الإطلاق، تخصيص دورة العمل، الأمان، ملكية المحتوى، الربط، الدعم وتكلفة الانتقال لاحقًا.
اطلب تجربة صغيرة لأصعب متطلب قبل التعاقد على المشروع كله. واتأكد مين يملك ملفات المصدر والدومين والحسابات وتصدير البيانات. السعر القليل في البداية بيبقى غالي لو الشركة مش قادرة تنقل محتواها أو بياناتها من غير ما تبدأ من الصفر.
- استخدم قائمة متطلبات واحدة مع كل بديل أو مقدم خدمة.
- اختبر أصعب Integration أو Workflow قبل الالتزام الكامل.
- احسب تكلفة الملكية لسنتين بما فيها الدعم والانتقال.
- اكتب الملكية والصلاحيات وشروط الخروج في العقد.
قائمة تنفيذ خاصة بالموضوع
- اختار WordPress لما سرعة النشر وسهولة المحرر أهم من Workflow غير معتاد.
- اختار Custom لما الصلاحيات أو الربط أو المعاملة الأساسية ما ينفعوش داخل Plugins متصانة.
- في الحالتين حدد مسؤول التحديثات والـStaging والـBackup ومراقبة الأمان.
- اطلب تجربة Export كاملة عشان المحتوى والبيانات يفضلوا قابلين للنقل.
تفاصيل أغلب العروض بتفوتها
مقارنات الشركة أو التقنية بتفشل لما تقارن أسماء بدل سيناريوهات الفشل. الأسئلة الأصعب: مين يقدر يعدّل بأمان؟ العطل بيتشخّص في قد إيه؟ إيه البيانات اللي تتصدر؟ وإيه اللي يحصل لو الشخص أو المنصة الأصلية بقوا غير متاحين؟
- Requirement Scorecard موزونة حسب خطر البيزنس، مش عدد المميزات.
- Proof of Concept لأصعب Workflow أو Integration.
- ملكية واضحة للدومين والـRepository والـProduction وAnalytics وحسابات الموردين.
- Maintenance Map تحدد مين يحدث الكود والمحتوى والمكتبات والاستضافة.
- Exit Test يصدّر المحتوى والبيانات التشغيلية بصيغة مفيدة.
طبقة التنفيذ اللي بتفرق مع TechMate
TechMate بتعتبر استقلال العميل جزءًا من الجودة. المشروع بيتنظم بحيث العميل يملك الصلاحيات والقرارات، وفي نفس الوقت يفضل التوثيق والبيئات وتاريخ الإصدارات مفهومين لأي فريق مؤهل.
- مسؤول تسليم واحد يربط التصميم والمحتوى والبرمجة.
- Trade-offs مكتوبة بدل ادعاء إن كل اختيار مناسب لكل حالة.
- عرض كل مرحلة برحلة العميل، مش Screens منفصلة.
- Risk Register للربط والنقل وحدود الخدمات الخارجية.
- حدود الدعم ومسار التصعيد مكتوبين قبل الإطلاق.
مراحل تنفيذ تقلل المخاطرة
تعامل مع القرار كـDue Diligence صغيرة. ابدأ بالمخاطر صعبة الرجوع، واختبر أصعب متطلب، ووضح الملكية قبل مقارنة جمال العروض.
- اكتب النتائج الإلزامية والفشل غير المقبول.
- وزن المعايير حسب أثرها التشغيلي والمالي.
- اطلب دليلًا لأصعب متطلب.
- راجع الملكية والأمان والدعم وشروط الخروج.
- ابدأ بمرحلة مستقلة قابلة للاستلام.
أسئلة تكشف جودة التنفيذ
- مين يغطي الشخص الأساسي لو غاب؟
- هل فريق آخر يقدر ينشر من الـRepository المستلمة؟
- إيه Data Export اللي اتجربت فعلًا؟
- أنهي Limit غالبًا هيأثر على المشروع؟
- إيه الخارج صراحةً من الدعم بعد الإطلاق؟
سيناريو واقعي يوضح الفرق
مثال: موقع نشر من 6 صفحات يستفيد من سهولة WordPress. محرك تسعير بصلاحيات فروع ومخزون Live ممكن يتحول لسلسلة Plugins هشة. القرار يتبع الـWorkflow الأساسي مش شهرة الأداة.
مصادر مرتبطة مباشرة بالموضوع
عندك سؤال المقال مردّش عليه؟
ابعتهولنا. بنرد بجد، سواء اشتغلت معانا في الآخر أو لأ.



