قبل كتابة أي كود، أبحث بعمق فيما يجب أن يقدمه المنتج ولمن يتم تصميمه. بالنسبة لتطبيق Birinia، كان هذا يعني فهم كيف يبيع الحرفيون المحليون في الجزائر ويتواصلون مع المشترين اليوم، وكيف يمكن لتطبيق يدعم اللغة العربية من اليمين إلى اليسار (RTL) بشكل أساسي أن يسهل هذه العملية.

أستفسر عن القيود مبكرًا — الأجهزة المستهدفة، طرق الدفع (بريدي موب، الدفع عند الاستلام)، متطلبات اللغة — حتى لا نحتاج إلى إعادة بناء هيكلية التطبيق لاحقًا.

أقوم بتخطيط نموذج البيانات قبل المساس بواجهة المستخدم — مخططات Convex، العلاقات، والفهارس — بالإضافة إلى هيكلية التوجيه في Expo Router أو Next.js.

هنا أحدد ما سيتم إطلاقه في الإصدار الأول مقابل ما سيتم تحسينه لاحقًا، مثل درجات الشهرة المحسوبة مسبقًا بدلاً من حسابها مع كل طلب.

يبدأ عمل واجهة المستخدم بالنظام، وليس بالشاشة: ملف لرموز التصميم، لوحات ألوان للإضاءة والظلام، ومكونات مشتركة تستمد منها جميع الشاشات.

بالنسبة لتطبيقات RTL، تحمل هذه المرحلة أهمية إضافية — التخطيطات المعكوسة، الوحدات الآمنة للاتجاهين، وترتيب العناصر كلها تُتخذ قراراتها هنا، وليس كترقيعات لاحقة.

يتم بناء الميزات من البداية إلى النهاية وإطلاقها في أجزاء صغيرة — شاشة دردشة، موجز صفحات، وتدفق مصادقة — بدلاً من بناء واجهة المستخدم بالكامل أولاً ثم المنطق.

تظل التقنيات ثابتة عبر المشاريع: Expo و Convex و NativeWind وغيرها للهواتف المحمولة؛ Next.js و Tailwind للويب. الأدوات المألوفة تعني مفاجآت أقل.

أجهزة حقيقية، وليس فقط محاكيات — يتم التحقق يدويًا من تسليم الإشعارات في خلفية أندرويد، استثناءات تحسين البطارية، وحالات RTL الصعبة (اتجاه النص، الأيقونات المعكوسة).

الأخطاء المكتشفة هنا هي التي لا تظهر أبدًا في النسخة التجريبية للعميل.

الإطلاق يعني الإرسال إلى المتاجر (تأكيد Play Console، وخطوات إثبات العنوان الخاصة بالجزائر)، وفحوصات بيئة الإنتاج، وتدفق دفع يعمل قبل أن يقوم أي شخص بتنزيل التطبيق.

بعد الإطلاق، أراقب تقارير الأعطال وتدفقات التحديث الإجباري لاكتشاف المشكلات قبل أن يلاحظ المستخدمون نمطًا معينًا.