CaterEase
I couldn't find a good caterer for my son's birthday. So I designed a better way to book one.
The Spark
My son's birthday was coming up. I needed a caterer. What followed was three days of phone calls, WhatsApp messages, and second-guessing — with no way to compare prices, no written menu, and no clue what the final bill would look like.
When my 10K Designers cohort asked me to pick a problem space, I didn't have to think twice.
The Mess
Booking a caterer in India is entirely offline. No platform, no transparency, no system.
- You call the same caterer twice and get two different prices
- Delivery, setup, and staff charges appear after you've committed
- Menu items change on event day because nothing was in writing
- If the food is bad, there's nowhere to report it
Going Deeper
I interviewed 8 people across three segments — a budget-conscious parent, a corporate event admin, and a quality-seeking professional. I also analyzed existing platforms, competitor gaps, and pricing patterns across Chennai.
View Full Research Board (FigJam) ↗
Three patterns kept showing up:
People want verified caterers, real photos, and reviews from actual customers — not curated testimonials.
The same caterer quotes different prices to different people. Hidden charges for delivery, setup, and staff are the norm.
Once you pay the advance, you have no leverage. No tracking, no agreement, no recourse if quality drops.
Who I'm Designing For
Calls 4–5 caterers, negotiates hard, always gets surprised by hidden charges after booking.
Books fast, needs invoices. Once had food arrive 30 minutes late to a client meeting with no way to track it.
Researches extensively, willing to pay premium. Paid ₹40,000 advance once and got mediocre quality with no recourse.
Getting to the Root
I ran the 5 Whys framework on each persona's top pain point. Six root causes surfaced — and they all pointed to the same gap:
There's no system. The entire catering industry runs on trust and phone calls. No digital agreements, no feedback loops, no tracking, no locked menus, no transparent pricing, no payment visibility.
The app needed to be that system.
From Research to Product
Every major screen maps directly to a research finding.
| Research Finding | Design Decision |
|---|---|
| Can't compare caterers | Standardized cards with rating, price, cuisine, verified badge |
| No transparent pricing | Full cost breakdown: food + staff + setup + delivery + GST |
| No written agreement | Locked menu with digital agreement on order summary |
| No tracking on event day | 7-stage order timeline from confirmed to completion |
| No accountability | Post-event review with 4 category ratings tied to real bookings |
| Portion confusion | Portion planner: per-head recommendation × guest count |
| Fragmented communication | In-app messaging with quick replies |
| No dietary clarity | Veg/non-veg indicators, “Pure Veg” badge, cuisine filters |
Key Screens
Here's how the key design decisions play out in the actual product.
Browse & Compare Caterers
Transparent Pricing
Order Tracking & Accountability
Beyond Figma
Most case studies end at a prototype. I wanted to see if this actually worked — not just as a Figma file, but as something you could tap through with real data.
I used Claude Code to build a fully functional React Native app.
Built with React Native (Expo), Supabase, and NativeWind. The goal wasn't production-ready code — it was proving that the research held up when you could actually use the product.
What I Learned
My best research insights came from already understanding the frustration. I wasn't discovering the problem — I was confirming and expanding what I already knew.
The screens came together fast because the decisions were already made during research. Every layout choice traced back to a finding.
Building the app forced me to confront things Figma doesn't — edge cases, empty states, real data. It made the design better retroactively.