I build backends
that don't drift,
don't leak, don't go down. أبني أنظمة خلفية
لا تنحرف حساباتها،
ولا تتسرّب، ولا تتوقّف.

• Expense claims are easy to game — the same receipt twice, a lightly edited image, one purchase claimed by two people. I built an explainable fraud engine: 8+ weighted checks per receipt producing an audited 0–100 score that routes to approve, review, or flag — every signal logged, so a reviewer sees why.
• Signals: SHA-256 and perceptual-hash duplicates (Hamming distance), EXIF tampering forensics, upload-velocity analysis, OCR-to-data cross-validation.
• Multi-tenant isolation with record-level permissions across manager, accountant, and employee roles.
• مطالبات النفقات قابلة للتلاعب — إيصال يُقدَّم مرتين، صورة معدّلة، مطالبة واحدة من شخصين. بنيت محرّك كشف احتيال قابلًا للتفسير: أكثر من 8 فحوص موزونة تنتج درجة 0–100 مُدقّقة توجّه الإيصال تلقائيًا — مع تسجيل كل إشارة، ليرى المدقّق السبب.
• الإشارات: بصمات SHA-256 وبصمات إدراكية، وتحليل EXIF، وسرعة الرفع، والمطابقة المتقاطعة بين OCR والبيانات.
• عزل كامل لبيانات كل شركة مع صلاحيات على مستوى السجل لأدوار المدير والمحاسب والموظف.

Frontend by Nour Aldeen Tofiتطوير الواجهة الأمامية: نور الدين توفي

• Auth ran through one SMS provider. When it went down, nobody could log in — not just new users, everyone re-authenticating. A provider outage was a total outage.
• I rebuilt OTP delivery as a switchable interface behind seven channels, selected from a settings table at runtime. No redeploy, no release — an outage became a config change taking seconds.
• One versioned API (v1/v2 in parallel) serving customer app, driver app, and admin panel, with timestamped task tracking, scheduled orders, deduplicated push, and revenue reporting.
• كانت المصادقة تعتمد على مزوّد رسائل واحد. وعند تعطّله يتوقف تسجيل الدخول للجميع لا للمستخدمين الجدد فقط. انقطاع المزوّد كان يعني توقّف الخدمة.
• أعدت بناء إرسال الـ OTP كواجهة قابلة للتبديل خلف سبع قنوات تُختار من جدول إعدادات لحظيًا. دون إعادة نشر — فصار الانقطاع إجراءً يستغرق ثوانٍ.
• واجهة API واحدة بإصدارات متوازية تخدم تطبيق الزبون والسائق ولوحة الإدارة، مع تتبّع المهام وطلبات مجدولة وإشعارات لا تتكرر وتقارير إيرادات.

• Every booking splits revenue between the platform and an independent office. Both shares must reconcile exactly — even when coupons and points subsidise the customer, and even when a rate changed after the booking was made.
• Solved in fixed-point BCMath: time-versioned per-office rates, platform-absorbed subsidies, rounding designed so the two shares always reconcile to the cent. Unit-tested on the money math specifically.
• Office wallets, settlements, referral chains, and price snapshotting — historical bookings never shift when prices change.
• كل حجز يقسّم الإيراد بين المنصة ومكتب مستقل، ويجب أن تتطابق الحصتان تمامًا — حتى مع الكوبونات والنقاط، وحتى لو تغيّرت النسبة بعد الحجز.
• الحل بحساب عشري ثابت (BCMath): نسب مؤرّخة لكل مكتب، ودعم تتحمّله المنصة، وتقريب يضمن التطابق دائمًا. مع اختبارات وحدة على منطق الأموال تحديدًا.
• محافظ للمكاتب وتسويات وسلاسل إحالة ولقطات أسعار — الحجوزات التاريخية لا تتغيّر عند تغيّر الأسعار.

• RESTful APIs behind internal platforms, with role-based access control across admin and staff areas.
• GitHub Actions CI/CD with atomic zero-downtime deploys across 4 projects on 3 servers — releases run mid-workday, rollback in seconds.
• Automated quotation generation into templated Excel files, replacing manual document prep.
• واجهات RESTful للمنصات الداخلية مع صلاحيات قائمة على الأدوار.
• خطوط CI/CD مع نشر ذرّي بدون توقف عبر 4 مشاريع على 3 خوادم — إصدارات في منتصف الدوام وتراجع خلال ثوانٍ.
• أتمتة توليد عروض الأسعار ضمن ملفات Excel وفق قوالب جاهزة.

• The three products above, end to end: API design, auth, payments logic, push notifications, documentation, deployment.
• المنتجات الثلاثة أعلاه، من الطرف إلى الطرف: تصميم الـ API والمصادقة ومنطق المدفوعات والإشعارات والتوثيق والنشر.