Colleatz Food Delivery Platform: A Performance Case Study

Food delivery is an unforgiving product category. Users expect instant browsing, quick ordering and live tracking, and they notice every delay. A slow menu page costs orders. A failed step at checkout loses the customer. A stale order status turns into a support call.

A food delivery startup asked us to build Colleatz, a modern food ordering platform that connects customers with local restaurants. Building a food delivery app was never the hard part, since plenty exist. The hard part was making one that felt fast on every interaction, kept working on patchy mobile connections, and could handle a high volume of orders across every device.

Food delivery platforms demand sub-second performance and bulletproof reliability

Architecture decisions

We built Colleatz on Next.js, FastAPI and MongoDB, with the frontend on Vercel and backend services on Azure. That stack gives server-side rendered menu pages for speed and SEO, async WebSocket support for real-time order tracking, and a document model that matches the nested restaurant, menu and item structure of food delivery data.

Why Next.js + FastAPI + MongoDB

Colleatz Architecture
├── Frontend: Next.js (React)
│   ├── Server-side rendering for menu pages
│   ├── Client-side state for cart and ordering flow
│   ├── Progressive web app capabilities
│   └── Mobile-first bottom navigation
├── Backend: FastAPI (Python)
│   ├── Restaurant and menu API
│   ├── Order processing
│   └── WebSocket server for real-time updates
├── Database: MongoDB
│   ├── Restaurants and menus
│   ├── Orders
│   └── User profiles, preferences and order history
├── Notifications: Twilio
│   ├── OTP verification
│   └── Order status SMS updates
└── Deployment
    ├── Vercel (frontend)
    └── Azure (backend services)

Why MongoDB? Food delivery data is document shaped. A restaurant has menus, menus have categories, categories have items, and items have variants and add-ons. In a relational schema that hierarchy lives in several tables joined at read time. In MongoDB it can be one document with nested arrays, which makes the most common read on the platform (load this restaurant’s full menu) a single query. The tradeoff is that cross-restaurant reporting gets harder, but for a consumer ordering app, menu reads dominate.

Why FastAPI? FastAPI is async native, which suits a backend that keeps many WebSocket connections open for order tracking while serving ordinary API requests. We break the broader tradeoff down in our Django REST Framework vs. FastAPI comparison.

Performance design

Server-side rendering for menu pages

Menu pages are where users spend their time on any food delivery platform, so they get the most attention. Colleatz renders them on the server with Next.js:

Menu Page Strategy
├── First visit: server-side rendered
│   └── Full menu data in the initial HTML (no loading spinner)
└── Later navigation: client side
    ├── React state preserved (the cart persists)
    └── No full page reloads between restaurants

The point of this split is simple. The first load has to be fast and complete, which SSR handles. Everything after that has to feel instant, which client-side state handles.

The smart cart

The cart is the highest-friction part of food ordering. Users add items, change quantities, switch restaurants and often leave halfway through. Colleatz has a persistent cart, so items survive a closed tab, with prices recalculated in real time on every change. A wishlist lets users save favorite items for quick reordering, and user preferences and order history are stored with the profile.

Feature	What it does
Persistent cart	Items stay in the cart across sessions
Real-time pricing	Totals recalculate on every modification
Wishlist	Save favorite items for quick reordering
Preferences and history	Personalized settings and past orders on the profile

Real-time order tracking

Once an order is placed, users expect live status. Colleatz pushes order status updates over WebSockets, a choice we would make again for any tracking screen that also needs to send events back. Our server-sent events vs. WebSockets guide covers when the simpler one-way option is enough.

A typical status flow for food delivery looks like this:

Order Status Flow
├── Placed
├── Accepted by the restaurant
├── Preparing
├── Out for delivery
├── Delivered
└── Each transition:
    ├── WebSocket push to the user's browser
    └── SMS via Twilio

On mobile networks, connections drop all the time as phones switch between WiFi and cellular. Any WebSocket tracking system needs reconnection logic and a way to catch the client up on status changes it missed while offline. Without that, the tracking screen quietly goes stale, which is worse than no tracking at all.

Mobile-first design

Colleatz is designed mobile first. Its primary navigation is a bottom tab bar placed for thumb reach, because one-handed use on a phone is the normal case for ordering food.

Tab	Function
Home	Restaurant discovery
Search	Find restaurants or dishes
Cart	Current order
Orders	Order history and tracking
Profile	Settings and preferences

Progressive web app capabilities round this out. A PWA can be installed to the home screen and cache static assets and data, which gives mobile users an app-like experience from the same Next.js codebase.

Twilio integration

SMS on Colleatz does two jobs: OTP verification at login, and order status updates.

Notification	Trigger
Login OTP	User requests a login code
Order update	Order status changes

For any SMS integration like this, plan for bursts. Orders cluster around mealtimes, and sending messages through a queue rather than inline keeps a busy evening from running into provider rate limits.

Results

Outcome	What shipped
Ordering flow	A smooth path from browsing to checkout
Order tracking	Real-time order status updates
Mobile	Progressive web app capabilities for mobile users
Performance	Optimized with server-side rendering

Lessons learned

1. MongoDB fits read-heavy document data

The restaurant, menu and item hierarchy maps cleanly onto MongoDB’s document model. A single read returns a restaurant with its menus, categories and items. For a workload dominated by menu browsing, that is the access pattern worth optimizing for.

2. SSR plus client-side state is the right pattern

The first page load must be fast, and SSR handles it. Everything after that must feel instant, and client-side state handles it. This hybrid gives you SEO-friendly pages with a fast first paint and app-like interaction after hydration.

3. WebSocket reliability matters more than WebSocket speed

It is tempting to focus on shaving latency off each status message. For order tracking, reliability matters far more. A status update that arrives a little late is fine. One that never arrives because the phone switched networks is a support ticket.

4. Progressive web apps are underrated

PWA capabilities (home screen installation, offline caching, push notifications), the same ones we cover in our guide to progressive web apps, can give a startup near-native functionality without app store review cycles. For a team iterating quickly, that is a real advantage.

Colleatz reinforced our belief that performance is a feature, not an optimization. In food delivery, where users are hungry and impatient, the speed of the product is a large part of the product.

---

Building an e-commerce or food delivery platform? Get in touch, we specialize in high-performance web applications.