LUXWATCH
أخرجنا متجرًا من رسائل إنستغرام، وأعطينا فريقه نظامًا يديره دون مطوّر.
كانت كل عملية بيع محادثة يدوية في الرسائل. الآن يعمل المتجر بكتالوج ثنائي اللغة، ومخزون لكل قطعة على حدة، ودورة حياة للطلب من عشر حالات، ولوحة تحكم من 59 صفحة يديرها الفريق بنفسه.
- التصنيف
- تجارة إلكترونية
- الموقع
- luxwatchs.store
- السنة
- 2026
- التقنيات
- Next.js 14 (App Router)
- React Server Components
- React 18
- TypeScript 5.5
- PostgreSQL (Neon, eu-central-1)
- Prisma
- Tailwind CSS
- NextAuth v4
- Zod
- Vercel (Frankfurt)
- Vercel Blob
- Cloudflare
- Resend
- SMSMisr
- Paymob
المشكلة
كانت كل عملية بيع تبدأ بمحادثة يدوية. ما المتوفر، وكم السعر، وهل تصلون إلى هنا، وهل ما زالت متاحة — تُكتب من جديد لكل عميل، على يد شخص، وفي ساعات صحوه هو. لم يكن هناك كتالوج يُتصفَّح ولا شيء تفهرسه Google، فكان على كل مشترٍ أن يعرف بوجود المتجر مسبقًا. و«أين طلبي» كانت رسالة أخرى.
والدفع عند الاستلام زاد الأمر سوءًا بدل أن يسهّله. لا شيء يُتحقَّق منه عند إتمام الطلب، فرقم خاطئ واحد في الهاتف أو مكالمة لم يُرَدّ عليها يعني أن المندوب دُفع له مرتين، وأن البيعة ضاعت في الغالب.
ولم يكن هناك نظام مخزون أصلًا. أي ساعة بعينها ذهبت إلى أي عميل؟ سؤال لم يكن له جواب. وفي الموقع الذي سبق إعادة البناء كانت كل صفحة تُولَّد من قاعدة البيانات من جديد مع كل ضغطة — سطر واحد طبّق العرض الديناميكي على كل المسارات، حتى صفحة الأسئلة الشائعة كانت تُبنى من الصفر مع كل طلب. قيس زمن عرض صفحة المنتج على الخادم فكان 1,070 مللي ثانية، واتضح أن السبب طابور انتظار على اتصالات قاعدة البيانات لا بطء في الاستعلامات.
«كل ضغطة تستغرق من 1 إلى 5 ثوانٍ.»
الحل
- استبدلنا محادثة الرسائل بكتالوج بالإنجليزية والعربية — بتخطيط معكوس من اليمين لليسار، وبقاعدة كود واحدة لا موقع ثانٍ — مع تصفية حسب الماركة والجنس ونوع الحركة والسعر، وبحث ثنائي اللغة، وقائمة أمنيات ومقارنة.
- إتمام الطلب كزائر دون حساب، لأن معظم عملاء الدفع عند الاستلام لا يسجّلون أبدًا.
- تتبّعنا كل ساعة فعلية كسجل مستقل برقم تسلسلي ورمز قابل للمسح، فيصبح «متوفر» عددًا لقطع حقيقية لا يمكن أن ينحرف.
- بنينا دورة حياة للطلب من عشر حالات مع إسناد المندوبين وسجل التوصيل، وإلغاء ذاتي للعميل حتى لحظة تغليف الطلب، وتتبّع ذاتي برقم الطلب دون تسجيل دخول.
- جمعنا التوصيل في إجراء واحد لا يتكرر أثره: تاريخ التسليم، ونقاط الولاء، ونافذة الإبلاغ عن العيوب، والبريد والرسالة النصية معًا، أو لا شيء منها. زرّان منفصلان في لوحة التحكم يستدعيان الإجراء نفسه، فلا يمكن أن يختلفا.
- أضفنا مسار إبلاغ عن العيوب واسترداد بأدلة مصوّرة ونافذة مطالبة ثابتة مدتها 14 يومًا.
- جعلنا رقم هاتف ثانٍ حقلًا أساسيًا في كل طلب، لأن المكالمة التي لا يُرَدّ عليها هي السبب الرئيسي لفشل التسليم بالدفع عند الاستلام.
- سلّمنا لوحة تحكم من 59 صفحة و30 وحدة إجراءات على الخادم، بثماني صلاحيات للموظفين كل منها محدودة بنطاقها، وسجل تدقيق كامل. تغيير الصلاحية يسري خلال 60 ثانية لا عند تسجيل الدخول التالي.
- وحّدنا الدعم في صندوق وارد واحد: نموذج التواصل، والبريد الوارد، ومحادثات روبوت الدردشة في مكان واحد.
- وضعنا روبوت دردشة يقرأ قيمًا حية من قاعدة البيانات — سعر الشحن الفعلي، والسياسات الفعلية، والمخزون الفعلي — بمستويين لرؤية البيانات، وتحويل إلى شخص بعد ثلاث محاولات فاشلة.
- نقاط الولاء تُضاف عند التسليم لا عند إتمام الطلب، وتُستبدل عبر خطوة موافقة تُصرف رصيدًا في المتجر.
- أعطينا كل اتصال خارجي مهلة محددة، حتى لا يُفشل طرف ثالث بطيء عملية نجحت بالفعل.
- طابقنا أسماء الماركات دون اعتبار لحالة الأحرف، فتبقى الماركة المكتوبة بثلاث طرق ماركة واحدة بدل أن تقسم الكتالوج ثلاث مرات.
- أضفنا لاحقة تلقائية لأسماء المنتجات المكررة بدل أن يظهر خطأ قاعدة بيانات خام لمن يضيف المنتج.
- ضبطنا بيانات وصفية وروابط أساسية لكل صفحة في كل المسارات، وستة أنواع من البيانات المنظّمة، وخريطة موقع ثنائية اللغة مع hreflang.
النتيجة
البيع الزائد عن المخزون مستحيل: الساعة إما محجوزة داخل معاملة أو غير محجوزة. تعليم الطلب كمُسلَّم إما يتم كله أو لا يتم، فلا يخسر العميل نافذة المطالبة أو نقاطه بسبب تحديث نصف مكتمل. المشرف الذي تُسحب صلاحيته يفقد الوصول خلال 60 ثانية. ولا أحد يحتاج إلى مطوّر لتشغيل أي من ذلك — المنتجات والمخزون والطلبات والمندوبون والخصومات والمحتوى والحملات والولاء والدعم كلها في يد الفريق.
عن الأرقام
لا أرقام أعمال منشورة، لأن شيئًا منها لم يُقَس كما ينبغي. لا يوجد خط أساس سابق لساعات الفريق في الرد على الرسائل، وتغيّر الإيرادات ليس شيئًا يُنشر على صفحة عامة، وبيانات الأداء من المستخدمين الحقيقيين بدأت تتراكم مؤخرًا فقط — وأي رقم من جهاز مطوّر على اتصال سريع لا يشبه في شيء عميلًا على بيانات الجوال في الإسكندرية. كل ما سبق عبارات عن طريقة بناء النظام، يمكن التحقق منها اليوم. الأرقام ستظهر هنا حين تكون من النوع الذي يصمد أمام السؤال.
ما بداخله
واجهة المتجر والتصفّح
- كتالوج كامل بهيكل الماركات والمجموعات والفئات والوسوم
- تصفية حسب الماركة والجنس ونوع الحركة والسعر، مع شريط سعر بمقبضين
- بحث في الأسماء والماركات والأوصاف بالإنجليزية والعربية
- الوصول الجديد، والأكثر مبيعًا، والعروض، وعرض لكل مجموعة
- كل تصفية تعيش في الرابط: قابلة للمشاركة والحفظ، وزر الرجوع يعمل معها بشكل صحيح، وقابلة للفهرسة، فيصبح العرض المصفّى صفحة يمكن أن ترتّبها Google
صفحات المنتجات
- معارض صور مع دعم الفيديو
- مواصفات خاصة بالساعات: الحركة، ومادة الهيكل ومقاسه، والسوار، والميناء، ومقاومة الماء، والضمان
- قائمة مميزات منتقاة يختار منها الفريق، حتى لا يتفتت الكتالوج إلى ست طرق لكتابة الخاصية نفسها
- مخزون حي مشتق من القطع الفعلية لا من عدّاد
- تقييمات العملاء مع متوسط التقييم، وأسئلة وأجوبة علنية عن المنتج
- بيانات منظّمة، فيصبح السعر والتوفر والتقييم مؤهلة للنتائج المنسّقة
السلة وإتمام الطلب
- إتمام الطلب كزائر دون حساب، وهذا مهم حين لا يسجّل معظم العملاء أبدًا
- سلة محفوظة للعملاء المسجّلين، وسلة للزوار
- أكواد خصم، بنسبة أو بمبلغ ثابت، بحدود استخدام وتاريخ انتهاء
- استخدام رصيد المتجر
- شحن بسعر ثابت قابل للضبط وحدّ للشحن المجاني
- دفتر عناوين، مع رقم تواصل ثانٍ كحقل أساسي
الدفع والتنفيذ
- الدفع عند الاستلام من البداية إلى النهاية
- ربط البطاقات والمحافظ مبني ومتوقف خلف مفتاح تشغيل
- دورة حياة للطلب من عشر حالات: قيد الانتظار، مؤكد، مغلّف، مشحون، مُسلَّم، مكتمل، إضافة إلى ملغى، ومسترد، ومرتجع
- إلغاء ذاتي للعميل حتى لحظة تغليف الطلب
- سجلات للمندوبين مع الإسناد ومنطقة التغطية وسجل التوصيل
- تتبّع الطلب برقمه دون تسجيل دخول
- مسار منظّم للإبلاغ عن العيوب والاسترداد بأدلة مصوّرة ونافذة مطالبة ثابتة
الحسابات والولاء
- التسجيل وتسجيل الدخول واستعادة كلمة المرور
- سجل الطلبات وتفاصيل الطلب
- قائمة أمنيات وأداة لمقارنة المنتجات
- نقاط ولاء تُكتسب عند التسليم لا عند إتمام الطلب، وتُستبدل عبر خطوة موافقة تُصرف رصيدًا في المتجر
- تفضيلات الإشعارات والتسويق محفوظة بشكل منفصل للبريد وللرسائل النصية
الإدارة والتشغيل
- إنشاء المنتجات وتعديلها بلغتين، مع رفع الصور وإعادة ترتيبها
- قطع مخزون مستقلة، لكل منها رقم تسلسلي ورمز قابل للمسح
- مخزون عبر عدة مستودعات، مع سجل حركة المخزون
- إدارة الطلبات: تغيير الحالة، وإسناد المندوب، والملاحظات الداخلية
- سجلات العملاء وسجل طلباتهم
- أكواد الخصم والإعلانات، وكلاهما قابل للجدولة
- صفحات المحتوى ومقالات المدونة، بلغتين
- حملات بريد ورسائل نصية مع سجل لكل إرسال
- صندوق دعم موحّد: نموذج التواصل والبريد الوارد ومحادثات روبوت الدردشة في مكان واحد
- مراجعة مطالبات الاسترداد
- مستويات الولاء والمكافآت وموافقات الاستبدال
- مكتبة وسائط وتقارير
- ثماني صلاحيات للموظفين، كل منها محدودة بمجالات بعينها
- سجل تدقيق كامل لمن غيّر ماذا، لا يراه إلا المالك
المحتوى والبحث
- ست صفحات ثابتة من قاعدة البيانات، بلغتين، يعدّلها الفريق
- مدونة بمقالات ثنائية اللغة
- بيانات وصفية وروابط أساسية لكل صفحة في كل المسارات
- ستة أنواع من البيانات المنظّمة: المؤسسة، والبحث في الموقع، والمنتج، ومسار التنقل، والأسئلة الشائعة، وقوائم العناصر
- خريطة موقع مولّدة من قاعدة البيانات، تذكر كل رابط مرة لكل لغة مع الربط بين النسختين، إضافة إلى x-default
- ملف robots.txt مدعوم بترويسات الاستجابة، فتُستبعد المسارات الخاصة بالفرض لا بالطلب
- صور مشاركة بمقاسات WhatsApp وFacebook، وهما بالنسبة لمتجر مصري أهم بكثير من Twitter
التعريب
- إنجليزية وعربية كاملتان في واجهة المتجر ومحتوى الإدارة ورسائل النظام
- تخطيط من اليمين لليسار، معكوس بالكامل لا مجرد نص محاذى لليمين
- نسخة واحدة من كل مسار: الوسيط يزيل بادئة اللغة ويمرّر اللغة، فتعرض /shop و/ar/shop الملف نفسه
- اختيار اللغة محفوظ، والرابط يتقدّم دائمًا على التفضيل المحفوظ
- المحتوى العربي للمنتج اختياري ويرجع إلى الإنجليزية، فيمكن نشر المنتج فورًا وترجمته لاحقًا بدل أن يتعطّل
- الجنيه المصري في كل مكان، عملة واحدة عن قصد لا عن سهو
الأداء والأمان
- إعادة توليد ثابتة تدريجية لكل مسار بدل إعداد عرض ديناميكي شامل؛ الصفحات التي يجب أن تكون محدّثة تخرج تلقائيًا بقراءتها للطلب، فلا توجد قائمة استثناءات يدوية يمكن الخطأ فيها
- تشخيص صفحة منتج بطيئة حتى الوصول إلى طابور انتظار على اتصالات قاعدة البيانات لا إلى تعقيد الاستعلامات — الاستعلامات كانت سريعة وتنتظر اتصالًا
- ضبط مجمّع الاتصالات، ونقل الدوال إلى منطقة قاعدة البيانات نفسها
- صور بصيغ حديثة وبمقاسات مناسبة لكل جهاز، مع حجز أبعادها لمنع اهتزاز التخطيط
- ترويسات أمان تُضبط من الخادم الأصلي لا من شبكة التوزيع فقط، تشمل سياسة أمان المحتوى وHSTS والحماية من النقر المخادع
- تحديد معدّل الطلبات عبر قاعدة البيانات، لأن نسخ الخوادم عديمة الحالة لا تتشارك الذاكرة
- جدار حماية لتطبيقات الويب وقواعد للروبوتات على الحافة
الأتمتة
- بريد ورسائل نصية تلقائية عند تأكيد الطلب وشحنه وتسليمه
- إجراء تسليم واحد يسجّل التاريخ، ويضيف نقاط الولاء، ويفتح نافذة الإبلاغ عن العيوب، ويرسل الإشعارين
- لكل اتصال خارجي مهلة محددة، فلا يُفشل طرف ثالث بطيء عملية نجحت بالفعل
- إبطال الذاكرة المؤقتة تلقائيًا حين يعدّل الفريق المحتوى
- روبوت دردشة يجيب من قيم حية في قاعدة البيانات — سعر الشحن الفعلي، والسياسات الفعلية، والمخزون الفعلي — لا من نص ثابت، بنموذج رؤية من مستويين وتحويل إلى شخص بعد تكرار الفشل
- خريطة الموقع تُعاد توليدها من قاعدة البيانات
- سجل لكل إرسال بريد أو رسالة نصية، فيصبح سؤال «هل وصل الإشعار للعميل؟» له جواب
المفاضلات التي اخترناها
ساعات مستقلة، لا رقم مخزون
النموذج البديهي صف واحد للمنتج مع كمية. نحن فصلناه: المنتج هو العرض، وكل ساعة فعلية سجل مستقل له رقم تسلسلي وتكلفة شراء وحالة ووضع.
جعل ذلك البيع أصعب بشكل ملموس — حجز قطعة، وربطها بالطلب، وتعليمها كمباعة، داخل معاملة واحدة — في حين كان يمكن أن يكون سطرًا واحدًا ينقص رقمًا.
لكنه يمنح أربعة أشياء لا يمنحها غيره: تتبّع الأرقام التسلسلية؛ والهامش الحقيقي لكل قطعة، لأن ساعتين متطابقتين اشتُريتا بفارق أشهر تختلف تكلفتهما؛ وحالة كل قطعة؛ والقدرة على الإجابة عن «في أي طلب شُحنت هذه الساعة بعينها؟» حين تعود إحداها بخدش.
لمتجر قمصان سيكون هذا إفراطًا في الهندسة، ولن نبنيه.
الطلب لقطة، لا مجموعة مؤشرات
بنود الطلب تحفظ اسم المنتج ورمزه وسعره كنسخ بدل أن تبحث عنها. هذا من الناحية التقنية تكرار للبيانات، وهو مقصود: لو ارتبط الطلب بالمنتج الحي، لغيّر رفع السعر بأثر رجعي ما يبدو أن العملاء السابقين دفعوه.
هذا ليس خطأ عرض، بل تزوير لسجلاتك المحاسبية. ورابط المنتج قابل لأن يكون فارغًا للسبب نفسه: الطلب يبقى حتى لو حُذف المنتج.
أشياء لم نبنها، عن قصد
لا Redis، ولا طابور مهام، ولا خدمات مصغّرة، ولا GraphQL. لكل منها شرط مكتوب يحدد متى يصبح جديرًا بالإضافة: تزاحم مقيس، أو حجم طلبات محدد، أو انقسام في الفريق.
بناء أي منها الآن يعني دفع ثمن تعقيد لا يُستخدم، والتخمين الخاطئ لأي الأجزاء ستهم.
تريد التفاصيل وراء هذا المشروع — القرارات والمفاضلات وما كنا سنفعله بشكل مختلف؟ اسألنا مباشرة.
المشروع التالي