Case studies

The problem

Most online orders in Egypt are paid cash on delivery, and a large share are refused at the door. The seller pays for shipping both ways and has stock tied up in transit, and there is no way to know in advance which orders will come back.

What we built

An API and dashboard that score each order the moment it is placed. Every score comes with a verdict (ship, confirm first, or ask for a deposit) and the top reasons in plain language, so the seller knows what to do and why.

How it works

• A CatBoost model trained on point-in-time features, so it never learns from information it would not have at order time.
• A rules scorecard takes over when a store has too little history for the model.
• A shared refusal signal across stores, built only from hashed phone numbers. Raw numbers are never stored, in line with Egypt's data protection law.
• Per-store models, retraining and performance charts in the dashboard.
• The dashboard runs in Arabic and English with full right-to-left support, plus dark mode.

How we keep it working

• 205 automated tests (pytest) run on every change in GitHub Actions, next to a security scan.
• Docker Compose deployment: API, web app, PostgreSQL and nginx.
• A one-command bootstrap that recreates the same demo data and model for anyone who clones the project.

The problem

Factories in Egypt often run stock, accounts and staff on spreadsheets, or on foreign systems that fight Arabic, local tax rules and the way a factory floor actually works.

What we built

One platform that serves many companies, each with its own set of modules, roles and fields chosen from templates. Staff record goods in and out, print receipts and barcode labels, post journal entries and manage attendance, all in Arabic with English as a second language.

How it works

• Each company's data is walled off by row-level security inside PostgreSQL itself, not just by application code.
• The stock ledger is append-only: mistakes are fixed with reversing entries, never edits, so the history is always complete.
• Money is stored as whole piastres, never as floating-point numbers.
• Roles and permissions per company, two-factor sign-in for sensitive roles, and an audit log that records every change and who made it.
• Designed around Egyptian e-invoicing and data protection rules from day one.

How we keep it working

• Over 1,000 unit tests, plus architecture checks that fail the build if a module reaches into another module's internals or a table misses its security policy.
• End-to-end tests in Playwright that run the real app in Arabic, right to left.
• An attendance importer built and tested against the client's real monthly file.

The problem

Small businesses lose hours every day confirming orders and bookings by phone, checking supplier invoices line by line, and pulling sales numbers together by hand.

What we built

• OrderFlow: every new cash-on-delivery order gets a WhatsApp message with Confirm and Change buttons. Replies update the order and alert the owner on Telegram.
• BookingFlow: the same for clinic and salon bookings, with reminders before the appointment.
• InvoiceFlow: AI reads supplier invoices in Arabic or English, from a PDF or a photo. Code then checks the maths, VAT, totals and duplicates before anything is approved.
• ReportFlow: daily and weekly sales reports on Telegram, with short AI insights.

How it works

• Workflows are generated from source code by a builder script, so the four packs share tested building blocks.
• AI reads the documents, but every number it returns is checked in code before anyone relies on it.
• Buyers get setup forms, bilingual PDF guides and sample data to test with.

How we keep it working

• A full end-to-end test that installs each pack the way a buyer would and runs it against fake WhatsApp, Telegram and Gemini servers.
• A checker that verifies every pack and download before release.