Hello, I'm Abdelrahman Ahmed Saeed — a Mobile Team Lead & Senior Mobile Engineer.

Apps that work where the signal doesn't.

Giza, Egypt · 8+ years · Open to senior & lead roles

For eight years I've built the systems companies actually run on: field-sales apps in the hands of hundreds of reps every day, the Laravel APIs behind them, and the production servers they talk to.

8+years building mobile
500+daily users on flagship
25+applications delivered
3layers I own: app, API, ops

About

I lead a mobile team, and I'm still the one in the code.

Since 2019 I've led mobile development at United Distributors, where I architected the company's core systems end-to-end. The flagship is Sales Book: an Android field-sales platform that 500+ retail and wholesale reps open every morning to take orders, manage van stock, run their routes, and print invoices at the customer's counter.

Field sales is an unforgiving place to ship software. Reps work in warehouses and back streets where connectivity disappears, on cheap devices, with a Bluetooth printer in the other hand — and a failed sync is a real order that never reached finance. That constraint shaped how I build everything since: offline-first, reconcile on sync, fail loudly and locally.

I don't stop at the app boundary. I build and maintain the Laravel APIs behind every mobile product, own the database layer, and handle daily production operations. Alongside that I built Just On Table — a complete two-sided restaurant marketplace, designed, coded, deployed and operated entirely on my own, which is the fastest way I know to stay honest about what "full lifecycle" really costs.

Selected work

Projects

The numbers below are measured from the codebases, not estimated.

Sales Book

Flagship Android · Java · Laravel · 2019–present

The company's sales backbone, architected and built end-to-end. Order taking, van-stock management, route visits, on-site Bluetooth invoice printing, customer and merchandising data capture, and automated target and incentive calculation. Built offline-first so reps keep selling with no signal and reconcile cleanly on sync, backed by a Laravel API I own down to the schema and wired into the corporate Odoo ERP.

500+ daily reps 167 Eloquent models 200+ endpoints offline-first sync thermal printing
The problem

A rep starts the day with a route, a van full of stock and a phone, and ends it owing the warehouse an exact account of what left the van and what came back. Every order, return and collection has to reconcile — and the places this happens, back streets and loading bays, are exactly where connectivity disappears.

What I built
  • Order capture with per-customer pricing, promotions and credit rules
  • Van stock treated as a moving warehouse — load out, sell, return, reconcile against the depot
  • Route and visit planning with GPS confirmation that a customer was actually visited
  • Bluetooth thermal invoice printing at the customer's counter
  • Automated target and incentive calculation, so commission stops being a spreadsheet argument
  • Merchandising and photo capture from the field
The hard part

Offline-first means the device is the source of truth until it syncs, so the interesting work is all in reconciliation: what happens when two devices touch the same stock, when a sync half-completes, when a rep's phone dies mid-route. A dropped order here is real money that never reached finance.

Stack
AndroidJavaSQLiteLaravelMySQLOdooBluetooth printing

Just On Table

Independent Flutter · Laravel 10 · Firebase

A complete two-sided restaurant marketplace — discovery, table booking, dine-in, delivery and takeaway ordering, payments, wallets and cashback, plus a merchant back office with analytics, role-based permissions and subscription billing. Two production Flutter apps against one Laravel API, with real-time chat spanning three Firebase projects. Designed, built, deployed and operated single-handedly.

~1,700 Dart files 171 OAuth2 endpoints ~90-model schema Android / iOS / web self-hosted production
The problem

Two audiences who want opposite things from the same data. A diner wants to find a table near them in seconds; a restaurant owner wants stock, staff, promotions and settlement. Built alone, which means every architectural shortcut would have been my own problem later.

