دراسة حالة · 2025
Rojaboom
منصة إلكترونية لحجز الإقامات عالية الجودة والفاخرة في إيران
مطوّر واجهات · من الصفر إلى منتج مُطلق
عرض الموقع المباشرrojaboom.vercel.app02 — من الصفر إلى الإطلاق
Version 1 في أقل من شهرين.
بدأ المشروع بموعد نهائي ضاغط: إيصال نسخة أولى قابلة للإطلاق وبمعيار مناسب في أقل من شهرين.
كانت تصاميم Figma تصل بالتوازي مع التطوير. البناء والتصميم تحرّكا معاً — والقرارات لم تثبت على لوحة مكتملة، فكان على الواجهة امتصاص التغيير الحقيقي أثناء الشحن.
- من الصفر إلى منتج قابل للإطلاق
- تصميم وتطوير متوازيان
- جودة معيارية لـ Version 1 تحت ضغط الوقت
- سرعة دون تفريغ أساس المنتج
03 — منصة واحدة، ثلاثة أدوار
Guest وHost وAdmin — ثلاث زوايا لمنتج واحد.
لم يكن روجابوم مجرد صفحة حجز. ثلاثة أدوار رئيسية حدّدت نطاق المنتج الحقيقي.
كنت مسؤولاً عن واجهتي Guest وHost. أُنجز لاحقاً لوحة Admin بـ Laravel بسبب ضيق الوقت الشديد.
Guest
البحث وعرض الإقامة واختيار التاريخ وإكمال مسار الحجز.
تجربة يجب أن تبدو بسيطة — حتى حين يكون التقويم والتسعير والتوافر تحتها.
Host
إنشاء الإدراج وإدارة الحجوزات والتقويم وبيانات العقار والعمليات المالية.
حيث يظهر عمق المنتج: لوحة تشغيلية لمضيفين حقيقيين.
Admin
طبقة الإدارة الداخلية للمنصة للعمليات والدعم.
بُنيت لاحقاً بـ Laravel تحت ضغط زمني شديد.
04 — تجربة المضيف
خلف تجربة بسيطة كان نظاماً كاملاً.
لم يكن المضيف «يضيف إقامة» فحسب. كان يدير الحجوزات والتقويم وبيانات العقار والمال في تدفق متصل.
كان يجب أن تكون لوحة المضيف واضحة وتشغيلية معاً: تدفقات متعددة الخطوات وجداول ديناميكية ونماذج بسيطة ومعقّدة وتفاعلات تطابق عمل المضيف اليومي.
- لوحة المضيف
- إدارة الحجوزات
- إدارة التقويم
- تفاصيل العقار
- العمليات المالية
- تدفقات متعددة الخطوات
05 — اثنا عشر خطوة لإدراج عقار
تدفق أعمال معقّد — وليس مجرد نموذج طويل.
كان إنشاء الإدراج من المضيف عملية من اثنتي عشرة مرحلة مترابطة يجب إكمالها بترتيب محدد.
خلال التطوير تغيّر هيكل المراحل والحقول المطلوبة وقواعد التحقق والاعتماد بين الخطوات وحتى ترتيب المعلومات مراراً. العمل الحقيقي كان إبقاء التدفق متماسكاً بينما المنتج ما زال يعرّف نفسه.
اثنتا عشرة خطوة مترابطة
- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 01
اعتماد المراحل
كل مرحلة تعتمد على بيانات وقرارات السابقة. لم يكن ممكناً معاملة التدفق كشاشات منفصلة.
- 02
متطلبات متغيّرة
تغيّر هيكل المراحل والمعلومات المطلوبة عدة مرات. كان يجب أن يبقى النظام قابلاً لإعادة الترتيب لا هشّاً.
- 03
تحقق حيّ
قواعد التحقق تحرّكت مع المنتج. كان يجب أن تبقى الأخطاء واضحة دون كسر مسار المستخدم.
- 04
إعادة ترتيب المعلومات
أُعيد ترتيب تجربة الاستخدام وأولوية الحقول أكثر من مرة. كان على معمارية التدفق امتصاص ذلك.
06 — تقويم بُني من الصفر
التقويم كان أحد أعمدة المنتج التقنية.
بُني تقويم روجابوم من الصفر — ليس كودجت تجميلي، بل كسطح تفاعل أساسي للحجز وإدارة التوافر.
هنا التقى تصميم التجربة والهندسة: اختيار المدى وتسعير كل يوم والأيام المحجوبة وأوضاع العرض وإدارة الحالة عبر تفاعلات حقيقية.
- 01
اختيار مدى
وضع المدى لمسار الحجز، بسلوك متوقع لبداية ونهاية وتعديل المدى.
- 02
سعر كل يوم
عرض الأسعار اليومية داخل التقويم نفسه — لا منفصلة عن قرار المستخدم.
- 03
أيام يحجبها المضيف
كان يجب أن تكون الأيام المحجوبة أو المشغولة مقروءة وموثوقة في اللحظة.
- 04
وضعان Single وDouble
وضعا عرض لسيناريوهات مختلفة لاختيار التواريخ وتصفّحها.
- 05
نافذة وصفحة كاملة
نفس التقويم يُفتح في Modal ويُعرض بالكامل في صفحة الإقامة.
- 06
العطل وحالة معقّدة
عرض العطل إلى جانب تفاعلات وإدارة حالة يحتاجها منصة حجز حقيقية.
07 — ثلاث وأربعون شاشة خلف التجربة
اتساع المنتج الحقيقي — لا بضع صفحات للعرض.
بلغت النسخة النهائية نحو 43 شاشة. الرقم أقل أهمية من نوع العمل الذي غطّته.
جمعت تلك الشاشات تدفقات حجز الضيف وواجهات تشغيل المضيف ونماذج خفيفة وثقيلة وجداول ديناميكية واختيار موقع على الخريطة وتدفقات متعددة الخطوات.
43
حجز الضيف
من اكتشاف الإقامة إلى اختيار التواريخ وإكمال الحجز.
إنشاء الإدراج وإدارته
تدفقات إنشاء بيانات العقار وتعديلها وصيانتها للمضيف.
عمليات المضيف اليومية
الحجوزات والتقويم واللوحة وقرارات المضيف اليومية.
النماذج والجداول
من النماذج البسيطة إلى المعقّدة، مع جداول ديناميكية.
تدفقات متعددة الخطوات
عمليات يجب أن تتقدّم مرحلة بمرحلة مع الحفاظ على الحالة.
الموقع على الخريطة
تفاعلات الخريطة لتحديد موقع الإقامة.
08 — الشحن تحت القيود
الشحن حين لا تكون البنية التحتية في صفّك.
جزء من التطوير والنشر جرى في ظروف إنترنت وبنية تحتية قاسية — انقطاع دولي وحدود سجلات الحزم ومشكلات مراكز البيانات.
هذه ليست قصة درامية. إنها مثال على حل المشكلات حين لا تكون الأدوات المعتادة متاحة والمنتج يجب أن يخرج رغم ذلك.
- 01
قطع الوصول
انقطاع الإنترنت الدولي وحدود السجلات أغلقا مسار التثبيت والنشر المعتاد.
- 02
عدم استقرار البنية
مشكلات مراكز البيانات والظروف غير المستقرة أخرجت التصحيح والنشر من الوضع الروتيني.
- 03
مسار نشر بديل
في أحد عمليات النشر الصعبة، نُشر المشروع بـ Liara CLI باستخدام مرايا سجلات محلية كبدائل لتثبيت الحزم.
كانت الخلاصة واضحة: جودة الهندسة لا تُقاس في الظروف المثالية فقط — بل أيضاً في القدرة على إخراج المنتج حين تكون القيود حقيقية.
09 — أبعد من الإطلاق
المنتج لم ينتهِ عند الإطلاق.
كانت Version 1 مجرد نقطة البداية. عمل روجابوم أكثر من سنة في بيئة حقيقية ومع حركة مرور حقيقية للمنصة.
خلال تلك الفترة استمرت الميزات الجديدة وإصلاح الأخطاء وتغيّر المتطلبات والاحتياجات التشغيلية على نفس الأساس.
- 01
إطلاق مضغوط
إيصال Version 1 إلى منتج قابل للاستخدام في أقل من شهرين.
- 02
استخدام حقيقي
أكثر من سنة مع مستخدمين وحجوزات وعمليات حقيقية على المنصة.
- 03
تكرار وصيانة
ميزات وإصلاحات واحتياجات متغيّرة وضغط تشغيلي يومي.
10 — حين تغيّر المكدس
الترحيل قرار تنظيمي — لا حكم تقني.
بعد أكثر من سنة نُقل المشروع بالكامل إلى Laravel.
هذه نقطة مهمة: لا ينبغي قراءة هذا الانتقال كفشل لـ Next.js. كانت نسخة Next.js سليمة تقنياً وعملت بشكل صحيح في الإنتاج.
اتُّخذ قرار الترحيل لأسباب تنظيمية وتشغيلية أكثر منه لعجز تقني في المكدس السابق.
ما الذي شكّل القرار
حاجة إلى دعم أسرع
كان العمل يحتاج تغييراً مستمراً واستجابة تشغيلية.
تنسيق الواجهة والخادم
احتاجت الميزات الجديدة تنسيقاً أقرب بين الجانبين.
هيكل الفريق
كان في الفريق ثلاثة مطوّري Laravel؛ وخبرة الواجهة وحدها.
خفض المخاطر التشغيلية
أصبح الدعم والتطوير أبسط لفريق متمركز أصلاً على Laravel.
اختيار التقنية ليس مسألة قدرة تقنية فقط — بل يجب أن يتوافق أيضاً مع هيكل الفريق والعمليات واحتياج العمل.
11 — ما كان على عاتقي
نطاق المسؤولية الحقيقي.
من معمارية الواجهة إلى النشر — هذه الأجزاء التي حملتها فعلياً في المشروع.
- 01معمارية الواجهة
- 02تجربة Guest
- 03لوحة Host
- 04تدفقات الحجز
- 05تدفق إنشاء الإدراج
- 06التقويم المخصّص
- 07النماذج والتحقق
- 08جداول ديناميكية
- 09تفاعلات الخريطة
- 10الاتصال بـ API
- 11واجهة متجاوبة
- 12إصلاح الأخطاء
- 13النشر
لم يكن روجابوم مجرد إطلاق سريع.
كان تمريناً على شحن منتج حقيقي تحت ضغط الوقت والتغيير المستمر والقيود التشغيلية.