Four user roles. One payment gateway that lied to me. Three rewrites of the same feature. And a GPS bug that nearly flooded my database. This is the real story behind Savor.
I was tired of building things that felt fake
At some point every developer hits a wall with tutorial projects. You've built the weather app. You've done the blog CRUD. You've cloned Twitter in a weekend. And none of it actually teaches you what it feels like when four different types of users are all touching the same data at the same time, and you have to keep their worlds completely separate.
I wanted something that would break me a little. Something with real business logic, real money, real state synchronization problems. Food delivery checked every single box.
Customers order food. Restaurants fulfill it. Delivery agents pick it up. Admins oversee everything. Four completely different actors, all interacting with overlapping data, all in real time. That's not a tutorial problem — that's a systems problem. I called it Savor.
"Building this was the first time I genuinely didn't know if something would work until I ran it. That was terrifying and that was the point."
These aren't exciting choices. They're correct ones.
Django REST Framework on the backend. React 19 + Vite on the frontend. PostgreSQL. I didn't pick these to be cool. I picked them because the problem needed a mature ORM, ACID-compliant transactions, and a frontend that wouldn't fight me on state management.
| Layer | Tech | Why it mattered |
|---|---|---|
| Backend | Django 5.1 + DRF | Atomic transactions, battle-tested ORM, signals for cross-model side effects |
| Frontend | React 19 + Vite | Fast HMR, modern concurrent features |
| Auth | SimpleJWT + rotation | Silent 60-min access token rotation, 7-day refresh — no mid-session logouts |
| Database | PostgreSQL | ACID compliance. Nested financial data cannot partially save. |
| Payments | Razorpay | Localized processing, webhook verification |
| Media | Cloudinary CDN | Edge delivery. Serving images from Django would be career-ending performance-wise. |
| Styling | Tailwind CSS 4.0 | Zero runtime. Design tokens kept four portals visually coherent. |
| Animations | Framer Motion | Micro-interactions. A premium feel isn't just design — it's movement. |
| Mapping | Leaflet.js | Live GPS plotting on the customer tracking view |
The one decision I'd revisit: React Context API over Zustand. Context was fine for the scope but I started feeling prop drilling pain by week four. If you're building something this complex, just start with Zustand.
Each portal was its own distinct problem
The customer app was where I started because it's the most tangible — you can see it, click it, feel it. The discovery architecture has two layers: global cuisines (Arabian, South Indian, Desserts) and restaurant-internal categories (Must Try, Specials). Getting that hierarchy right in the serializers took four iterations. The cart was where I first hit real business logic — you can't add items from two different restaurants to the same cart. I built persistent local state that checks restaurant ID on every cart mutation. Sounds simple. It wasn't.
The restaurant partner portal was the one I underestimated the most. I assumed it'd be a dashboard with some CRUD. What I got was the most complex portal in the system. Restaurant owners are power users. The order lifecycle — Pending → Accept → Preparing → Ready for Delivery — cascades into downstream state changes across three other portals simultaneously. I used Django signals for this. Required very careful thinking about idempotency.
The delivery agent interface is the one I'm most proud of technically. Geo-fencing logic is implemented at the queryset manager level, not the view level. A Kochi agent cannot see a Mumbai dispatch — and this isn't a frontend filter someone can bypass with a crafted request. The data simply doesn't exist in the response. Getting the earnings calculation to be atomic and accurate on the Delivered status transition took three rewrites.
The admin console could have been an afterthought. I didn't let it be. With 3,000+ menu items seeded from the Kerala restaurant dataset, server-side pagination was non-negotiable. I implemented cursor-based pagination — offset pagination on PostgreSQL becomes unusably slow past 1,000 rows.
Live demo: food-delivery-seven-bice.vercel.app
The struggles nobody writes about in project writeups
01 — Multi-tenancy took three complete rewrites
The first version filtered at the serializer level. That works until a restaurant owner in tenant A briefly sees an order from tenant B during a race condition. The second version moved filters to the view layer — better, still bypassable. The third version put tenant scoping into the queryset manager. That's where it needed to be from the start. Two full days of debugging a bug that shouldn't have existed if I'd thought it through properly the first time.
02 — Razorpay webhook verification in development is a trap
Webhooks need a publicly accessible endpoint. In development, you don't have one. I spent a full day debugging a signature verification failure that turned out to be a timezone mismatch in how I was constructing the HMAC payload. I ended up building a local webhook simulator specifically for dev testing, stripped out before production. This is not in any Razorpay tutorial I found.
03 — GPS telemetry nearly destroyed my database
Early testing: delivery agents broadcast coordinates on every geolocation API event. The browser's watchPosition fires multiple times per second. At 10 concurrent test agents, that was hundreds of database writes per minute for a field that only needs to update every few seconds. I added a frontend debounce and a backend timestamp guard that rejects updates more frequent than 3 seconds. The database survived. My nerves less so.
04 — CSS across four portals with four different visual languages
The customer app is warm and premium. The delivery interface is utilitarian and fast. The admin console is dense and data-heavy. The partner portal is somewhere between all three. Tailwind's design token system helped, but by week three the tokens were drifting in ways that required a full audit to fix. CSS architecture is genuinely hard at scale and nobody talks about the multi-portal version of this problem.
05 — The cart constraint bug that appeared in production and nowhere else
Cart state was using localStorage with a restaurant ID key. In production, the Vercel edge occasionally delivered a cached app version mid-session with a stale cart key. The constraint check passed because the key comparison was against an old restaurant ID. Never reproduced locally. Fixed by adding a session-scoped cart version hash alongside the restaurant ID. The worst kind of bug: requires production traffic to surface.
The one decision that saved the whole system
Early on I had a choice: enforce multi-tenancy at the UI layer or the data layer. The UI layer is easier — you just filter what you show. The data layer is harder — you modify how querysets are constructed at the model level so filtered-out data is never even fetched.
I chose the data layer. Every restaurant-scoped query goes through a custom queryset manager that injects the tenant ID before the SQL hits PostgreSQL. Bypassing tenant isolation requires compromising the Django application layer itself — not just crafting a request with different parameters.
For financial data, I used @transaction.atomic everywhere that touched nested profile updates. A restaurant's payout configuration and platform commission rate update in a single atomic operation. Either both succeed or neither does. This is not optional when you're dealing with money.
"The architecture that survives isn't the one that looks cleanest in a diagram. It's the one that fails gracefully when things go wrong — and they will go wrong."
You only understand failure modes by creating them
You can read about multi-tenancy. You can read about JWT rotation. You can understand atomic transactions in the abstract. But there's a kind of understanding you only get from tracing a data leakage bug through four layers of abstraction at 11pm, finding the one queryset that forgot to filter by restaurant_id, and sitting with the fact that your first two architectural decisions were wrong.
Building Savor taught me that system design isn't about choosing the right technologies. It's about understanding the failure modes of every interface between them. The Razorpay integration fails if my webhook handler is slow. GPS tracking floods my database if the frontend isn't debounced. Multi-tenant isolation breaks if I filter at the wrong layer. None of these are things you learn by reading. You learn them by breaking them, badly, and having to fix it.
If you're in the middle of a solo project right now and it feels like the complexity is winning — it probably is, temporarily. That's what week three feels like. The tangle is the work. Push through it.
Live demo: food-delivery-seven-bice.vercel.app
Backend API: food-delivery-backend-c4pe.onrender.com/api
Github: food-delivery-github
Postman collection at backend/postman.json — all auth rotation, order status, and multi-tenant profile endpoints pre-configured.
Top comments (0)