What I built
  • Customer app: geo-search and discovery, table booking, dine-in / delivery / takeaway ordering, wallet, cashback, payments
  • Merchant app: menu and item management, tables, live orders, promotions, customers, dashboard analytics
  • Laravel API serving both apps from a single route table, secured with OAuth2
  • Real-time chat across three Firebase projects, with chat identity minted server-side
  • Firebase Phone Auth with the ID token re-verified by the backend, not trusted from the client
  • Verification steps switchable from a database row, with one gate every entry point consults
  • Production operation: Linux server administration, transactional email with SPF/DKIM/DMARC, an Astro marketing site
Read more

The full write-up — architecture, the auth hole I found and closed, and what running it in production actually taught me — is in the case study further down this page.

Stack
FlutterDartBlocLaravel 10MySQLFirebaseFirestoreAstroLinux

Sales Book — Flutter rebuild

Flutter · Clean Architecture · in progress

Leading the rewrite of the flagship onto a single cross-platform codebase: Clean Architecture with Bloc/Cubit, get_it dependency injection and dartz functional error handling. The hard parts carry forward natively — thermal receipt printing, Google Maps routing, GPS-verified customer visits, barcode scanning — replacing years of Android-only code with one Android and iOS build.

~790 Dart files 15 feature modules Bloc + get_it + dartz one codebase, two platforms
The problem

A decade of Android-only Java, one team, and a business that now wants iOS too. Rewriting the system the company runs on is not a project you get to do twice, so it has to stay shippable the whole way through rather than landing as one big-bang cutover.

What I built
  • Clean Architecture throughout: domain use cases, repository contracts, and data sources kept strictly separate
  • Bloc/Cubit for state, get_it for dependency injection, dartz Either for errors that must be handled, not thrown
  • 15 feature modules — orders, van stock, visits, promotions, merchandising, printing, products, search, settings and more
  • Native capability preserved: thermal receipt printing, Google Maps routing, geolocation, barcode and QR scanning
Status

In active development alongside the running Android system, which stays in reps' hands untouched until each module is proven.

Stack
FlutterDartBlocget_itdartzDioGoogle Mapsmobile_scanner

Talabya

Flutter · B2B ordering

Lets supermarkets and retailers order directly from the distributor, removing the phone-and-paper step between store and warehouse. Full catalog with faceted filtering, a promotion and special-discount engine, order timeline tracking, a dedicated sales-rep mode, and push notifications for order status.

promotion engine order timeline sales-rep mode FCM push
The problem

Orders arrived by phone call and handwritten note, which meant transcription errors, disputed quantities, and a sales rep acting as a human API between the shop and the warehouse system.

What I built
  • Product catalog with faceted filtering and search across the distributor's full range
  • Promotion and special-discount engine applying the right price per customer tier
  • Cart, checkout and order review with a visual order timeline from placement to delivery
  • Sales-rep mode so a rep can place and manage orders on a customer's behalf
  • Complaints and suggestions channel, plus Firebase push for every status change
Stack
FlutterDartBlocGetXLaravelFirebaseFCM

Sitterly

Flutter · Laravel 10

Two-sided childcare marketplace delivered as one ~470-file codebase on Clean Architecture, with the API built alongside it. Map-based sitter discovery, booking requests and scheduling, live baby-location tracking, a parent community feed, and encrypted on-device token storage.

The problem

Parents and sitters need opposite views of the same booking, and the trust bar is higher than any other marketplace I have built — the product is someone's child.

What I built
  • Role-split onboarding and profile setup, parent or sitter, from the same codebase
  • Map-based sitter discovery with availability and scheduling
  • Booking request flow with accept, decline and confirmation states on both sides
  • Live baby-location tracking for a booking in progress
  • Parent community feed, and encrypted on-device storage for auth tokens
Stack
FlutterBlocget_itDioflutter_mapLaravel 10MySQL

UD HR Self-Service

Flutter · ~210 Dart files

Company-wide employee app that retired paper HR workflows: geofenced attendance check-in hardened against mock-location and rooted devices, digital payslips, and the full request-and-approval chain for vacations, missions, overtime, short leave and social insurance.

The problem

HR ran on paper forms and physical signatures. The moment attendance moves to a phone, the question stops being convenience and becomes trust: how do you know the check-in happened where it claims to?

