متاع

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 or LyPay is an adapter and a test, not a change to checkout.

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. 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, a checkout that has absorbed new payment providers without being rewritten, and a home screen that staff change 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.