نظام حجوزات ومدفوعات
استوديو كان يدير حجوزاته يدوياً ويخسر المواعيد للحجز المزدوج وسلال الدفع المهجورة. الآن يحجز الضيوف بأنفسهم — والتقويم لا يستطيع الكذب.
- الدور
- مطوّر وحيد، من البداية للنهاية
- التسليم
- تطبيق PWA قابل للتثبيت، دون تسجيل دخول
- التشغيل
- Airtable كنظام خلفي للفريق
المشكلة
كانت الحجوزات تعيش في تقويم يُدار يدوياً. شخصان يمكن أن يدفعا للموعد نفسه، وسلة دفع مهجورة يمكن أن تحجب موعداً لم يشترِه أحد، وكل خطأ ينتهي بمحادثة استرداد.
نظام الحجوزات يستحق وجوده بوعد واحد: التقويم لا يكذب أبداً.
ما بنيته
نظام واحد، أربعة خيارات مقصودة:
توفر لحظي مع حجوزات مؤقتة تنتهي تلقائياً
الموعد يُقفل لحظة بدء الدفع ويحرر نفسه تلقائياً إذا لم يكتمل — الحجز المزدوج يصبح مستحيلاً بنيوياً، لا مكروهاً إجرائياً.
مدفوعات Stripe
الدفع يحدث داخل مسار الحجز — يُؤكَّد الموعد بالضبط عندما يُؤكَّد المال، وليس قبل ذلك أبداً.
Airtable كنظام تشغيل خلفي
الفريق يدير الغرف والأسعار والحجوزات في أداة يعرفها أصلاً — دون لوحة إدارة تُبنى أو تُتعلَّم أو تُصان.
خدمة ذاتية للضيوف كتطبيق PWA
دون حساب، دون تسجيل دخول، دون متجر تطبيقات — يحجز الضيوف من المتصفح ويمكنهم تثبيته على الشاشة الرئيسية.
النتيجة
أنماط الفشل التي بُني النظام للقضاء عليها — اختفت:
- الحجز المزدوج: مستحيل بنيوياً — نموذج الحجوزات المؤقتة يمنعه، لا سياسة.
- سلال الدفع المهجورة تحرر مواعيدها بنفسها.
- الفريق يدير كل شيء من Airtable — صفر أدوات جديدة للتعلم.
التقنيات
Next.js 16 وReact 19 في الأمام، وStripe للمال، وAirtable للتشغيل. الهندسة المثيرة هي نموذج انتهاء الحجوزات المؤقتة، لا الحزمة.
هل يبدو هذا مألوفاً من تطبيقك؟
كل عمل هنا بدأ بالطريقة نفسها: تطبيق يعمل بالفعل، ومشكلة قرر أحدهم التوقف عن التعايش معها. الفحص هو الطريقة منخفضة المخاطر للبدء — وصول للقراءة فقط، تقرير مكتوب، وقائمة إصلاحات مرتبة حسب الأولوية.