خدمة
تطوير تطبيقات ويب مخصصة
منصات تصمد تحت حمل حقيقي وبيانات حقيقية ومستخدمين حقيقيين.
الويب هو المكان الذي يعيش فيه معظم ما نبنيه: منصات داخلية تدير أعمالاً، وبوابات للعملاء، ولوحات معلومات فوق بيانات تشغيلية حقيقية، ومواقع عامة يجب أن تكون سريعة وقابلة للعثور عليها. تُبنى كتطبيقات لا تُجمَّع من إضافات، وهذا ما يبقيها قابلة للتغيير بعد عام.
القرار
متى يكون هذا هو القرار الصحيح.
نادراً ما يكون القرار بين بناء مخصص ولا شيء. إنه بين بناء مخصص ومنصة مع الإضافات اللازمة لسد الفجوة بين ما تفعله وما تحتاجه. تلك الكومة رخيصة البدء باهظة الامتلاك: كل إضافة اعتمادية وكلفة أداء ومساحة أمنية، والتجمّع كله ينكسر مع الإصدار الكبير التالي للمنصة.
التكلفة الثانية هي السقف. البناءات القائمة على المنصات سريعة حتى أول متطلب تعجز المنصة عن التعبير عنه، ثم يصبح الالتفاف هو البنية. وينتهي الأمر بالشركات وهي تعيد تشكيل نفسها حول برمجياتها بدل العكس، وهو بالضبط الوضع الذي اشتُريت البرمجية لتفاديه.
يستحق البناء المخصص كلفته حين يكون منطق المجال هو المنتج، أو حين يكون نموذج البيانات ملكك فعلاً، أو حين يبلغ الأداء والتكامل حداً يجعلهما قرارات هندسية. وحين لا ينطبق أيٌّ من ذلك نقولها — فمنصة مختارة بعناية جواب أفضل من بناء كنا سنستمتع به أكثر.
ما الذي تحصل عليه
ما الذي يشمله العمل.
بنية تصمد مع النمو
نموذج البيانات والحدود والنشر تُحسم قبل أول شاشة، لأن هذه هي القرارات التي يكلف التراجع عنها كثيراً.
معالجة على الخادم حيث يهم ذلك
صفحات يستقبلها الزاحف والهاتف البطيء كاملةً، مع تفاعلية تُضاف فوقها لا تُشترط لظهور المحتوى.
تفويض حقيقي
تُفرَض الصلاحيات على الخادم عند كل طلب، لا بإخفاء عناصر القائمة. وتتحقق منها اختبارات تحاول كسرها.
الأداء بوصفه ميزانية محددة
تُعامَل مؤشرات Core Web Vitals كقيد بناء مرتبط برقم، لا كتقرير يُشغَّل بعد الإطلاق.
إتاحة مدمجة من البداية
مسارات لوحة المفاتيح وإدارة التركيز والتباين والدلالات من أول مكوّن، وهو أرخص من إضافتها لاحقاً وأفضل لمحركات البحث أيضاً.
قابل للتشغيل في بيئة الإنتاج
التسجيل والإبلاغ عن الأخطاء والنسخ الاحتياطي واستعادة مُجرَّبة، لأن برمجية لا يمكن تشغيلها ليست منتهية.
التقنيات
بماذا نبنيه.
تُختار لكل مشروع. لا شيء هنا يُفرَض افتراضياً، والفريق الذي سيصونها يزن بقدر المشكلة نفسها.
الواجهة الأمامية
TypeScript مع React أو قوالب تُعالَج على الخادم، تُختار لكل مشروع. لا يُفرَض إطار عمل افتراضياً.
الواجهة الخلفية
Python أو Node أو .NET، تُختار بالنظر إلى الفريق الذي سيصونها بقدر النظر إلى المشكلة نفسها.
البيانات
PostgreSQL أو MySQL، بمخطط مصمم لا مولَّد. وRedis حيث يفيد التخزين المؤقت فعلاً.
البنية التحتية
Linux وnginx، وحاويات حيث تستحق تعقيدها — على سحابتك أو على سحابتنا.
التسليم
إدارة إصدارات واختبارات آلية وخط نشر من اليوم الأول، لا تُضاف حين يبدأ الألم.
مقارنة
البناء على منصة مقابل بناء مخصص.
المقارنة التي يجدر إجراؤها قبل أن تكلّف أحداً بأي عمل. في شريحة كبيرة من المشاريع يفوز العمود الأيسر، وسنقول ذلك.
| الجانب | منصة + إضافات | بناء مخصص |
|---|---|---|
| الوقت حتى الحصول على شيء قابل للاستخدام | أيام. هذه ميزة حقيقية، وكثيراً ما تكون هي الحاسمة. | أسابيع. ولا تُبرَّر إلا حين تعجز المنصة عن التعبير عما تحتاجه. |
| شكل التكلفة | منخفضة ومتكررة: الترخيص، والنمو مع كل مستخدم، واشتراك كل إضافة، وشريك التنفيذ | مرتفعة ولمرة واحدة، ثم الاستضافة فقط. الشيفرة ملكك دون ترخيص تشغيل. |
| السقف | يُبلَغ عند أول متطلب تعجز المنصة عن التعبير عنه؛ ثم يصبح الالتفاف هو البنية نفسها | تحددها قراراتك التصميمية أنت، لا خارطة طريق جهة أخرى |
| مساحة الاعتماديات | كل إضافة هي شيفرة لم تكتبها، لها دورة إصدار خاصة بها، وتقع داخل محيطك الأمني | فقط المكتبات التي اخترتها وراجعتها وثبّتّ إصداراتها |
| ترقيات الإصدارات الكبرى | ما ينكسر هو تجمّع الإضافات، وينكسر وفق جدول جهة أخرى | أنت تقرر متى، والاختبارات تخبرك بما تغيّر |
| الأداء ومؤشرات Core Web Vitals | عبء القالب مع الإضافات، ويُعالَج بإضافة إضافة تخزين مؤقت أخرى | قيد بناء مرتبط برقم محدد، ويُفرَض داخل خط الإنتاج |
كيف يسير الأمر
من أول حديث حتى الإطلاق.
إرشادي لعمل بهذا الشكل. التجربة الأولية ليست اختيارية — ولا يُنقل شيء قبل أن يقول مستخدموه إنه يصمد.
- 1-2 أسبوع
الاستكشاف
نضع نموذج البيانات والأدوار أولاً. هنا تقيم التكلفة فعلاً، وهنا تخطئ البناءات القائمة على المنصات — لا في الشاشات.
- 4-8 أسابيع
البناء الأساسي
المسار الأكثر استخداماً من طرفه إلى طرفه، ببياناتك الحقيقية، وخط نشر من الأسبوع الأول لا حين يبدأ الألم.
- 2-3 أسابيع
تجربة أولية
يستخدمه فريق واحد في عمل حقيقي بينما تستمر العملية القديمة. وكل فجوة يصادفونها تُصلَح قبل نقل أي أحد آخر.
- 1-2 أسبوع
الإطلاق والتسليم
بقية المستخدمين والمراقبة ونسخ احتياطية باستعادة مُجرَّبة، مع التوثيق الذي يتيح لمطوّر آخر تسلّم العمل.
بعد الإطلاق
ما الذي يتغير.
- المتطلب الذي عجزت المنصة عن التعبير عنه لم يعد شخصاً يعالجه في جدول بيانات.
- يصبح أداء الصفحة رقماً في يدك، لا إضافة تأمل أنها تعمل.
- لم تعد الترقيات حدثاً، لأنه لا يوجد تجمّع إضافات لينكسر.
- تغيير تريده في الأسبوع الستين يكلف تقريباً ما كان سيكلفه في الأسبوع السادس.
وُصفت نوعياً عن قصد. نحن لا ننشر نسب تحسّن لا نستطيع نسبتها إلى عميل بعينه وبموافقته.
أسئلة
أسئلة شائعة.
كم يستغرق تطبيق ويب مخصص؟
منصة داخلية مركّزة تستغرق عادةً من ثمانية إلى أربعة عشر أسبوعاً من أول حديث حتى الإنتاج. أما الأنظمة الأكبر متعددة الوحدات فتستغرق وقتاً أطول وتُسلَّم على مراحل، بحيث تعمل الوحدة الأولى بينما تُبنى التالية — ونفضّل أن تستخدم شيئاً حقيقياً مبكراً على أن تنتظر كل شيء.
هل نملك الشيفرة؟
نعم، بالكامل، بما في ذلك المستودع وإعدادات النشر. لا يوجد ترخيص تشغيل ولا ما يمنع مطوراً آخر من تسلّم العمل.
هل يمكنكم العمل مع نظامنا الحالي؟
غالباً نعم. تبدأ معظم المشاريع بالتكامل مع شيء قائم بالفعل — برنامج محاسبة، أو نظام تخطيط موارد، أو قاعدة بيانات قديمة. واستبدال كل شيء دفعة واحدة نادراً ما يكون القرار الصحيح، والمسار التدريجي أكثر أماناً.
ماذا يحدث بعد الإطلاق؟
تتضمن الخدمة فترة دعم، وبعدها يختار معظم العملاء عقد متابعة للتعديلات والمراقبة. ولا يمثل أي منهما ارتباطاً إجبارياً: فالشيفرة ملكك وموثّقة بما يكفي ليتابعها شخص آخر.
ألا يجدر بنا أن نستخدم منصة جاهزة فحسب؟
في الغالب نعم. إذا كان نموذج بياناتك يناسب المنصة ولم تكن البرمجية هي ما يميّزك، فالمنصة أسرع وأرخص وسنقول ذلك. أما البناء المخصص فيستحق كلفته حين يكون منطق المجال هو المنتج، أو حين يكون نموذج البيانات ملكك فعلاً، أو حين يكون التكامل والأداء مشكلتين هندسيتين لا مجرد إعدادات.
ماذا يحدث إذا تغيرت متطلباتنا في منتصف الطريق؟
ستتغير، والخطة تفترض ذلك. تُعاد التقديرات عند حدود كل مرحلة بما تعلّمناه، ولهذا نفضّل سقفاً للسعر لكل مرحلة على سعر ثابت للنطاق كله — فالأخير إما مضخّم تحسباً للمخاطر أو متجه إلى نزاع مع أول تغيير.