صفحات مسارات بتترتّب، ومسار حجز يعيش في الطابور.

المسافر مش بيدوّر على «خدمة ترانسفير». بيدوّر على «من مطار القاهرة لفندق في الجيزة» — مسار محدد، غالباً على موبايل، وغالباً بعد النزول بدقايق والطابور ماشي وراه.

Easy Transfer 247 كان عنده الأسطول والتغطية اللي تخدم الطلب ده. بس الموقع كان بيوصف الترانسفيرات كخدمة عامة بدل ما يجاوب كل مسار كصفحة لوحده — فالبحث اللي المسافر كتبه بالظبط نادراً ما كان يلاقي صفحة يهبط عليها، والحجز اللي موجود كان طويل مش هيخلص قبل ما الطابور يتحرك.

البريف كان حاجتين في نفس الوقت: صفحة لكل مسار يهمّ، ومسار حجز قصير كفاية إنه يعيش في طابور المطار. واحدة من غير التانية مبتكسبش حاجة — زيارات من غير تحويل، أو فورم سريع محدش بيلاقيه.

التصميم والبرمجة والمحتوى كلهم اتعملوا داخلياً. مفيش باطن ومفيش تسليم بين فرق، وده اللي بيخلّي القرار المعماري يفضل واصل لآخر سطر كود.

متبني على ووردبريس مكتوب ببنية مسارات وschema على كل صفحة مسار بدل page builder — عشان كل مسار جديد ينزل بروابط نضيفة وبيانات منظّمة ونفس مسار الحجز القصير من غير ما حد يعيد بناءه بإيده. السرعة اتعاملت كمتطلب في البناء، مش مرحلة في الآخر.

النتيجة موقع المسافر بيلاقي فيه بالظبط المسار اللي دوّر عليه ويخلّص الحجز قبل ما الطابور يتحرك. دي الميكانيكا كلها. صفحات المسارات بتكسب البحث؛ المسار القصير بيكسب الحجز. ولا واحدة بتشتغل من غير التانية.