Cross-border commerce · 2024 · iOS + Android

Amanah

Cross-border marketplace connecting travelers and shoppers across 10+ countries. Offers, tracking, and secure messaging — 40% engagement lift in beta.

Technical Product Owner + Mobile Engineer

10+

Countries

Two-sided

Shoppers and travelers

40%

Beta engagement lift

FlutterTwo-sidedChatMulti-currency

Click any screen to zoom

Context

Amanah (“Your Journey. Their joy.”) is a two-sided mobile product: shoppers who want an item from abroad, and travelers who can carry it. A trip (Toronto → Amman) becomes a capacity. Offers, orders, in-thread chat, and a fee stack (item, tax, service, processing, traveler reward) have to make sense in CAD and JOD.

My role

I owned

Two-sided flow: shopper order vs. traveler trip
Offer / order states and in-order chat
Pricing breakdown and multi-currency display
Flutter implementation, auth, and messaging UI

The team owned

Payments and payout rails
Trust & safety policy
Backend matching of trips to orders

The problem

Cross-border shopping usually means a forwarder or a cousin. Neither is structured. Travelers have unused luggage space; shoppers have Amazon links and a deadline. Without offers, status, and a conversation tied to the item, the handshake falls apart in WhatsApp.

Discovery

We split the jobs: a traveler publishes a trip and sees orders/offers; a shopper places an item (URL, price, qty) and a reward. Chat is not a generic inbox — it is scoped to the order, with a progress strip and the product card pinned. Social login exists because this is a consumer product, not an enterprise SSO.

Product decisions

Chat lives on the order

The decision: Messaging is inside the order thread, with the item, expected date, and stage tracker above the bubbles.
Why: Context switching to WhatsApp is how money and dates get lost.
The trade-off: We did not ship a global social inbox. Conversations are transactional on purpose.
The result: Shopper and traveler negotiate against the same Nike, the same date, the same stages.

Show every fee, including traveler reward

The decision: The summary screen lists item, Canadian tax, service, processing, and traveler reward, then estimated CAD and the JOD billed note.
Why: Trust dies in surprise totals. The traveler’s cut must be visible or the supply side will not show up.
The trade-off: The checkout looks “expensive” compared to a fake low headline price.
The result: Both sides can argue about a number that is honest before anyone flies.

Trips as the traveler home

The decision: Travelers manage Active / All trips (route, date, details) rather than a generic feed.
Why: Capacity is a flight, not a profile. The unit of work is Toronto → Amman on a date.
The trade-off: Less social discovery. More operational clarity.
The result: Offers and orders hang off a trip. Earning is visible even when it is still zero.

UX / user flow

Teal, white, and light blue. Ahlan on sign-in, Google / Facebook / Apple, then Home, orders, messages, trips, profile. Offer cards show rater, status (Accepted), product image, source URL, and placed offer. Settings expose email, phone, and payout — the traveler’s real account, not a toy profile.

Technical architecture

Flutter, REST-backed orders and trips, real-time or polled chat, image attachments, coupon hooks, and multi-currency presentation. Auth is email plus social. Payout method is a first-class account setting because the supply side is paid people, not ads.

What I built

Auth (email + social) and account settings
Trip list and trip detail (orders / offers)
Item edit flow with summary, coupons, and fee stack
Order-scoped chat with stage tracker
Shopper and traveler navigation

Trade-offs

KYC, insurance, and customs automation were not v1. We shipped the commercial handshake: trip, offer, price honesty, and a thread. Marketplace liquidity features waited until the core loop was usable.

Launch

Consumer Flutter app for iOS and Android, bilingual in spirit (Ahlan, JOD/CAD) for a Jordan–Canada corridor first.

Outcome

Shoppers and travelers can complete an offer, see a full cost stack, and talk on the order. Scale and GMV figures stay unpublished. The product exists as a working two-sided loop, not a concept deck.

What I learned

Two-sided products fail when you design only the shopper. The traveler needs trips, offers, and payout in the same mental model. I would have put traveler empty states (no trips yet) on the same polish level as the shopper checkout from the start.