EzGrocery

A grocery service spanning several provinces is not a single catalogue with a wider delivery radius. Availability, pricing, substitutions and delivery windows all belong to the individual store, so the store had to be a first-class object in the data model rather than a label attached to a product.

Groceries are the category where something is always out of stock. A customer who cannot see what was picked, what was substituted and where the driver is will phone somebody — and a support call per order is a business that does not scale.

Card handling and bulk SMS both carry rules that are expensive to get wrong and boring to get right. Both were taken to established providers rather than built, so the platform never touches raw card data.

Catalogue, stock and delivery windows resolved per store, so a customer in one province sees a genuinely different shop from one in the next — and a store owner manages only their own.

Geo-location and delivery tracking through the Google Maps API, giving the customer the same view of the order that the operation has: placed, picked, on its way, delivered.

Real-time chat on Firebase between the customer and the store handling their order. This is the substitution problem solved socially rather than algorithmically — the picker asks rather than guesses.

Accounts verified by one-time code to a real mobile number rather than an email address, because a delivery address with no reachable phone behind it is a failed delivery waiting to happen.

Elavon for the payment gateway and Twilio for order-status messages, so status reaches the customer on the channel they actually read rather than only inside the app.

Automated reporting and history built separately for the client, the individual store owners and the platform admin — three audiences who need the same underlying data cut three different ways.

See how we deliver web application development for clients worldwide.

See how we deliver mobile app development for clients worldwide.