Case study · Loyalty platform · Fuel retail · GCC
A fuel-station network had no way to know its repeat customers.
One API contract, three clients, and an append-only points ledger — the foundation beneath the products, live today.
Numbers at a glance
User-facing products
OpenAPI contract
Data models
Languages, Arabic-first
Manager dashboard pages
The situation
Every fill-up was a transaction. None of them was a relationship.
Before
- A driver filled up and left. Nothing told the brand they had been there before.
- Workers had no way to record a loyalty purchase; head office could not see who came back.
- Complaints had no central place to be resolved.
After
- The customer shows a code on their phone. Points land against a verified purchase.
- The worker scans it on the station device and records the purchase.
- Head office sees every station, customer and transaction in one dashboard.
What we delivered
Three products, one shared backend.
Customer app
Arabic-first, right-to-left. Balance, single-use QR, rewards, vouchers, station finder, complaints — the driver's loop.
Worker app
Android, scanner-led. Scan a QR, record a purchase, redeem a voucher — idempotent retries settle once.
Manager dashboard
Stations, workers, customers, transactions, complaints and offers, each role seeing only its own. Arabic and English.
The moment it happens
From code to points, at the pump.
Illustrative screens in our own styling. The client's screens, branding and data are not shown.
Customer phone
Staff device
Head-office ledger
Points ledger
This period- EarnStation A+ 100
- RedeemReward− 500
- ReversalCase 1001+ 100
- EarnStation B+ 40
How it fits together
One agreement in the middle, so nothing drifts apart.
Three applications, one shared definition of what the system does. Change it once and every client follows.
Founder reflection
“The product is built; the workflow is not. People end up bridging the gaps between systems that were never designed to work together.”
Decisions that matter later
Loyalty points are money. They were built that way from day one.
A balance nobody can quietly edit
When a customer disputes their points, there is an answer. Every correction is a new visible entry; the history reads like a statement.
A code that works exactly once
A code cannot be shared and claimed twice, and a repeated tap on a bad connection never awards twice.
Three products that cannot drift apart
One change reaches the customer app, the worker app and head office together.
Project review
Have a workflow that never became a product?
A project review is one conversation: your workflow, what would change it, and an honest answer about scope.
Start a project reviewThe end-to-end loyalty loop
Three hand-offs, two idempotency boundaries, one ledger.
- Step 01
Customer shows a code
The customer app issues a single-use signed QR. The worker scans it.
- Step 02
Worker records the purchase
An Idempotency-Key rides along. A bad connection never double-counts.
- Step 03
Ledger records a verified earn
The backend appends a ledger entry; the points rule engine computes the reward.
- Step 04
Customer redeems a reward
A voucher is reserved and revealed.
- Step 05
Worker consumes the voucher
Points are debited atomically.
- Step 06
Head office sees the repeat visit
Every verified purchase lands in the dashboard; the original record is never edited.
Production vs. planned
What is live today, and what is named as the next phase.
- Backend / APIToday. Live in Azure UAE North, 2026-08-12. Next. SMS sender and production seed data next.
- Manager dashboardToday. Live and used internally by head office. Next. No live screenshots published with this case study.
- Customer appToday. 21 screens designed in Arabic-first; the public station flows render in the build. Next. Preparing for store release — OTP, in-app Terms, and a production signing key next.
- Worker appToday. Built for an Android station device; 14 screens designed. Next. POS integration planned, not complete — hardware qualification next.
Deeper studies
One product at a time.
Manager dashboard
Stations, workers, customers, transactions, complaints and offers — role-based, Arabic and English.
What you will see. Role-aware screens, access-denied paths, silent token refresh.
What is not shown. Dashboard is live and used internally; no live screenshots published.
Read the manager dashboard studyCustomer app
21 screens designed in Arabic-first RTL; five are still placeholders.
What you will see. Five end-to-end screen flows traced through the screens.
What is not shown. Preparing for store release — no store listing yet.
Read the customer app studyWorker app
Android station operations; scanner-led; 14 screens with server-authoritative hand-offs.
What you will see. No false success, no client-side balance, idempotent retries.
What is not shown. No production-station deployment or POS hardware qualification yet.
Read the worker app study