FastFood
FastFood is a full-stack food-ordering platform built around two connected experiences. A customer web app lets people discover nearby restaurants, browse menus with dish details and allergens, build an order in a live cart, and check out with a choice of payment method, then follow the order through its lifecycle in real time. A restaurant management console lets owners run their menu, advance incoming orders through a status pipeline, and track performance on an analytics dashboard. LilyByte designed and built the whole product end-to-end (Next.js frontend, Express/MongoDB API) as a self-initiated project.
Both roles are driven by one system: a single account model with a customer/restaurant switch, one order that both sides can see and act on, and a location-aware discovery engine that ties menus to a map.
The challenge
A food-ordering marketplace is really two products that must agree with each other. Building both, well, at once was the core challenge.
Two audiences, one data model. Customers want speed (find something good nearby and order it in a few taps. Restaurants want control and insight) manage a menu, process incoming orders, and understand the business. Both are driven by the same restaurants, menus and orders.
Location-aware discovery. Discovery only feels right when it respects where you are and what you like: real geospatial queries for restaurants near an address, combined with cuisine preferences and allergen constraints.
A shared, live order lifecycle. An order moves through ordered, preparing, ready or out for delivery, and completed. The same record powers the customer’s live tracking popup and the restaurant’s operational board, so state must stay consistent on both sides.
A complete ordering funnel. From browsing a dish, to a detailed dish view, to a live cart, to checkout with order details and a payment method: the whole path had to feel like a real ordering app, not a form.
Operational insight. Owners needed genuine analytics (revenue and order trends, best and worst sellers, period comparisons) rendered clearly.
The solution
FastFood pairs a modern Next.js frontend with a geospatial Express/MongoDB backend, unified by a role-aware auth layer.
001
A role-aware Next.js frontend
The client is built on Next.js 15 (App Router, Turbopack) with the HeroUI component system and Tailwind CSS. Route groups separate the customer app from the restaurant console, and an auth guard routes each user to the right surface. Chart.js powers the analytics, and cart and ordering state is handled with React context so the flow persists across the whole checkout.
002
A geospatial ordering API
The backend is an Express 5 REST API on MongoDB via Mongoose, secured with JWT (bcrypt), validated with Joi, documented with Swagger, and handling menu imagery with Multer uploads. Discovery is powered by MongoDB 2dsphere indexes and $geoNear pipelines that rank restaurants by distance and filter dishes by cuisine and allergens; OpenStreetMap Nominatim geocodes addresses and OSRM estimates delivery times.
003
One order lifecycle, two views
A single Orders collection is the backbone of the app: it feeds the customer’s live order-status popup, the restaurant’s order-management board, and the dashboard’s aggregations for revenue, order counts, sales trends and product popularity.
Key features
Authentication & roles
A single sign-up flow with a User/Restaurant account switch routes each person to the right experience; sessions use JWTs.
Discovery & search
The home feed is personalized by taste and location; a dedicated search page adds a category carousel, cuisine preferences, allergen exclusions and an open-now filter on top of the geospatial ranking.
The ordering flow
The heart of the customer app is a complete ordering funnel. From a restaurant page, a dish opens a detailed popup with photo, tags, allergens and ingredients; adding dishes fills a live cart with quantities and a running total; and checkout collects order details and a payment method before the order is placed.
Live order tracking
Customers follow every order through its lifecycle in a real-time status popup (from “Waiting for confirmation” to “Preparing your order”, “Ready for pickup” and “Completed”) with the full itemized order and progress. Restaurants advance the same order from their console.
Customer account
Customers manage their profile, delivery addresses and saved cards from a dedicated account area.
Restaurant console: analytics dashboard
The manager dashboard turns the order stream into insight: KPI cards for orders and revenue (today, week, month, with period-over-period deltas and average ticket), a configurable sales-trend chart, a best/least-sellers table, and a live recent-orders feed.
Restaurant console: menu & order operations
Owners manage the catalogue with full dish CRUD (adding a brand-new dish or picking an existing one) and work through incoming orders on a searchable, paginated board, advancing each order’s status from a popup.
Technology stack
001
Frontend
- Next.js 15: App Router with Turbopack; role-based route groups and an auth guard
- React 18 + TypeScript
- HeroUI component system + Tailwind CSS for a consistent, responsive design
- Chart.js analytics · Framer Motion · react-beautiful-dnd · Axios · js-cookie
- React context for cart & auth state that persists across the ordering flow
002
Backend & API
- Node.js with Express 5: REST API
- MongoDB with Mongoose ODM
- JWT authentication with bcrypt-hashed credentials; role-based access
- Joi validation · Multer image uploads · Swagger (OpenAPI) docs
003
Geospatial & data
- MongoDB 2dsphere indexes and $geoNear aggregation for “near me” discovery
- Preference- and allergen-aware feeds and search via aggregation pipelines
- OpenStreetMap Nominatim geocoding + OSRM routing for delivery-time estimates
- Server-side analytics aggregations for revenue, orders and product trends
Work categories
The build spanned the full product lifecycle across these disciplines:
001
Product & UX/UI design — flows and interface for two roles under one design system.
002
Frontend engineering — Next.js client, stateful ordering flow and data visualization.
003
Backend & API — Express REST services, validation and documentation.
004
Database & geospatial — MongoDB schema design, 2dsphere indexing and aggregation.
005
Auth & security — JWT sessions, password hashing and role-based routing.
006
DevOps & deployment — productionization plan (below).
Production & scale (planned)
FastFood is a feature-complete prototype that has not yet been deployed publicly. The following is the intended path to production and the targets set for it.
001
Deployment architecture
The frontend would ship to Vercel with edge caching and image optimization, while the Express API would run as a containerized service (Render / Fly.io / AWS ECS) behind a load balancer. Data would move to MongoDB Atlas with the geospatial indexes preserved and automated backups; menu media would be served from object storage (S3) via a CDN (CloudFront) instead of the local uploads folder. A GitHub Actions pipeline would handle CI/CD, and the stack would be instrumented with structured logging, error tracking (Sentry) and uptime monitoring.
002
Hardening for real traffic
Before launch the platform would add rate limiting and input sanitization at the API edge, HTTP-only secure session cookies, image moderation on uploads, an idempotent checkout backed by a real payment provider (Stripe), and push/email notifications on order-status changes. A Redis cache would front the hottest discovery queries, and the order pipeline would move to websockets for truly live updates on both sides.
Target outcomes
The productionization goals were framed as concrete targets rather than measured results:
~50
Restaurants onboarded at launch
Onboard a first cohort of ~50 partner restaurants across a single city at launch.
<300ms
Response time for geospatial search
Sub-300 ms median response time for geospatial discovery queries under nominal load.
100s
Concurrent sessions per instance
Support hundreds of concurrent ordering sessions on a single API instance before horizontal scaling.
99.9%
Uptime, with automated rollback
99.9% target uptime with automated backups and one-click rollback.
<24h
From sign-up to first processed order
Operator funnel: from sign-up to first published menu to first processed order in under a day.
~50
Restaurants onboarded at launch
Onboard a first cohort of ~50 partner restaurants across a single city at launch.
<300ms
Response time for geospatial search
Sub-300 ms median response time for geospatial discovery queries under nominal load.
100s
Concurrent sessions per instance
Support hundreds of concurrent ordering sessions on a single API instance before horizontal scaling.
99.9%
Uptime, with automated rollback
99.9% target uptime with automated backups and one-click rollback.
<24h
From sign-up to first processed order
Operator funnel: from sign-up to first published menu to first processed order in under a day.
Note: this project has not been released to production; the deployment architecture and figures in this section are the planned/target setup, not measured results.
Next projects
FantaGraal
A gamified fantasy football app blending live match data with deep fantasy management
PayWise
A multi-tenant payroll & workforce-management platform for a labour consultancy
FantaGraal
A gamified fantasy football app blending live match data with deep fantasy management
PayWise
A multi-tenant payroll & workforce-management platform for a labour consultancy