Albagshi Gold & Diamonds
High-ticket jewellery commerce on mobile — four payment rails, a thousand-piece catalogue, and a house founded in 1881.
// By the numbers
- 6+
- Years in production
- 4
- Payment rails
- 1,000+
- Catalogue
- 1881
- Client since
on the App Store since May 2020 and still updated in 2025
local cards, one-tap wallet, instalments, and cash or bank transfer
gold and diamond pieces, shipped across the Kingdom
the founding year of the jewellery house the app was built for
What the business was up against
Selling jewellery online is a settlement problem wearing a catalogue's clothes. A single piece is a four-figure purchase, and at that price a shopper does not abandon a checkout they distrust — they never start it. Some will only pay with the local card scheme they already use; some want the purchase split across months before they will commit; some will not put four figures through a phone at all and need a human and a receipt. Each of those is a different payment rail, and a missing rail does not degrade the sale, it loses it outright. Meanwhile the same pieces sit in four mall branches, so whatever the app shows has to be the same catalogue the shop floor is working from.
A mobile storefront for a jewellery house founded in 1881, with branches across the Eastern Province, Riyadh and Al-Khobar. Shoppers browse a thousand-piece gold and diamond catalogue, check out across four payment rails — local cards, one-tap wallet, instalments, or cash and transfer — and follow the order to the door, on iOS and Android against a Laravel backend.
How it's put together
Mobile App
Flutter — iOS & Android
Cart & Checkout
Four settlement paths
Catalogue API
Pieces, collections, availability
Order Service
Placement · state · history
Relational Database
Catalogue, orders, customers
Media Storage
Product photography
Payment Gateway
Hosted checkout · local cards
Wallet & Instalments
One-tap pay and split payment
Push Notifications
Order state to the shopper
One catalogue behind the app and the branches; checkout fans out to four settlement paths.
The calls that shaped it
The handful of decisions that determined how this system behaves — and what each one bought.
- 01
Four payment rails, because one rail loses the sale
Local cards for the default buyer, a one-tap wallet for the impatient one, instalments for the one weighing a four-figure piece, and cash or bank transfer for the one who will not card it at all. On this basket size each rail wins a distinct shopper, so the cost of building all four was lower than the cost of the customers any single choice would have excluded.
- 02
Instalments as a first-class option, not a footnote at checkout
On a four-figure ring, splitting the payment is frequently the decision itself rather than a convenience. Surfacing instalments alongside the price — not three taps into a payment sheet — puts the affordable version of the number in front of the shopper while they are still deciding.
- 03
Card data never touches the app or our server
Checkout hands off to a hosted gateway flow, so payment credentials travel from the shopper to the processor directly. On a catalogue where a single order is large, keeping card data and its compliance burden outside a codebase maintained by a small team was not a close call.
- 04
One catalogue behind the app and the shop floor
Over a thousand pieces across the house's in-house lines are served from a single backend, so the app and the branches describe the same inventory. A jewellery buyer who is shown a piece on a phone and then told something different in the store has been given a reason to leave.
- 05
Push notifications tied to order state
Someone who has just spent four figures wants to know where the parcel is. Tying notifications to real order transitions turned the most common support call into something the app answered on its own.
- 06
One Flutter codebase for both platforms
A single client for iOS and Android is why the app kept evolving instead of ossifying — it passed version 37 while still being maintainable by a small team, which two parallel native codebases at this scale would not have been.
Signature capabilities
Four-rail checkout
Local cards, a one-tap wallet, instalments and cash or bank transfer each convert a shopper the others would have lost — which on a four-figure basket is the difference between a storefront and a brochure.
Instalments on high-value pieces
Split payment is surfaced next to the price rather than buried at checkout, because on an expensive piece the monthly figure is the number the buyer is actually deciding against.
Payments off the critical path
A hosted gateway flow keeps card credentials out of both the app and the server, so the compliance surface stays with the processor while the checkout still feels native.
One catalogue, two channels
A thousand-plus pieces across the house's own lines are served from a single backend, so the app and the four mall branches never contradict each other.
Order tracking with push
Notifications fire on real order transitions, turning the most frequent support call for a high-value delivery into something the shopper can answer themselves.
Arabic-first storefront
Designed around Arabic and right-to-left layout from the start, for a consumer audience across the Kingdom.
Business feature set
The functional scope delivered across every part of the product.
Shoppers
- Browse gold and diamond collections
- In-house brand lines
- Product detail with photography
- Search and filtering
- Wishlist
- Arabic interface with right-to-left layout
Checkout & payments
- Local card payment
- One-tap wallet payment
- Instalment plans on high-value pieces
- Cash on delivery
- Bank transfer
- Hosted payment flow, no card data stored
Orders
- Cart and order placement
- Delivery addresses
- Order status tracking
- Order history
- Order-state push notifications
Platform
- Single catalogue behind app and branches
- Server-driven merchandising
- Single codebase for iOS and Android
- Maintained in production past version 37
What changed operationally
Documented outcomes from the delivered system. Where exact figures are confidential, the operational change is stated instead.
- Live on the App Store and Google Play since May 2020, still receiving updates in 2025
- Four payment rails in production, including instalments and one-tap wallet
- Catalogue of over a thousand gold and diamond pieces, shipped Kingdom-wide
- Order-state push notifications replaced the most common support call
- One Flutter codebase serving both iOS and Android
- Arabic-first interface with full right-to-left layout
What we had to work within
- Four-figure basket values — trust and settlement matter more than browse volume
- Shoppers split across local cards, wallets, instalments and cash on delivery
- Physical branches sell the same pieces, so the catalogue cannot diverge
- Insured high-value shipments, delivered across the Kingdom
- Arabic-speaking consumer audience, on both platforms
What I owned
End-to-end on this project — from architecture and data modelling through to a shipped, production product.
- Flutter application for iOS and Android
- Laravel API, catalogue and order data model
- Payment gateway and wallet integration
- Instalment provider integration
- Order lifecycle and push notifications
- Store submission and release management
Built with
Mobile
Backend
Data
Payments
Integrations
Want something like Albagshi Gold & Diamonds?
Boutique software studio — agency-quality systems, shipped by one senior engineer.
// Related work
