Les applications de courses existantes ne pouvaient garantir des délais inférieurs à 15 minutes dans les zones résidentielles denses, car l'emplacement des dark stores, la logique de routage et l'allocation des livreurs fonctionnaient comme des systèmes séparés et faiblement coordonnés. Chaque minute de retard supplémentaire se traduisait directement en désabonnement, ce qui imposait de concevoir la vitesse comme une contrainte architecturale de premier ordre, pas un détail secondaire.
La synchronisation des stocks entre plusieurs dark stores était source d'erreurs et de ruptures, chaque entrepôt gérant son propre inventaire local sans source de vérité partagée. Des commandes étaient régulièrement acceptées pour des articles déjà vendus dans un magasin voisin partageant le même catalogue, obligeant à des annulations manuelles qui érodaient la confiance des clients.
Il n'existait aucune plateforme unifiée pour les courses, les services à domicile et les annonces communautaires, obligeant les résidents des communautés résidentielles à jongler entre trois ou quatre applications pour leurs besoins quotidiens. Cette fragmentation freinait l'engagement et empêchait le client de construire l'habitude d'usage quotidien dont dépend l'économie du quick-commerce.
Les pics de demande en heure de pointe — typiquement entre 18h et 21h — créaient des files d'attente de commandes et des échecs de dispatch de livreurs, l'architecture du prototype existant ne pouvant absorber qu'une fraction du trafic généré pendant la préparation des dîners. Les commandes en attente se répercutaient en cascade sur l'ensemble du pool de commandes actives, bien au-delà des seules nouvelles commandes.
Les pannes de passerelle de paiement sous forte concurrence entraînaient des paniers abandonnés et des pertes de revenus, en particulier lors des promotions flash où le volume de transactions était multiplié par dix en quelques minutes. Un point de défaillance unique sur le paiement rendait tout le tunnel de commande fragile, chaque timeout se traduisant directement par une commande perdue.
Le dispatch des livreurs reposait sur une coordination manuelle et des zones statiques, envoyant fréquemment des livreurs vers le mauvais dark store ou les laissant inactifs pendant que des commandes s'accumulaient ailleurs à proximité. Aucune visibilité en direct sur la position, la charge ou la disponibilité des livreurs ne permettait d'optimiser les affectations en temps réel.
L'équipe fondatrice devait lancer et faire grossir la plateforme en seulement 5 mois pour respecter une fenêtre critique de levée de fonds et d'entrée sur le marché, sans laisser de place à une montée en charge progressive de l'infrastructure. Chaque décision d'architecture devait être de qualité production dès le premier jour, un lancement raté risquant de compromettre la confiance des investisseurs.
Les fonctionnalités propres aux communautés résidentielles — vérification des résidents, annonces au niveau de la société, offres de services localisées — ajoutaient une complexité produit supérieure à celle d'une application de livraison classique, nécessitant une modélisation de données rigoureuse pour que l'identité et les règles d'accès des communautés fermées ne se mélangent pas avec la logique du marketplace ouvert des dark stores publics.