Stravo
Bilingual restaurant ordering & delivery — loyalty ledger, delivery-zone geofencing, dual-build.
// By the numbers
- 2
- Products from one build
- 4 rewards
- Repeat-order engine
- Geofenced
- Delivery accuracy
- AR · EN
- Bilingual storefront
customer storefront and admin dashboard — one codebase, two deployments
points-based loyalty ledger that brings customers back
map-based zone detection — orders only where delivery is possible
full RTL — every customer ordered to in their own language
What the business was up against
A restaurant taking delivery orders over the phone and social media absorbs three costs at once: staff time transcribing orders, mistakes on addresses outside the delivery range, and no memory of who orders regularly. Aggregator platforms solve the ordering but take the margin and the customer relationship with it. The business needed its own ordering surface, its own delivery boundaries, and its own reason for customers to come back.
A bilingual restaurant ordering and delivery platform with a customer storefront and an admin dashboard — live order tracking, map-based delivery-zone detection, and a points-based loyalty system. One codebase compiles into two independent, zero-overlap deployments.
How it's put together
Customer Storefront
Menu · cart · checkout · tracking
Admin Dashboard
Orders · menu · zones · loyalty
Dual Build
One codebase → two zero-overlap bundles
Managed Backend
Auth · row-level security · server-side pricing
Relational Database
Append-only loyalty ledger
Maps
Delivery-zone geofencing
A single codebase tree-shaken into two independent deployments.
The calls that shaped it
The handful of decisions that determined how this system behaves — and what each one bought.
- 01
One codebase, two zero-overlap deployments
The customer storefront and the admin dashboard are built from a single tree-shaken source and deployed independently, so shared business rules stay identical while no admin code ever ships to a customer's browser.
- 02
Delivery zones as geofences, not text fields
Map-based zone detection decides at checkout whether an address is deliverable. Orders that could never be fulfilled stopped entering the system at all.
- 03
Loyalty as a points ledger
Earning and spending are ledger entries rather than a mutable counter, so a reward can be audited and reversed instead of quietly disappearing.
- 04
Bilingual storefront from the first screen
Arabic RTL and English were built together rather than mirrored later, because the ordering surface is the whole customer relationship.
Signature capabilities
Loyalty ledger
An append-only points ledger with server-authoritative redemption, per-customer locking to prevent double-spend, idempotent earning, and automatic refunds on cancellation.
Dual-build architecture
One environment flag tree-shakes the codebase into two zero-overlap bundles — the storefront ships no admin code and vice versa.
Delivery-zone geofencing
Customer coordinates resolve to the correct zone, fee and minimum order using distance math computed directly in the database.
Server-authoritative pricing
All prices are re-fetched server-side at order time; the client never controls totals.
Live order tracking
An auto-refreshing status timeline from pending through delivered, with a copyable order reference.
Bilingual & RTL
English and Arabic with dynamic direction switching and a persisted language preference.
Business feature set
The functional scope delivered across every part of the product.
Customer storefront
- Menu browsing by category
- Debounced search (incl. Arabic)
- Product detail & recommendations
- Cart drawer
- Today's offers
- Delivery or pickup checkout
- Map-based delivery pin
- Delivery-zone detection
- Live order tracking
- Order history
Admin dashboard
- Orders management
- Menu & category CRUD
- Offers & promotions
- Delivery-zone editor
- Business settings (hours, tax, channels)
- Loyalty rewards manager & analytics
Loyalty & rewards
- Append-only points ledger
- Four reward types
- Configurable earn rate
- Auto refunds on cancellation
- Server-authoritative redemption
What changed operationally
Documented outcomes from the delivered system. Where exact figures are confidential, the operational change is stated instead.
- Phone-and-social ordering replaced by a direct storefront the business owns
- Two independent products — storefront and admin — from one maintained codebase
- Out-of-range orders prevented at checkout by geofenced delivery zones
- Points-based loyalty ledger driving repeat orders without an aggregator
- Live order tracking visible to the customer through fulfilment
- Full Arabic RTL and English storefront from launch
What we had to work within
- Small operator — the admin surface had to be usable by kitchen staff
- Delivery is geographically bounded and the boundary is not a straight line
- Bilingual Arabic/English customer base ordering from the same menu
- No aggregator dependency; the customer relationship had to stay first-party
What I owned
End-to-end on this project — from architecture and data modelling through to a shipped, production product.
- Full-stack architecture & data modeling
- Loyalty ledger with concurrency-safe redemption
- Dual-build storefront + admin from one codebase
- Delivery-zone geofencing & server-side pricing
- Row-level security & dual authentication
- Bilingual English/Arabic with full RTL
Built with
Frontend
Backend
Maps
Infrastructure
Want something like Stravo?
Boutique software studio — agency-quality systems, shipped by one senior engineer.
// Related work
