01 / 04 · System overview
Selected work
Client delivery · 2025 – Present
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 contribution
- 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
Selected production stories
Story 01 · Systems integration
Core integration confirmed
Connected an external POS catalog and ordering workflow
- Problem
- The platform needed to import categories, modifiers, products, prices, location context, and nutrition data, then forward customer orders and process provider status updates.
- My contribution
- I implemented the catalog import and outbound-order path, aligned the provider SDK and data contracts, added pricing, location, and nutrition handling, and built the webhook-to-internal-status update path.
- Verified result
- A test order reached the provider dashboard, import fixes were deployed and acknowledged, and relevant deployment checks passed for the core flow.
- Proof boundary
- The complete status-to-notification loop was not independently verified; image import and broader security hardening are not claimed, and scheduling UI was shared work.
Story 02 · Launch configuration
Implementation confirmed
Added location-specific scheduled-pickup rules before launch
- Problem
- One location needed customers to choose from every available pickup slot instead of defaulting to only the next available time.
- My contribution
- I added location-specific slot enforcement, required scheduling, and follow-up weekend and location refinements without changing the generic flow for other stores.
- Verified result
- The implementation is integrated into the production history.
- Proof boundary
- The generic scheduling UI began with a teammate, and no clean post-launch acceptance message was recovered.
Story 03 · Mobile delivery
Confirmed delivery
Moved three mobile UX defects from request to test build in one day
- Problem
- Ingredient photos looked soft, a saved card was not selected by default, and the app showed haptic and success feedback even when an item had not been added.
- My contribution
- I implemented one focused fix for each behavior and sent the changes through two reviewed pull requests.
- Verified result
- Both quality gates passed and a new test build was uploaded that evening.
- Proof boundary
- This proves the three attributable fixes, not broader ownership of the mobile app.
02 Approach
Important engineering decisions.
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.
03 Evidence
Evidence chapters.
02 / 04 · Product journey
Order journey
03 / 04 · System boundary
BFF contract boundary
04 / 04 · Delivery / verification
Order-state fan-out and operations
04 Delivered & verified
What the public proof supports.
Delivered scope
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, book a short call and I will help scope the next step clearly.