Abdullah MohamedSenior Software Engineer
All work

Gold & jewellery commerce, retail and wholesale

BTC

Appenza Studio · product engineer

Two apps from one Flutter codebase for one of Egypt's largest gold and jewellery houses: a consumer storefront and a B2B wholesale ordering app, both over the same GraphQL API.

2 appsretail + B2B, one codebase
LiveApp Store and Google Play
GraphQLone catalogue, two shapes

The challenge

The same business sells a 1,200 EGP gift to a walk-in customer and a 50-gram ingot to a merchant, on prices that move with the gold market. Two audiences, two buying flows, one catalogue — and a company that did not want two engineering efforts.

What it had to do

  • A retail storefront and B2B wholesale ordering from one catalogue
  • Prices that move with the gold market
  • Delivery country and language chosen per visit, so a price doesn't change at checkout
  • One engineering effort, not two

My role

Product engineer on both apps and the shared codebase behind them.

How I built it

  • Built the customer storefront — collections, categories, a savings calculator, cart and checkout — with per-visit delivery country and language.
  • Built the B2B merchant app for wholesale ordering from the same codebase and the same catalogue.
  • Integrated both against a GraphQL API so a price or a product exists once and both apps read it.
  • Shipped both to the App Store and Google Play.

Decisions, and why

One codebase, two products — not one app with a switch

Retail and wholesale share a catalogue and nothing else: different prices, different quantities, different checkout. A single app gated on an account type would have put wholesale pricing one bug away from a consumer's screen. Two builds from one codebase keeps the shared model shared and the flows genuinely separate.

GraphQL, because the two apps ask different questions of the same catalogue

The storefront wants a product with images and a retail price; the merchant app wants the same product with tiers and stock. Against REST that is either two sets of endpoints or over-fetching on both sides. One graph lets each app ask for the shape it renders.

Country and language as a per-visit choice, not a device setting

Delivery country decides price and availability, and the buyer is not always in the country they are shipping to. Making both explicit selectors in the header — rather than inferring from the locale — avoids quoting someone a price that changes at checkout.

Stack

  • Flutter
  • GraphQL
  • Clean Architecture
  • E-commerce

From the product

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

BTC storefront home: a Silver Collection banner, selectors for delivery country (Egypt, EGP) and language (English), a Gold/Silver toggle, category tiles for coins, ingots, bars and wearables, and a Calculate Your Savings panel taking an amount in EGP.
The storefront: metal and category up front, delivery country and language chosen per visit — and a savings calculator, because people buy gold by budget as often as by product.
BTC gift collections screen: Baby Gifting with 19 items and Happy Birthday with 153 items, above a Best Sellers row showing a wooden box of 25 cards at 1,200 EGP and a 50g Kaaba ingot at 338,852.48 EGP.
Curated collections above best sellers. Prices run from a 1,200 EGP gift to a 338,000 EGP ingot in the same list, which is the range the UI has to stay legible across.
BTC coins category: a two-column grid of gold coins — 40g and 8g Al Masjid Annabawi, 8g and 4g Angel — each with a photo, weight, price in EGP, and an Add To Cart button.
A category grid priced to the piastre. Gold prices move, so the number on the card is a live figure rather than a stored one.

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.

Hire me for the same thing