Context
Mataa runs e-commerce and delivery in Tripoli, which means three audiences with three apps: customers ordering, vendors fulfilling and drivers delivering. When I joined as a developer in September 2024 there was one customer app and a plan for the rest. I led the mobile team from January 2025 through the build-out, and moved back to part-time development in February 2026, still shipping releases and reviewing code.
Decisions
One Melos workspace, three apps, a shared core. Networking, authentication, payments, design system and analytics live in packages that all three apps depend on, so a fix lands in every app in the same release. Mason bricks generate a new feature package with the layers already in place, which on a team of several engineers turns "where does this file go" from a taste question into a non-question.
Payments behind a single interface. Libyan customers pay with local wallets and cards that global providers do not cover, and international customers expect Stripe. Each provider is an adapter behind one payment contract, so adding Moamalat, Edfaly or Sadad is an adapter and a test, not a change to checkout. In 2026 that layer carried thousands of transactions across online, wallet and card-on-delivery flows.
A server-driven storefront. Marketing wanted to change the home screen for Ramadan without a store release, so the storefront is described by the server and rendered by the app, with a React and TypeScript admin panel where staff compose it. The app knows how to render a fixed set of components; the server decides which ones and in what order.
Shorebird over the air updates on top of the Codemagic and Fastlane pipeline, so Dart-level fixes reach users the same day. Releases went from 1.7 to 3.8 a month, 2.2 times as many in the six weeks after it shipped. Native changes still take the normal route.
Semantic search with Qdrant and ONNX embeddings, so "something warm for a toddler" finds a fleece jacket. I worked on this alongside two other engineers; it was not mine alone.
Consequences
Three apps in production that share most of their code and serve up to 115,000 monthly active users, with 27,600 orders and 12.3M LYD in order value since January 2026. The checkout has absorbed new payment providers without being rewritten, and staff change the home screen weekly without engineering.
The server-driven storefront is also the biggest liability: every component the app can render is a permanent API, and removing one means waiting for old app versions to die.
What I would do differently
Draw the package boundaries before the codebase grew. The workspace split happened after the first app existed, so a few packages still depend on each other along the old folder lines rather than along the real coupling.