Existing grocery apps in the market could not guarantee sub-15-minute delivery windows in dense residential areas because dark-store placement, routing logic, and rider allocation were all treated as separate, loosely coordinated systems. Every extra minute of delay was directly tied to churn, so the client needed a platform architecture built around speed as a first-class constraint, not an afterthought.
Inventory synchronisation across multiple dark stores was error-prone and caused stockout orders, since each warehouse maintained its own local stock count with no shared source of truth. Orders were frequently accepted for items that had already been sold from a neighbouring store's shared catalogue, forcing manual cancellations that damaged customer trust.
There was no unified platform for grocery delivery, home services, and community notices in one experience, so residents of gated communities had to juggle three or four separate apps for daily needs. This fragmentation suppressed engagement and made it hard for the client to build the kind of daily habit loop that quick-commerce economics depend on.
Surge capacity during peak hours — typically 6 to 9 PM — caused order queue backlogs and driver dispatch failures, with the existing prototype architecture unable to absorb more than a fraction of the traffic residents generated during dinner-prep windows. Backlogged orders cascaded into missed SLAs across the entire active order pool, not just the newest ones.
Payment gateway failures under high concurrency led to abandoned carts and revenue loss, particularly during flash promotions when transaction volume spiked ten-fold in minutes. A single point of payment failure meant the checkout funnel had no resilience, and every gateway timeout translated directly into lost orders.
Driver dispatch relied on manual coordination and static zone assignments, which meant riders were frequently sent to the wrong dark store or left idle while nearby orders queued elsewhere. There was no live visibility into rider location, load, or estimated availability, making it impossible to optimise assignments in real time.
The founding team needed to launch and scale within an aggressive 5-month runway to hit a critical fundraising and market-entry window, leaving no room for a slow, phased infrastructure build. Every architectural decision had to be production-grade from day one, since a broken launch would have jeopardised investor confidence.
Community-specific features like resident verification, society-level notices, and localized service bundling added product complexity beyond a typical delivery app, requiring careful data modelling so gated-community identity and access rules did not collide with the open marketplace logic used for public dark-store delivery.