Multi-Location Restaurant Ordering Platform

A multi-location restaurant ordering and operations platform across a Flutter ordering app, web ordering, an admin dashboard, and an Express API layer. The system connects store/menu discovery, basket and checkout flows, provider-backed order state, loyalty, notifications, support, and back-office operations.

01 Scope

The product context behind the work.

Problem

A multi-location restaurant brand needed customer ordering and internal operations to stay aligned. Customers needed a clean way to choose a location, browse menus, customize items, check out, and track orders. The operations team needed reliable menus, stores, customers, orders, exports, support, messaging, and analytics in one place instead of several disconnected surfaces.

My role

Worked across a Turborepo monorepo with a Flutter ordering app, Next.js web surfaces, an operations dashboard, and an Express BFF on shared packages
Built and connected ordering contracts for store selection, menu/category reads, modifiers, baskets, checkout context, payment handoff, order history, favorites, delivery addresses, and rewards
Supported operations dashboard modules for orders, menus, ingredients, stores, customers, analytics, order exports, support, messaging, notifications, and internal jobs
Connected provider APIs, webhooks, background queues, Redis, email/notification delivery, product analytics, error monitoring, support workflows, and Postgres/Prisma persistence so mobile history, order tracking, and admin views stay in sync

02 Approach

How the work was shaped.

This was delivered for a client under NDA, so it's shown here without identifying details - the focus is on what was built and how.

The product is a multi-location restaurant ordering and operations platform. It spans a Flutter customer ordering app, web ordering and marketing surfaces, an internal operations dashboard, and an Express API layer that normalizes the ordering contracts between the frontend products and provider systems.

On the customer side, the ordering experience covers the full path from location selection to menu browsing, product customization, basket management, checkout, rewards, saved addresses, order history, and order tracking. The app and web surfaces do not talk directly to raw provider APIs; they rely on the BFF to expose stable, app-shaped contracts.

On the operations side, the dashboard gives the team control over the back office: orders, menus, ingredients, stores, customers, analytics, exports, notifications, support, messaging, and internal jobs. That matters because restaurant ordering is operational software, not just a cart flow - store availability, menu overlays, payment handoff, order imports, webhooks, email/notification delivery, product analytics, error monitoring, support tickets, and customer history all have to stay aligned.

The architecture is a Turborepo monorepo with shared packages for UI, database access, environment validation, utilities, logging, and config. The API server connects provider-backed ordering, loyalty, checkout, email delivery, push/device notifications, product analytics, error monitoring, and support workflows to Postgres/Prisma persistence, Redis-backed queues, webhooks, cron jobs, and admin-facing read models.

Gallery

Architecture and flow.

How a restaurant order moves — A customer selects a store, builds an order, moves through basket and checkout, then provider events, imports, notifications, analytics, and support workflows persist order state for mobile history, tracking, admin views, and operations.Open largerimage opens in a new tab

03 Outcome

What the work made clearer.

Qualitative outcomes

Customer journey

Location -> menu -> basket -> checkout -> order tracking across mobile and web ordering surfaces

Operations

Orders, menus, stores, customers, analytics, exports, support, messaging, notifications, and internal jobs in one admin system

Architecture

Turborepo monorepo with Flutter, Next.js, Express, Prisma/Postgres, Redis queues, provider APIs, email/notifications, analytics, error monitoring, webhooks, and cron jobs

Stack

TurborepoFlutterNext.jsExpressTypeScriptPrismaPostgresRedisClerk

Reflections

The product challenge was not a single checkout screen - it was keeping mobile, web, API, provider integrations, order state, and operations tooling aligned around one ordering lifecycle.
The monorepo helped keep shared contracts, config, UI primitives, database access, and integration behavior consistent across a Flutter app, web surfaces, dashboard, and API.

Next step

Have a similar project?

If this looks close to the product work you need, use the contact path and I will help scope the next step clearly.

Book a call