Rasoi

Aaj khane me kya banega? (What are we cooking today?)

Comment

Inspiration

This started as a problem I live with every single day.

A bunch of us moved to different cities for work. We rent apartments, we share them with flatmates, and like a lot of young people in India, we have a cook who comes over to make our food. Sounds convenient. It mostly is. Except for one thing.

Every single day, someone has to answer the question: "Aaj khaane mein kya banega?"

And it's never simple. We come from different states, different food cultures, different bodies and diets. One of us doesn't eat rice. One is strictly vegetarian. One eats chicken sometimes but not always. One's on a diet this month. One's skipping dinner today. So every morning the group chat lights up with the same negotiation: "3 rotis for me," "I'll skip dinner," "no onion in mine," "can we do rajma?"

I added it up once. We were burning 15 to 20 minutes a day on a decision nobody even enjoyed making. That's not a food problem. That's a coordination problem. And coordination problems are exactly the kind of thing software is good at killing.

So I built Rasoi to take this decision off our plates, literally.

What it does

Rasoi is a mobile-first web app where a household sets up a shared kitchen and gets an automatically generated daily menu.

  • Accounts & shared flats — each person signs up, then joins their flat with a short human-friendly code (e.g. K7F2QX) or creates a new one. The flat's data is synced to the cloud and shared across every member.
  • People & rules — add each flatmate with their diet (veg / eggetarian / non-veg), allergies (hard rules, never violated), "never eats" categories (onion, garlic, etc.), and a per-person dish blocklist.
  • Smart menu generation — Rasoi builds a thali matching the household's daily "meal shape" (e.g. carb + dal + sabzi + side) that satisfies everyone's constraints, favours dishes people like, and avoids what was eaten recently. Don't like it? Re-roll.
  • Per-person overrides — individuals can skip a meal, swap a dish, or opt into non-veg for the day.
  • Shareable — copy the flat code or a deep link to invite flatmates instantly.

How I built it

  • Frontend: React 18 + TypeScript, built with Vite, styled with Tailwind CSS, and routed with React Router. The UI lives inside a 430px phone frame for a native-app feel.
  • State: a single shared store built on React's useSyncExternalStore, giving every screen one consistent source of truth with debounced cloud persistence.
  • Backend: Supabase (Postgres + Auth). Each flat is a row keyed by its share code, with the entire app state stored as JSONB. Email/password auth gates access, and a flat_members table maps each user to their flats.
  • Security: Row-Level Security policies so only authenticated users can read/write, and members only see their own memberships.
  • Menu engine: a constraint-satisfaction algorithm that, for each dish slot, finds dishes everyone present can eat — preferring shared favourites and de-prioritising recently used dishes. Roughly, for each slot it maximises coverage:

$$ \text{score}(d) = \sum_{p \,\in\, \text{people}} \mathbb{1}\big[p \text{ can eat } d\big] \;+\; \alpha \cdot \text{favourites}(d) \;-\; \beta \cdot \mathbb{1}\big[d \in \text{recent}\big] $$

  • Deployment: Vercel, wired to GitHub for continuous deploys, with Supabase keys injected as build-time environment variables.

Novus.ai is installed on the deployed app for measurement, as required.

Challenges I ran into

  • Keeping AI away from hard constraints. The hardest part wasn't making it smart, it was making it safe while still smart. I had to architect the engine so the AI literally never receives an illegal option, then validate again after composing. Belt and suspenders.
  • Components, not dishes. An Indian meal isn't one dish, it's a base + dal + sabzi + sides, mixed differently per person. Modeling the menu as composable components with per-person plates, instead of a single fixed menu, took a few rethinks to get right.
  • Hard vs soft, and the gray middle. Some rules are absolute (allergies, "never karela"), some are flexible defaults (prefers rice today, but fine with roti). Designing a UI and a data model that respects that difference, without overwhelming the user at setup, was a real balancing act.
  • Resisting scope creep. Every conversation surfaced a tempting new feature. The discipline of saying "that's V2" over and over was harder than any line of code.

Accomplishments that we're proud of

  • I solved a problem I actually have. This isn't a hypothetical. Rasoi works for my flat, with my real flatmates and their real, stubborn food rules. That's the bar I cared about most.
  • The hybrid engine genuinely works. Rules guard the safety, AI handles the taste. Allergies and hard no's are never violated, not even by accident, and the menus still feel varied and thoughtful instead of random. Getting that balance right was the whole game.
  • I shipped a clean, real product, not a demo. A stranger can land on the link, set up their household, and get a usable menu in minutes. No broken buttons, no "imagine if."
  • The "never serve" blocklist. A small feature, but it captures something real, the difference between can't eat (allergy) and won't eat (that one dish you despise). Both are hard no's, and Rasoi respects both.
  • It's specific on the surface, universal underneath. Rasoi proudly speaks the language of an Indian shared-cook household, but the engine, people with constraints, a shared pool, a constraint-aware generator, works for any group deciding meals together, anywhere.
  • I went from a blank mind to a shipped product. This started as "I have no idea what to build." It ended as something I'll actually use tomorrow morning.

What I learned

  • Specificity is a feature, not a limitation. My first instinct was to make this a generic "global meal planner." It would have been forgettable. Leaning into the real, lived, Indian flatmate scenario is what makes it feel true, and true is what makes people trust it.
  • AI should never touch the non-negotiables. The most important design decision was keeping AI out of the safety layer. The moment an AI puts chicken on a vegetarian's plate, the whole product loses trust and people go back to the group chat. Rules filter, AI composes, rules validate. Deterministic where it matters, smart where it helps.
  • The magic is in the boring days. Most days, nobody changes anything, the defaults just work. The product only earns its keep on the deviation days. That insight told me where to spend effort: a fast setup flow and a frictionless one-tap override, not a fancy generator.
  • Ship the small thing. I cut a lot, grocery lists, mood-based menus, cook-side WhatsApp automation, to ship the one loop that delivers the magic. A shipped V1 beats a half-built dream.

What's next for Rasoi

  • Making Rasoi more generally available: Making rasoi more generally adaptable to all households, not just indian
  • Cook-facing delivery: auto-send the settled menu to the cook as a clean WhatsApp message each morning.
  • Auto-generated grocery list based on the week's planned dishes.
  • Mood and diet awareness: "light dinner today," "I'm cutting carbs this month."
  • Smarter taste modeling: learn from what the household actually keeps vs. swaps over time.

Built With

Share this project:

Updates