The operator requested anonymity. We describe the project type and engineering decisions; order volumes, revenue figures and market identifiers are not disclosed.
The Client
A regional food ordering business aggregating independent restaurants under one consumer brand. They previously relied on a white-label aggregator with limited control over commissions, branding and menu data. Leadership wanted owned software to manage restaurant relationships directly and support future white-label partnerships.
The Challenge
- No unified menu management — restaurants updated items inconsistently, causing order failures at checkout
- Delivery coordination split between in-house riders and restaurant self-delivery with no single tracking view
- Settlement with restaurants done manually in spreadsheets
- Consumer web experience did not meet mobile performance expectations in their target markets
Our Approach
Kode Builder scoped an MVP followed by operational hardening:
- Customer web app (Next.js): Location-based restaurant discovery, cart, checkout with Stripe, order tracking
- Restaurant dashboard: Menu CRUD, order accept/reject, prep time updates, payout statements
- Operations admin: Restaurant onboarding, commission rules, support order lookup
- Notifications: Email and SMS for order state changes via SNS and a third-party SMS provider
- Phase two: Rider assignment view for in-house delivery staff (lightweight web, not full gig-economy dispatch)
Architecture: Next.js frontend, Node.js API, PostgreSQL, Redis for session and cart, ECS Fargate on AWS, CloudFront CDN, S3 for menu images. CI/CD via GitHub Actions.
Outcomes
Qualitative results reported after launch in selected cities:
- Restaurants manage menus without engineering tickets for routine changes
- Order lifecycle visible to support staff from a single admin console
- Commission and payout reports replace manual spreadsheet reconciliation for onboarded restaurants
- Platform runs on infrastructure the client owns — no per-order SaaS tax to a third-party aggregator
Rollout was city-by-city to control support load. Not all initial restaurants migrated immediately; migration was voluntary per contract renegotiation.
Lessons for Similar Projects
- Menu schema and modifier groups deserve upfront design — retrofitting complex combos is expensive
- Define delivery ownership rules early (platform vs restaurant vs hybrid)
- Start with web before native apps unless app-store presence is a launch requirement
- Restaurant onboarding UX determines catalog quality more than consumer UI polish alone