What I built
  • Geofenced attendance check-in validated against mock-location and rooted-device detection
  • Digital payslips available on the device instead of by request
  • Request and approval chain for vacations, missions, overtime, short leave and social insurance
  • Push notifications for approvals so a request is not waiting on someone remembering to look
Stack
FlutterGetXFirebaseFirestoregeolocatorsafe_deviceLaravel

WHRSbook

Flutter · warehouse ops

Purchase- and release-order handling for warehouse staff, built on Bloc with barcode scanning for line entry, QR generation, shareable receipt capture, and a fully bilingual Arabic/English interface.

The problem

Warehouse staff type least accurately exactly when they are busiest, and the cost of a wrong line on a release order is a wrong pallet on a truck.

What I built
  • Purchase order and release order flows built for speed over decoration
  • Barcode scanning for line entry, so quantities and SKUs are read rather than typed
  • QR generation and screenshot-based receipt capture for sharing a completed order
  • Full Arabic/English localisation including layout direction
Stack
FlutterBlocget_itDiomobile_scannerqr_flutter

Mobile–ERP integration

Java desktop · Odoo

The synchronization layer keeping the mobile estate and the corporate ERP in agreement — customers, sales orders, invoices, stock and HR data moving in both directions, so field activity lands in finance without manual re-entry.

The problem

The mobile system and the ERP each believed they owned the truth about customers, stock and invoices. Without a bridge, finance was re-keying field activity by hand.

What I built
  • Bidirectional synchronisation of customers, sales orders, invoices, stock and HR records
  • Scheduled sync jobs with error reporting, so a failed batch is visible rather than silent
  • Field mapping and conflict handling between two schemas that were never designed together
Stack
JavaDesktopMySQLOdoo

Customer service chat

Web + mobile · real-time

Live support platform letting agents answer customer inquiries in real time from a web console while customers stay inside the mobile app.

The problem

Support ran through phone calls and inboxes, so nobody could see a conversation's history and customers repeated themselves to every new agent.

What I built
  • In-app chat for customers, with the conversation kept in one thread
  • Web console for agents to handle several conversations at once
  • Real-time delivery so neither side is refreshing to see a reply
Stack
WebMobileReal-time messagingLaravel

Elite Capital

WordPress · real estate

Real-estate marketing portal covering 50+ property types with locations, floor plans and full facility details.

The problem

A developer's whole catalogue needed to be browsable by buyers who care about floor plans and facilities long before they care about marketing copy.

What I built
  • Structured catalogue of 50+ property types with locations and full facility details
  • Floor plan presentation as a first-class part of each listing
  • Marketing site built for a non-technical team to keep updating
Stack
WordPressPHPResponsive web

Economickey

Freelance · publishing

News and economics publishing platform that reached the top 500K global websites (Alexa Rank, 2021).

The problem

An independent publisher needed a platform that could carry real editorial volume and still be fast enough to rank.

What I built
  • Publishing platform for news and economics coverage
  • Built and tuned for search visibility — reached the global top 500K by Alexa Rank in 2021
Stack
WordPressPHPSEO

Case study

Just On Table: one engineer, the whole stack, in production.

Just On Table is a restaurant discovery, booking and ordering platform with two distinct audiences — diners and restaurant owners — and no team behind it but me. Every decision below was made with the knowledge that I would also be the one paged when it broke.

Shape

Two production Flutter apps and one Laravel 10 API, plus three Firebase projects and an Astro marketing site.

Surface

171 OAuth2-secured endpoints over a ~90-model MySQL schema, serving both apps from a single route table.

Scope

Geo-search, table booking, dine-in / delivery / takeaway, payments, wallets, cashback, merchant analytics, subscription billing.

Deliberately two apps, not one

The customer and merchant apps stay fully self-contained — each keeps its own core layer rather than sharing a package. That duplicates some code, and it's the right trade for a one-person team: a change to the merchant app can never break a diner mid-order, and neither app can be held hostage by a shared release. Drift between the two copies gets treated as a per-app bug, not as an argument to merge them.

