Abdullah MohamedSenior Software Engineer
All work

Performance and platform migrations on live apps

IMOX & YOLO

DIB GmbH · product engineer

Two live consumer apps at one company, in one year: a reels cold start cut from ~5–6 s to ~0.5–1.5 s, a deep-link migration completed before Firebase's shutdown, and a clinic app 41% smaller.

~6 s → 1.5 sIMOX cold start
41%smaller install (86 → 51 MB)
3 countriesclinics running YOLO
10+client features delivered

The challenge

Both products already had users, which is the hard version of this work: nothing could be rewritten, every change had to survive a store release, and one of them was racing a third-party deprecation with a fixed date.

What it had to do

  • No rewrites: both apps already had users, and every change had to survive a store release
  • IMOX's reels had to play the moment the app opened
  • Deep links migrated before Firebase Dynamic Links' shutdown date — deferred links and attribution included
  • YOLO: one clinic app for HR, appointments, patients, inventory and billing, in clinics in three countries

My role

Product engineer on both apps — owning the performance work, the deep-linking and analytics migration, and a run of client-requested features.

How I built it

  • Redesigned IMOX's reel preloading: prime only the first two reels at splash, prefetch the next two after launch, then paginate ten at a time with a one-page buffer.
  • Migrated deep linking off the deprecated Firebase Dynamic Links to Airbridge — deferred deep links included — preserving attribution continuity ahead of the shutdown, and integrated Mixpanel identity, events and funnels.
  • Cut YOLO's install size by 41%, from 86 MB to 51 MB, through build optimisation, asset compression, and a dependency audit.
  • Delivered 10+ client-requested features across appointment scheduling, HR, patient records and inventory for a platform running in clinics in Egypt, Germany and the UAE.

Decisions, and why

Fix the preloading budget, not the video pipeline

A reels app is slow at launch because it fetches too much before showing anything, not because decoding is slow. Priming exactly two reels at splash is the smallest amount that still lets someone swipe immediately; the next two arrive after first paint, and from there a ten-at-a-time page with one page buffered keeps the scroll ahead of the user without downloading a feed nobody will watch. The result — roughly 6 s to under 1.5 s — came from deciding what to leave unloaded.

Migrate deep links early, and carry deferred links across

Firebase Dynamic Links had an announced shutdown date, so the migration was going to happen either before it or during an outage. The part that is easy to drop is deferred deep linking — the case where someone taps a link, installs the app, and should still land on the thing they tapped. That path is invisible in testing until a real install breaks, so it was ported deliberately rather than discovered later, and attribution stayed continuous across the switch.

Audit dependencies before compressing assets

41% off an install size is not one trick. The order matters: a dependency audit removes whole libraries and their transitive weight first, then build configuration, then asset compression on what is genuinely left. Starting with image compression would have shaved a few megabytes off a bundle that was still carrying code nobody called.

Stack

  • Flutter
  • Airbridge
  • Mixpanel
  • Firebase
  • Performance profiling

From the product

Each caption describes what the screen is doing — several of these products have an Arabic-only interface.

IMOX discovery screen: a category rail down the left (Fashion, Beauty, Electronics, Groceries), and rows of products — men's shoes, women's shoes, accessories — each with a photo and an EGP price.
The discovery feed: categories down one side, priced product rows across, and the reel-backed catalogue this app is built around.
IMOX engage screen: a full-screen short video of a technician at work, with a product card overlaid at the bottom offering the service shown and a side rail of engagement actions.
A reel doubling as a storefront — the video plays full screen and the thing it shows is buyable from the card on top of it. This is the screen whose cold start had to come down.
YOLO HR module: an employee list with a search field and rows showing photo, first name, last name, and a role dropdown set to Administrator or Doctor.
YOLO's HR module: staff records with per-row roles — one of five domains (HR, appointments, patients, inventory, billing) in a single clinic app.
YOLO appointment details: tabs for Overview, Services, Medical Records and Payments, above a patient form with name, gender, date of birth, an international phone field and an address field with Google lookup.
Appointment detail, with the patient's clinical and payment history one tab away — and an address field wired to Google lookup, because the clinics span three countries.
YOLO CRM module: a searchable patient list, each row expanding to show the patient's name and phone number.
The CRM side: the same patient records, reached the way front-desk staff actually look for them.

Building something like this?

Tell me what you are trying to ship and I will tell you, honestly, whether I am the right person to build it.