Al Amri ExpressQuick commerce and grocery
Al Amri Express delivers groceries and daily essentials across Oman. We built two apps: the storefront customers order from, and the operations app the warehouse and delivery teams run on. Quick commerce app development and the grocery delivery platform behind it are one system, and the warehouse app is the harder half.
Build fingerprint
Where it runs, how we engaged, and what it was built on.
Technologies
What makes this problem genuinely hard - before any client name enters the page.
Oman's addressing standard excludes a location based post code. The codes in circulation belong to post office boxes, and street names are only unique within a wilayat. So the pin drop is the primary key and the text is commentary. Zones get drawn as polygons, and the landmark a customer types is a field the rider reads verbatim.
The rial carries three decimal places, so money must be stored in integer minor units with an exponent of three. Anything defaulting to two truncates silently. Cash also makes refusal partial: a shopper rejects one substituted item, not the order, so the door needs per item accept and reject that reprices collection on the spot.
Picking, packaging and rider time are near fixed whether the basket holds three items or twenty. Contribution scales with basket size while cost scales with order count, so the levers are batch picking, drop clustering, and slot capacity set by picking throughput rather than rider headcount.
A layout problem before a translation one. Mixed Arabic and Latin runs reorder at render time under the bidirectional algorithm, so a correctly stored order number displays scrambled unless interpolated values are wrapped in isolates. Search must normalise alef and taa marbuta variants, and both numeral sets must parse on input.
Al Amri Express sells groceries across Oman, delivered by its own operation rather than a marketplace of third party riders. That made the customer app and the warehouse one system, because a promise made at checkout is kept or broken by whoever picks the order.
A bilingual catalogue with search over Elasticsearch, so a query in either language returns the same shelf. Relevance carries grocery, where customers arrive knowing what they want.
Cart, checkout and one tap reorder from previous baskets, the highest value interaction in grocery because weekly shops repeat.
Order state pushed over websockets rather than polled, so the customer sees picking, dispatch and arrival as they happen.
A separate staff application with access split across admin, packer and delivery. Orders move through picking, packing and ready for dispatch, with staff assignment and dispatch tracking.
Tradeoffs
Every choice closed off something else. Those costs are stated, not hidden.
Instead of: MySQL full text indexes. Bilingual search needs analyzer level control over Arabic normalisation, which a database index does not give you.
What we acceptedA second datastore to keep in sync, and an indexing path that drifts from the source of truth if unmonitored.
Instead of: A single app that changes mode by permission. The audiences share almost no screens, and warehouse staff repeat one flow on a shared device. One app would couple very different release cadences.
What we acceptedDuplicated shell code and a second release process to maintain.
Instead of: Interval polling from the client. Status changes cluster during the delivery window, so polling either wastes requests or lags.
What we acceptedConnection state becomes the client's problem on flaky networks, so the UI needs a reconnect path and a truthful last known state.
Reusable
Every Gulf delivery build makes this call early, and it is hard to reverse once orders carry stored addresses.
| Method | Works in Oman | What it costs you |
|---|---|---|
| Street address, geocoded | Unreliable outside planned districts | Routing failures that look like rider error |
| Pin drop plus landmark note | Yes, and it matches how people give directions | A map interaction at signup, which adds friction |
| Postal code lookup | No, there is no location based postcode | Rewriting serviceability logic later |
| Plus code or mapcode | Supported by the national standard | Low familiarity, so it works better rider side |
Whichever you pick, store the coordinate with its capture source and deduplicate by proximity, not string match.
Delivery
Capabilities delivered and the scope of the build - not results attributed to it.
Capabilities
Scope
Scope of the build, not results attributed to it.
Bring us the part you think is hardest.
Roles are separated in the staff app, so people see only what their role covers. Data sits in the client's own AWS account.
The client holds the hosting account and both store listings, so changing supplier is a commercial decision, not a technical one.
The customer app shipped first and the operations app followed, so each entered production against something stable.
Reflection
Starting again, we would design the substitution flow before checkout rather than after. Substitution is the only part of a grocery order the customer did not choose, it moves ratings more than delivery speed does, and deciding late forces that question to be answered around code that already exists.
Because there is not one. Oman's addressing standard states there is no location based post code, and the codes in circulation are post office routing codes. Zones get drawn as polygons over coordinates.
Usually the mixed content. A purely Arabic screen mirrors cleanly, but an order number inside an Arabic sentence reorders under the bidirectional algorithm and displays wrong even though the stored string is correct. Isolating interpolated values is far cheaper at build time than as a retrofit.
Not always. The audiences share almost no screens and release on different cadences, so we split them here. For a smaller operation, a role gated section inside one app is defensible.
Context
Tell us what your operation runs on today.
Real feedback from the people we've proudly partnered with.
Sales Director |Cintas
United States
Zyneto Global Technologies provided excellent project management and technical expertise throughout the engagement. The team was responsive, collaborative, and adaptive, ensuring the project met our expectations and set a strong foundation for future growth.
Founder & CEO |Moneteo
We engaged Zyneto to design and develop a custom web platform for Moneteo, aimed at improving project management, data tracking, and collaboration across internal teams and external partners. Their work included full-stack web development, custom modules for workflow automation, API integration, and comprehensive testing.
CEO |E-Commerce Platform
Overall, their responsiveness and timely deliveries contributed positively to the project's success. The client achieved better data management and quality. The service provider delivered the project on time and ensured prompt responsiveness throughout the engagement. Their innovative approach was outstanding.