Chat, without trusting the client

Messaging runs client-to-Firestore for latency, but identity is never the client's to claim. Chat tokens are minted server-side and enforced by Firestore security rules, so a modified app can't read a conversation it doesn't belong to. Presence, typing and read receipts ride the Realtime Database; notifications and unread counts are the one part that runs in a Cloud Function, keeping the write path to unread single-writer.

Finding a real auth hole, and closing it

Phone verification originally ran through an endpoint that flipped is_phone_verified for any bearer token — no proof of the phone at all. I moved it to Firebase Phone Auth and made the backend verify the resulting ID token itself: signature, issuer and audience, auth_time freshness, the sign-in provider, and that the token's phone actually matches the account. The old route is gone and returns 405.

Both verification steps are switchable from a database row. One gate consults the setting on every entry point, so a step turned off is never routed to — no rebuild, no app-store round trip.

Running it is part of the job

The API lives on a Linux server I administer myself: deploy discipline against a checkout with different line endings, a diff against production before every upload, and timestamped backups in place of a git history the box doesn't have. Transactional email runs through an SMTP relay with SPF, DKIM and DMARC all passing.

The sharpest lesson came from mail that "sent" successfully but never arrived. The relay accepted every message and returned success, so the application never threw and never logged anything — the rejection existed only in the relay's own event log. The domain had been blocklisted years earlier, during an abandoned WordPress era that predated this stack entirely. I traced it, got it delisted, confirmed delivery, and audited the current server clean. The failure wasn't in the code; it was in assuming a successful return value meant a delivered message.

Tech stack

What I reach for

Mobile
FlutterDartAndroid (Java)Bloc / Cubit Clean Architectureget_itdartzSwift (working)
Back-end
PHPLaravelRESTOAuth2 / Passport JavaAPI design
Data
MySQLSQLiteFirestoreRealtime Database schema designoffline sync
Platform
Firebase (Auth, FCM, Functions)Google MapsOdoo ERP Linux / HestiaCPCI/CDGitPlay Store & App Store
Practice
code reviewdesign patternsperformance profiling crash reductionAgile deliverymentoring

Experience

Where I've done it

Mobile Team Lead — United Distributors

2019 – Present · Cairo
  • Lead the mobile team while owning products through the complete lifecycle — concept, requirements, architecture, development, release and production support — and run the internship program.
  • Architected and shipped Sales Book, the Android field-sales system used daily by 500+ reps.
  • Built Talabya, the Flutter B2B ordering app that puts supermarkets straight into the distributor's order flow.
  • Built and maintain the Laravel APIs powering every mobile product, and own the database layer end-to-end.
  • Delivered Mobile–ERP integration synchronizing customers, orders, invoices, stock and HR data with Odoo.
  • Introduced CI/CD pipelines automating build, test and deployment, cutting release turnaround and manual error.
  • Drove measurable gains in performance, stability and crash rates through profiling, refactoring to clean architecture, and stricter review standards.

Senior Mobile Developer / Technical Team Leader — Extend Group

2018 – 2019 · Cairo
  • Designed and built native Android applications for real-estate and corporate clients, including the CMS-Arabia, Extend and Extend Studio apps.
  • Integrated Firebase, Google Maps, social login and third-party web services; owned the full Play Store publishing lifecycle.
  • Gathered client requirements, defined project targets and strategic plans, and trained newly hired developers.

B.Sc. Computer Science — Modern Academy, Maadi

2012 – 2016
  • Overall grade Very Good. Graduation project "Remote Desktop Controller" graded Excellent and showcased at Egyptian Engineering Day 2016.

Get in touch

Let's talk about what you're building.

I'm open to senior and lead mobile roles, and to consulting on mobile systems that have to hold up in the field. Write below, or book a call and we'll talk it through.

Opens in your mail app, addressed to me.