Master Project Plan — {{BRAND}} Cloud Kitchen, Hyderabad

Version: 1.0 · Owner: Founder · Date: 2026-07-31 Capital available: < ₹5,00,000 · Stage: Pre-launch · Founder profile: Technical (builds own software)

1. Vision

Run one profitable cloud kitchen in Hyderabad, then extract the software that made it profitable and sell it to other kitchens.

The kitchen is customer zero. Every internal tool is built as if an external kitchen will use it next: multi-tenant data model, API-first, no hardcoded brand logic.

2. The Strategic Problem

A cloud kitchen that only sells on Swiggy and Zomato is not a business — it is a contractor with no customer list. Aggregators take ~22% commission + 18% GST on that commission + discount funding, leaving roughly 27% contribution margin. The same order sold direct leaves ~47%.

Therefore the entire plan is organised around one number: % of revenue coming from channels you own.

3. Objectives (12 months)

O5 is the one most founders skip. Track it weekly. If you are still manually compiling sales reports in Month 4, the SaaS thesis is dead.

4. Capital Allocation

Total deployable: ₹4,80,000 (₹20,000 held as absolute reserve, untouchable).

One-time setup — ₹2,88,000

Month-1 operating float — ₹1,92,000

Founder draws zero salary until Month 4. This is not motivational advice — the model does not close otherwise.

5. Runway Reality Check

At ₹86,000/month fixed cost and zero revenue, ₹1,92,000 lasts 2.2 months. You do not have a 6-month runway. You have until roughly Week 10 to be contribution-positive.

Consequences that follow directly from this:

• Launch on aggregators first, because they bring demand on day one. Direct channel is built after cash is flowing, not before.
• Do not build the website before launch. Build it in Weeks 5–8 while the kitchen runs.
• Do not hire a third person until 45 orders/day sustained for 14 days.

6. Timeline

7. Team & Ownership

Hiring trigger for #3 (second cook): 45 orders/day sustained 14 days. Not before.

8. Success Metrics — Reviewed Every Monday 9 AM

9. Top Risks (full register in 10-risk-register.md)

1. Cash runs out before breakeven — mitigated by hard Week-10 gate and a pre-agreed kill/pivot decision.
2. Aggregator rating drops below 4.0 — visibility collapses, orders halve. Mitigated by QA SOP and a review-response agent.
3. Single-cook dependency — one person quitting stops the business. Mitigated by SOP-documented recipes with gram-level specs from Day 1.
4. Discount addiction — margin evaporates chasing volume. Mitigated by a hard floor: never fund a discount that drops contribution below ₹70/order.

10. Related Documents

90-Day Execution Roadmap

Rule: a phase does not end because the calendar moved. It ends when exit criteria are met. If a phase slips, cut scope inside it — never skip the exit gate.

Owner column: F = Founder, C = Cook, H = Helper, S = Software/automation.

Phase 0 — Legal & Location (Week 1–3)

Goal: legally able to cook and sell, in a space with a signed lease.

Exit criteria: FSSAI number in hand · lease signed · GSTIN active · bank + payment gateway live.

The FSSAI number is the hard dependency — Swiggy and Zomato onboarding cannot start without it, and onboarding itself takes 2–3 weeks. Apply on Day 1, not Day 10.

Phase 1 — Build the Kitchen (Week 3–4)

Goal: a kitchen that can produce the finalised menu at target quality, repeatedly.

Exit criteria: every SKU cooked 3× · actual food cost within 3% of plan · no SKU below ₹70 aggregator contribution · packaging survives a 5-km bike ride upside-down.

Task 1.4 is the one that makes the business sellable later. A recipe living only in your cook's head is a liability, not an asset. Write it down in grams and seconds before you serve one customer.

Phase 2 — Launch (Week 5–6)

Goal: live on both aggregators with correct pricing and photography.

Exit criteria: live on both platforms · ≥30 orders fulfilled · zero food-safety incidents · avg dispatch time < 22 min · rating ≥ 4.2.

2.8 costs ₹1.20 per order and is the single highest-ROI item in this entire roadmap. Every box that leaves without it is a customer you are renting from Swiggy instead of owning.

Phase 3 — Stabilise & Instrument (Week 7–9)

Goal: consistent quality, and data flowing into your own database.

Exit criteria: 26+ orders/day for 7 consecutive days · rating ≥ 4.3 · founder manual admin < 12 hrs/week · every order in your own DB.

Phase 4 — Own the Customer (Week 8–11)

Goal: direct ordering live and producing real volume. This is where the business stops being a contractor.

Exit criteria: ≥10% of orders direct · direct order flow works with zero manual intervention · repeat rate ≥ 22%.

On 4.7 — you can undercut the aggregator by 15% and still earn 30% more per order. Say this explicitly on the box, the website, and in every WhatsApp message. It is a genuinely better deal for the customer, which is why it works.

Phase 5 — Recurring Revenue & Automation (Week 10–13)

Goal: predictable revenue and a back office that mostly runs itself.

Exit criteria: 50+ active subscriptions · founder admin < 6 hrs/week · net profit positive for 2 consecutive months.

Gate Reviews

Three hard decision points. Write the answer down; do not let a bad number slide.

Never proceed past a failed gate by increasing marketing spend. Every failure mode in this business ends with "so we spent more on ads."

Unit Economics & Financial Model

This is the most important document in the folder. Every other decision is downstream of these numbers. Update the input cells monthly.

1. Channel Contribution Comparison

Assumption: order value ₹350, food cost 30%, packaging ₹25.

A. Aggregator order (Swiggy / Zomato)

B. Direct order (Website / WhatsApp)

The whole strategy in one line

A direct order is worth 1.76 aggregator orders.

Moving 100 orders/month from aggregator to direct adds ₹7,186/month in contribution with zero increase in food production. This is why the WhatsApp reorder loop (Week 5–6) outranks almost everything else in the roadmap.

2. Fixed Cost Base (Monthly)

Note: gas and electricity are semi-variable — they scale ~₹1,200 per additional 10 orders/day. Treated as fixed here for conservatism.

3. Breakeven

Blended contribution assumption at launch: 100% aggregator = ₹94/order.

Breakeven orders/month = 86,000 ÷ 94 = 915 orders
Breakeven orders/day   = 915 ÷ 30    = 30.5 orders/day

As direct share rises, breakeven falls:

Every 20 points of direct share removes ~4 orders/day from your breakeven requirement. That is the compounding effect worth optimising for.

4. 12-Month P&L Projection

Conservative ramp. Assumes 30 operating days/month.

Year 1 totals: Revenue ₹65.2L · Net ₹8.68L · Cumulative cash trough ≈ −₹1,56,000 at end of M3.

Fixed cost steps: +₹12,000 at M5 (2nd cook), +₹12,000 at M8 (packer/dispatch), +₹12,000 at M11 (part-time ops).

The critical read

Your cash trough (−₹1.56L cumulative by M3) sits inside your ₹1.92L operating float with only ₹36,000 to spare. There is no margin for a bad month. Mitigations, in order of preference:

1. Negotiate the deposit to 2 months → frees ₹30,000.
2. Delay hire #2 (helper) to Week 3 → saves ~₹10,000.
3. Buy 60% of equipment used, not 100% new → already assumed; do not slip on this.
4. Pre-sell 30 subscriptions before launch at ₹2,999/15 meals → ₹90,000 upfront. Highest-leverage move available to you. See Marketing Plan §3.

5. Menu-Level Costing Template

Fill one row per SKU. Do not launch any dish where contribution < ₹70 on the aggregator channel.

Formula for the aggregator contribution column:

= SP − (SP × 0.10)          discount
    − (SP × 0.22)           commission
    − (SP × 0.22 × 0.18)    GST on commission
    − RM_cost − packaging

Rules that follow from the math:

• Any dish under ₹180 is structurally unprofitable on aggregators after discount + commission. Sell those only as combo attachments or direct-only.
• Push AOV with combos, not with price increases. A ₹60 add-on at 25% food cost adds ₹45 of contribution at zero fixed cost.
• Re-cost every SKU when any input moves >10%. The Inventory Agent (see AI plan) does this automatically.

6. Metrics Definitions (so the dashboard never lies)

LTV:CAC target ≥ 3:1 by Month 6. Below 2:1, stop paid spend and fix retention first.

Compliance & Licensing — Hyderabad, Telangana

Read this first: fees and procedures change, and some requirements depend on your building, floor area, and seating. Items marked ⚠️ VERIFY must be confirmed with the issuing authority or a local FSSAI/GST consultant before you rely on them. Budget ₹5,000–8,000 for a consultant — at this capital level it is cheaper than one rejected application delaying your launch by three weeks.

1. Critical Path

Only one item genuinely gates your launch date:

FSSAI → aggregator onboarding is a 4–7 week serial chain. Nothing else on this page is as time-sensitive. Apply the day the lease is signed.

2. License Register

Not applicable at your headcount: EPF (triggers at 20 employees), ESI (triggers at 10). Revisit when you cross 9 staff.

3. FSSAI — Detail

Which license? Registration (₹100/yr) covers turnover up to ₹12 lakh. Your Year-1 projection is ₹65 lakh, so you need the State License (₹12L – ₹20Cr band, ₹2,000/yr).

Do not under-declare turnover to save ₹1,900. Operating above your license band is a compliance breach, and aggregators reconcile your declared turnover against payouts.

Apply at: foscos.fssai.gov.in → Form B (License application)

Documents to have scanned before you start:

• Form B, completed and signed
• Photo ID + address proof of proprietor (Aadhaar + PAN)
• Passport photo of proprietor
• Rent agreement + NOC from property owner
• Kitchen layout plan with dimensions
• List of equipment with capacities
• List of food categories to be handled
• Water potability test report from an NABL-accredited lab (~₹2,000)
• Food Safety Management System plan
• Proof of business constitution (proprietorship declaration / incorporation certificate)

⚠️ The water test report is the item that most commonly delays applications. Book the lab test in Week 1, not when the portal asks for it.

Post-issue obligations:

• Display the license at the premises
• Print the 14-digit FSSAI number on all packaging and on both aggregator listings (mandatory)
• Annual return FSSAI Form D1 ⚠️ VERIFY applicability for your category
• Renew ≥30 days before expiry

4. GST — Detail

Registration is mandatory in practice. Even below the ₹20 lakh services threshold, Swiggy and Zomato require a GSTIN to onboard you.

Rate: restaurant service is 5% without Input Tax Credit. This has a direct consequence for your model: the 18% GST you pay on aggregator commission is a real cost, not a recoverable credit. It is built into the unit economics as such.

Aggregator sales: under Section 9(5) of the CGST Act, e-commerce operators (Swiggy/Zomato) discharge GST on restaurant services supplied through their platform. You still report these supplies. ⚠️ VERIFY exact reporting treatment with your CA — this is the single most commonly mis-filed item for cloud kitchens.

Direct sales: you collect and remit 5% yourself.

Filing cadence: GSTR-1 and GSTR-3B monthly (or QRMP quarterly if eligible — ask your CA; quarterly is less admin at your scale).

Budget ₹2,000/month for a CA. Do not self-file. The time cost alone exceeds the fee, and errors here compound quietly.

5. Ongoing Compliance Calendar

Automate every one of these as a recurring reminder — see AI & Automation Plan, agent A9 (Compliance Calendar Agent). A lapsed FSSAI license gets you delisted from both aggregators within days, which is a business-ending event at your cash position.

6. Food Safety — Non-Negotiables

These are not bureaucratic box-ticking. One food poisoning incident, publicly posted, ends the brand.

• Separate raw and cooked storage, always
• Cooked-food hot holding above 60°C; cold storage below 5°C
• Probe thermometer used and logged twice daily
• All prepped items labelled with prep date/time; FIFO enforced
• Daily deep-clean of surfaces; weekly of equipment
• Food handlers: hairnets, gloves, closed footwear, no jewellery
• Sick staff do not enter the kitchen — written policy, no exceptions
• Monthly pest control with signed service records
• Retain a 48-hour reference sample of each dish batch, refrigerated
• Tamper-evident seal on every delivery bag

The reference-sample practice (last item but one) is what lets you defend yourself if a complaint escalates. It costs nothing and it is the difference between "we tested the batch" and "it's your word against theirs."

7. Insurance

Not affordable in Month 1 at your capital level. Add to the budget the month you turn profit-positive (projected M4). Note it in the risk register so it does not get forgotten.

Operations Manual & SOPs

Audience: kitchen staff. Print §3–§8 and laminate them on the kitchen wall. Rule: if a task is done more than twice a week and isn't written here, it isn't a process — it's a habit that will break the week someone is absent.

1. Daily Rhythm

Two service windows, one prep cycle each. Do not run all-day service at your staffing level — you get worse food, longer dispatch times, and a falling rating, which costs more than the incremental orders are worth.

2. Equipment Buy List (₹1,10,000 target)

Where to buy used in Hyderabad: Begum Bazaar (hotel equipment cluster), OLX/Facebook Marketplace restaurant closures, and equipment dealers on Ranigunj / Secunderabad. Restaurant closures are the best source — a full kitchen at 40% of new.

Never buy used: the scale, thermometers, or fire extinguishers. Precision and safety items are where a ₹3,000 saving costs you a ₹50,000 problem.

3. SOP-01 — Opening Checklist

Owner: Helper · Time: 08:30 · Duration: 25 min · Sign off daily

• Unlock, lights on, exhaust on
• Check fridge temp < 5°C, freezer < −18°C — log both readings
• Any temperature out of range → escalate to Founder immediately, do not use the stock
• Gas cylinder level check; if <25%, flag for reorder
• Visual pest check — corners, drains, storage
• Sanitise all prep surfaces
• Verify yesterday's leftover prep: smell, colour, label date. Anything over 24 hrs is discarded, no judgement calls.
• Confirm packaging stock ≥ 1.5× today's forecast
• Staff hygiene: hairnets on, nails trimmed, no jewellery, hands washed
• Check the auto-generated prep sheet on the kitchen tablet
• Sign and date the checklist

4. SOP-02 — Closing Checklist

Owner: Cook + Helper · Time: 22:45 · Duration: 35 min**

• Menu confirmed offline on both platforms
• Log wastage by item, in grams, in the tablet (mandatory — this feeds the forecast agent)
• Label and refrigerate all usable prep with date + time
• Discard anything past its window
• Take and store 48-hour reference samples of each dish batch
• Clean: range, surfaces, floor, sinks, drains
• Empty and sanitise bins; take out waste
• Wash and stack all utensils
• Fridge/freezer temp recheck and log
• Gas off at the cylinder, electricals off except refrigeration
• Note tomorrow's shortages in the tablet
• Lock up, confirm in the ops WhatsApp group

The wastage log is the one item that gets skipped when everyone is tired. It is also the input to demand forecasting, purchase automation, and margin analysis. Make it the last thing before cleaning, never after.

5. SOP-03 — Order Fulfilment

Target: order accepted → handed to rider in under 18 minutes.

1. Order lands on the POS screen (single feed, both platforms)
2. Accept within 60 seconds — delayed acceptance directly hurts platform ranking
3. Cook reads the ticket aloud; helper confirms — catches 90% of wrong-item errors
4. Cook prepares to the recipes.yaml spec. No improvisation, ever.
5. Helper assembles: correct container, sealed lid, sauces/cutlery per SKU rules
6. Check against ticket, item by item, out loud
7. Tamper-evident seal applied
8. Reorder card (QR → WhatsApp) dropped in — every single order
9. Label bag with order ID; place in the dispatch rack
10. Hand to rider; mark ready in POS

Error handling

6. SOP-04 — Procurement

Always maintain a second vendor per category, even if you buy 90% from the first. A single-vendor category is a single point of failure, and the day your only vegetable supplier doesn't show up is the day you go offline.

Receiving procedure:

1. Weigh everything. Short-weighting is the most common and most invisible leakage in food businesses.
2. Reject visibly poor quality on the spot — accepting it once sets the standard permanently.
3. Log quantity, rate, and vendor in the tablet.
4. Photograph the invoice → auto-filed by the invoice agent.
5. Store immediately: FIFO, labelled, correct temperature zone.

Payment terms: target 7-day credit from Month 2 once you have a payment track record. At your cash position, ₹45,000 of vendor credit is effectively free working capital.

7. SOP-05 — Inventory

Method: par-level system. Every SKU has a par (target stock) and a reorder point.

• Physical count: daily for high-value/perishable, weekly for dry goods
• Reconciliation: weekly — theoretical consumption (from sales × recipe) vs actual consumption
• Variance > 6% is an investigation trigger, not a rounding error. Causes, in order of likelihood: portion drift, unlogged wastage, theft.

8. SOP-06 — Customer Complaints & Refunds

Response SLA: 30 minutes, always.

Refund policy: refund fast and without argument below ₹500. The cost of a ₹350 refund is ₹350. The cost of a 1-star public review is roughly 20 lost orders. This is not generosity, it's arithmetic.

Escalate to Founder within the hour if: any illness is alleged, any legal or FSSAI mention appears, the order value exceeds ₹1,500, or the customer is a corporate/subscription account.

9. SOP-07 — Weekly Ops Review

Every Monday, 09:00, 45 minutes, Founder + Cook.

Agenda:

1. Last week's numbers: orders, AOV, contribution, rating, wastage %
2. Every complaint from the week — root cause, not just resolution
3. Inventory variance review
4. Top 3 and bottom 3 SKUs by contribution
5. One process improvement to implement this week
6. Next week's forecast and prep plan

Output: a dated note in /ops-reviews/, with owners and dates on every action item. An action item without a name and a date is a wish.

10. Recipe Standard — recipes.yaml

Every dish is specified to gram and second precision. This file is the single source of truth, and it is also the first real asset of the software business.

- sku: DISH_001
  name: "{{DISH_NAME}}"
  selling_price: 289
  yield_portions: 1
  prep_time_sec: 240
  ingredients:
    - item: onion_paste
      grams: 60
      cost_per_kg: 90
    - item: chicken_boneless
      grams: 180
      cost_per_kg: 260
    - item: oil_refined
      grams: 15
      cost_per_kg: 140
  method:
    - step: "Heat oil to shimmer, ~45 sec"
    - step: "Add onion paste, cook 3 min until light brown"
    - step: "Add chicken, sear 4 min"
  packaging:
    container: "750ml round, black"
    sauces: ["mint_chutney_30g"]
    cutlery: true
  allergens: ["dairy"]
  hold_temp_c: 63

Why gram-level matters: it turns portion control into a measurable variance, makes food cost calculable per order in real time, lets a new cook produce the same dish on day one, and — critically — makes the operation transferable to a second kitchen without you standing in it.

Product Requirements Document — Internal Platform

Audience: you (the builder). Principle: every module is built multi-tenant from line one. The kitchen is tenant_id = 1.

1. Build Order (non-negotiable)

You have ~₹18,000 for tools and limited time. Build in strict dependency order and ship nothing before its dependency works.

Do not build M6 before Week 12. A demand forecast trained on 3 weeks of launch-noise data will be worse than the cook's intuition.

2. Stack

Total fixed software: ~₹3,500/month. That is the entire tech budget and it is correct at this stage.

Why WhatsApp Cloud API directly, not a BSP

BSPs (AiSensy, Interakt, Wati) charge ₹1,000–3,000/month plus a per-message markup for a UI you don't need — you can write the webhook handler yourself. Going direct to Meta means paying Meta's per-message rates with no reseller margin. Verify current India per-message pricing on Meta's developer pricing page before you model it — the rate card changes, and utility vs. marketing vs. service messages are priced differently. Service conversations (user-initiated, within the 24-hour window) are the cheapest category and cover most reorder traffic.

3. Data Model

Multi-tenant from day one. Every table carries tenant_id; enforce isolation with Supabase Row Level Security, not application code.

-- Core tenancy
create table tenants (
  id            bigserial primary key,
  name          text not null,
  fssai_number  text,
  gstin         text,
  created_at    timestamptz default now()
);

create table outlets (
  id          bigserial primary key,
  tenant_id   bigint not null references tenants(id),
  name        text not null,
  address     text,
  lat         numeric,
  lng         numeric
);

-- Catalogue
create table skus (
  id             bigserial primary key,
  tenant_id      bigint not null references tenants(id),
  code           text not null,
  name           text not null,
  selling_price  numeric(10,2) not null,
  material_cost  numeric(10,2),
  packaging_cost numeric(10,2),
  is_active      boolean default true,
  unique (tenant_id, code)
);

create table recipe_lines (
  id           bigserial primary key,
  tenant_id    bigint not null references tenants(id),
  sku_id       bigint not null references skus(id),
  ingredient   text not null,
  grams        numeric(10,2) not null,
  cost_per_kg  numeric(10,2) not null
);

-- Customers (the actual asset)
create table customers (
  id             bigserial primary key,
  tenant_id      bigint not null references tenants(id),
  phone_e164     text not null,
  name           text,
  first_order_at timestamptz,
  last_order_at  timestamptz,
  order_count    int default 0,
  lifetime_value numeric(12,2) default 0,
  segment        text,                    -- new | repeat | lapsed | vip
  unique (tenant_id, phone_e164)
);

create table addresses (
  id           bigserial primary key,
  tenant_id    bigint not null references tenants(id),
  customer_id  bigint not null references customers(id),
  line1        text not null,
  landmark     text,
  pincode      text,
  lat          numeric,
  lng          numeric,
  is_default   boolean default false
);

-- Orders
create type order_channel as enum ('swiggy','zomato','whatsapp','web','phone');
create type order_status  as enum ('placed','accepted','preparing','ready','dispatched','delivered','cancelled','refunded');

create table orders (
  id                 bigserial primary key,
  tenant_id          bigint not null references tenants(id),
  outlet_id          bigint not null references outlets(id),
  customer_id        bigint references customers(id),   -- null for aggregator orders
  channel            order_channel not null,
  external_ref       text,                              -- Swiggy/Zomato order id
  status             order_status not null default 'placed',
  gross_amount       numeric(10,2) not null,
  discount_amount    numeric(10,2) default 0,
  commission_amount  numeric(10,2) default 0,
  gst_on_commission  numeric(10,2) default 0,
  delivery_cost      numeric(10,2) default 0,
  packaging_cost     numeric(10,2) default 0,
  food_cost          numeric(10,2) default 0,
  net_realisation    numeric(10,2),
  contribution       numeric(10,2),                     -- computed on write
  placed_at          timestamptz not null,
  dispatched_at      timestamptz,
  delivered_at       timestamptz,
  unique (tenant_id, channel, external_ref)
);

create table order_items (
  id          bigserial primary key,
  tenant_id   bigint not null references tenants(id),
  order_id    bigint not null references orders(id) on delete cascade,
  sku_id      bigint not null references skus(id),
  qty         int not null,
  unit_price  numeric(10,2) not null
);

-- Operations
create table inventory_items (
  id             bigserial primary key,
  tenant_id      bigint not null references tenants(id),
  name           text not null,
  unit           text not null,           -- kg | litre | piece
  par_level      numeric(10,2),
  reorder_point  numeric(10,2),
  current_stock  numeric(10,2) default 0,
  last_rate      numeric(10,2)
);

create table stock_movements (
  id           bigserial primary key,
  tenant_id    bigint not null references tenants(id),
  item_id      bigint not null references inventory_items(id),
  movement     text not null,             -- purchase | consumption | wastage | adjustment
  qty          numeric(10,2) not null,
  rate         numeric(10,2),
  note         text,
  occurred_at  timestamptz default now()
);

create table subscriptions (
  id                 bigserial primary key,
  tenant_id          bigint not null references tenants(id),
  customer_id        bigint not null references customers(id),
  plan_code          text not null,
  meals_total        int not null,
  meals_remaining    int not null,
  price              numeric(10,2) not null,
  razorpay_sub_id    text,
  status             text not null,        -- active | paused | expired | cancelled
  starts_on          date not null,
  ends_on            date
);

create table reviews (
  id            bigserial primary key,
  tenant_id     bigint not null references tenants(id),
  channel       order_channel not null,
  external_ref  text,
  rating        int,
  body          text,
  responded_at  timestamptz,
  response_body text,
  received_at   timestamptz default now()
);

RLS pattern — apply to every table:

alter table orders enable row level security;

create policy tenant_isolation on orders
  using (tenant_id = (auth.jwt() ->> 'tenant_id')::bigint);

Do this on every table at creation time. Retrofitting RLS onto a live multi-tenant DB is how data leaks happen.

4. Key API Surfaces

Design these as public-shaped APIs even while you're the only consumer — it is what makes M7 a config change rather than a rewrite.

Webhook rules: verify signatures on every inbound webhook (Razorpay HMAC, Meta X-Hub-Signature-256); make every handler idempotent on the external reference ID; return 200 fast and process async. Aggregators and payment gateways both retry aggressively, and a non-idempotent order handler will create duplicate orders in production.

5. Contribution Calculation (single source of truth)

Compute on write, store on the order row. Never recompute in the dashboard — you want historical rows to reflect the economics that actually applied at the time.

// lib/economics.ts
type ChannelEconomics = {
  commissionRate: number;   // 0.22 for aggregators, 0 for direct
  gstOnCommission: number;  // 0.18
  paymentRate: number;      // 0.02 direct, 0 aggregator
};

export function computeContribution(order: OrderInput, cfg: ChannelEconomics) {
  const commission = order.grossAmount * cfg.commissionRate;
  const gstOnComm = commission * cfg.gstOnCommission;
  const gateway = order.grossAmount * cfg.paymentRate;

  const netRealisation =
    order.grossAmount - order.discountAmount - commission - gstOnComm - gateway;

  const contribution =
    netRealisation - order.foodCost - order.packagingCost - order.deliveryCost;

  return { netRealisation, contribution };
}

Food cost comes from recipe_lines at order time — sum grams × cost_per_kg / 1000 across every SKU in the order. That is why gram-level recipes (Ops Manual §10) are a prerequisite, not a nice-to-have.

6. LLM Architecture and Cost

Route by task difficulty. Most kitchen automation is classification and templated generation — that does not need a frontier model.

Three cost levers, in order of impact:

1. Prompt caching. Your menu, recipe list, and system prompt are identical on every WhatsApp turn. Cache them — reads cost ~0.1× base input rate. On Claude Opus 5 the minimum cacheable prefix is 512 tokens; on Sonnet 5 and Haiku 4.5 it is 1024. Put stable content (system prompt, menu) first and volatile content (the customer's message) last, or the cache never hits. Verify with usage.cache_read_input_tokens — if it's zero across repeated requests, something in your prefix is changing (a timestamp is the usual culprit).
2. Model tiering. Don't run Opus on order-taking.
3. Batches API for anything non-interactive — 50% off.

import anthropic

client = anthropic.Anthropic()

MENU_CONTEXT = load_menu_prompt()   # stable — cache this

response = client.messages.create(
    model="claude-haiku-4-5",
    max_tokens=1024,
    system=[{
        "type": "text",
        "text": MENU_CONTEXT,
        "cache_control": {"type": "ephemeral"},
    }],
    messages=conversation,           # volatile — after the cache breakpoint
)

Realistic monthly LLM spend at 50 orders/day: roughly ₹1,500–3,000 with caching and correct tiering, versus ₹10,000+ if you route everything to a frontier model without caching. Instrument usage on every call from day one — retrofitting cost attribution is painful.

7. Environments & Ops

• Two environments only: local and production. Staging is overhead you cannot afford yet.
• Secrets in Vercel env vars and Supabase Vault. Never in the repo.
• Backups: Supabase daily automated backups; additionally, a weekly pg_dump to your own storage. Platform backups are not a backup strategy on their own.
• Monitoring: Sentry free tier for errors; a single n8n workflow that pings /api/health every 5 minutes and WhatsApps you on failure.
• The kitchen must work without the software. Printed menu, a phone, and a paper order pad in a drawer. If Vercel is down during dinner service, you still serve dinner.

8. Path to Multi-Tenant SaaS (M7, Month 6+)

The refactor is small if you built §3 correctly. What actually needs doing:

• Tenant signup + onboarding flow (currently a manual DB insert)
• Per-tenant billing via Razorpay Subscriptions
• Tenant-scoped config: commission rates, channels, packaging costs
• Admin console for cross-tenant support
• Rate limiting per tenant
• Audit log of tenant-boundary-crossing actions
• RLS penetration test — attempt cross-tenant reads with a forged JWT before any external tenant touches the system

Gate: do not sell to a second kitchen until your own has been profitable for three consecutive months. Selling operations software you haven't proven on yourself is how the SaaS thesis dies.

AI & Automation Plan

Governing rule: automate a process only after it works manually. Automating a broken process produces broken output faster.

The metric this document optimizes: founder manual ops hours/week. Week 4 baseline is ~25 hrs. Target is <6 hrs by Month 4.

1. Manual Work Audit

Everything you will personally do in Week 4, honestly estimated.

2. Agent Roster — Ranked by ROI

Priority is (hours saved + margin impact) ÷ build effort. Build strictly in this order.

Total addressable: ~23 hrs/week. Realistic capture after accounting for exception handling: 17–18 hrs/week.

3. Agent Specifications

A1 — Daily Ops Digest P0

Trigger:  cron 23:00 IST daily
Input:    orders, order_items, stock_movements for the day
Model:    none (pure SQL + template) — do not use an LLM for this
Output:   WhatsApp message to founder

🍽 {{BRAND}} — 31 Jul

Orders        42  (▲ 5 vs 7-day avg)
Revenue    ₹14,280
AOV           ₹340
Contribution ₹4,620  (32.4%)

By channel   Swiggy 18 · Zomato 15 · Direct 9  (21% direct)
Top SKU      {{DISH_1}} ×14
Slowest      {{DISH_5}} ×1  ← review
Wastage      ₹310  (2.2%)
Avg dispatch 17 min
Rating       4.4  (2 new reviews, both answered)

⚠ Chicken stock below reorder point — PO sent to Vendor A

Use no LLM here. It is a deterministic query and a template. An LLM would add cost, latency, and the possibility of hallucinated numbers in the one report you make decisions from.

A3 — WhatsApp Ordering Agent P0

The highest-margin automation you will build. Every order it handles earns ~₹166 contribution instead of ~₹94.

Trigger:  POST /api/webhooks/whatsapp
Model:    claude-haiku-4-5  (escalate to claude-sonnet-5 on complaint intent)
Tools:    get_menu, check_availability, create_order, create_payment_link,
          get_customer_history, escalate_to_human
Guardrails: never invents prices; never promises delivery times;
            never processes refunds; hands off on any complaint

Conversation contract:

Escalation triggers — hand to founder immediately, no LLM reply:

• Any complaint, illness mention, or refund request
• Order value > ₹2,000
• Third consecutive turn without resolution
• Any request for something not on the menu

Cost control: cache the menu and system prompt (they're identical every turn); route only escalations to Sonnet 5. Log usage.cache_read_input_tokens on every call — if it's zero, your prefix is changing and you're paying full price on every turn.

A2 — Review Response Agent P1

Trigger:  new review detected (poll every 30 min)
Model:    claude-haiku-4-5
Policy:   ≥4★ → generate and auto-send
          <4★ → generate draft, hold for founder approval, alert immediately

Never auto-send a reply to a negative review. A tone-deaf automated response to a genuine complaint is materially worse than a slow human one, and it is public.

Prompt constraints: ≤40 words, no emoji beyond one, never argue, never blame the rider or platform, always give a route to resolution.

A5 — Demand Forecast Agent P1

Trigger:  cron 21:00 daily
Model:    none initially (statistical) → claude-opus-5 for weekly review only
Output:   prep sheet on the kitchen tablet

Do not start with an LLM. Start with:

forecast(sku, date) =
    0.5 × avg(same weekday, last 4 weeks)
  + 0.3 × avg(last 7 days)
  + 0.2 × avg(last 3 days)
  × festival_multiplier
  × weather_multiplier

Ship this. Measure MAPE weekly. Only add ML once you have 90+ days of data and a measured baseline to beat. Target MAPE < 20% by Month 4.

The weekly Opus 5 run is different — it looks at forecast error patterns and explains why the model missed, which is genuinely a reasoning task.

A4 — Inventory & Reorder Agent P1

Trigger:  stock_movements write drops an item to ≤ reorder_point
Model:    none (rules) — LLM only for the vendor message wording
Action:   compose PO → WhatsApp to primary vendor → log expected delivery
Guardrail: hard cap ₹5,000 per auto-PO; above that, founder approves

The cap matters. An inventory bug that auto-orders ₹50,000 of tomatoes is a business-ending event at your cash position.

A7 — Win-back Agent P1

Trigger:  last_order_at = today − 21 days AND order_count ≥ 2
Model:    claude-haiku-4-5
Offer:    20% off next order, 7-day expiry, one per customer per quarter

Personalise on their actual order history — "your usual {{DISH}} is waiting" outperforms a generic discount by a wide margin. Measure recovery rate; if it's below 8%, the problem is the food or the delivery experience, not the message.

A11 — Executive Analyst P3

Trigger:  cron Sunday 20:00
Model:    claude-opus-5, adaptive thinking, effort "high"
Input:    full week of orders, reviews, inventory, marketing spend
Output:   written analysis + exactly 3 ranked recommendations

This is the one place a frontier model earns its cost — it runs 4× a month and its output changes your decisions.

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=8000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},
    system="You are the COO of a Hyderabad cloud kitchen. "
           "Be specific and quantitative. Recommend actions, not observations.",
    messages=[{"role": "user", "content": weekly_data_dump}],
)

Note: on Claude Opus 5, thinking is on by default and max_tokens caps thinking plus response text together — size it generously (8K here) or the analysis truncates mid-thought.

4. Trigger → Action Map

5. Guardrails — Apply to Every Agent

On that last row: give the agent tools that read live data rather than putting the menu in the prompt as ground truth for prices. A hallucinated ₹180 on a ₹280 dish is a real loss you must honour.

6. Expected ROI

Aggregate: ~20 days of build for ~17 hrs/week saved and ~₹36,000/month of margin and recovered revenue.

The margin uplift from A3 alone (moving orders from aggregator to direct) exceeds the entire monthly software budget by roughly 5×. If you build only one thing from this document, build A3.

Marketing Plan — First 90 Days

Budget: ₹40,000 in Month 1, then ₹25,000–30,000/month. That does not buy meaningful paid reach in Hyderabad. It buys aggregator visibility plus concentrated local presence. Plan accordingly.

The one rule: every rupee should either (a) get a first order, or (b) move an existing customer to a channel you own. Spend that does neither is vanity.

1. Pre-Launch (Weeks 3–5) — Spend: ₹8,000

The highest-ROI window, and the one most founders skip.

Item 1 is the single most valuable line in this plan. ₹90,000 of pre-launch cash converts your −₹1.56L cumulative trough into something survivable, and it proves demand before you have spent on equipment you can't return. Sell to friends, colleagues, your building, your gym — anyone who will believe you enough to prepay.

If you cannot sell 30 subscriptions to people who already know you, that is information about the offer, and it is worth having before you sign a lease.

2. Launch (Weeks 5–8) — Spend: ₹32,000

Apartment groups are your cheapest channel and they compound. One admin relationship gives you repeated free access to 200+ households. Treat those admins as partners: give them a permanent discount code, credit them publicly, and never spam the group.

Aggregator launch tactics:

• Take the new-partner promotional slab; it is time-limited, so use it hard in Weeks 5–8
• Photography matters more than description — budget a proper shoot, not phone snaps
• Respond to 100% of reviews within 12 hours (A2 automates this)
• Never let the menu go offline during peak hours; it hurts ranking for days

3. Growth (Weeks 9–13) — Spend: ₹25,000/month

Shift from acquisition to channel migration. You already have customers; the job is now to own them.

Corporate is the highest-value B2B channel available to you. One office with 30 daily lunch orders is worth more than 200 sporadic consumer orders: predictable volume, near-zero CAC after the first sale, batch delivery, no aggregator commission. Target IT parks and mid-size offices in Madhapur, Gachibowli, Kondapur, and HITEC City.

4. Content Engine

5 posts/week, all sourced from things that actually happen in the kitchen. No stock photos, no generic food quotes.

Positioning: build in public. You are a technical founder running an AI-native kitchen — that is a genuinely differentiated story in Hyderabad's food scene, and it costs nothing to tell. Post your dashboards. Post the automation. Post the failures. It attracts customers, future employees, and eventually SaaS customers, all from the same content.

A6 (Content Agent) drafts these from real order data each Monday. You shoot and post.

5. Retention — Where the Money Actually Is

Acquiring a customer costs ₹100–150. Retaining one costs ~₹5. The whole business turns on this ratio.

Targets: 30-day repeat rate ≥28% by Week 12. LTV:CAC ≥3:1 by Month 6.

If repeat rate is below 20% at Week 12, stop all paid acquisition. You are pouring money into a bucket with a hole in it. Fix the food, the packaging, or the delivery time first — those are the three causes, in that order of likelihood.

6. Subscription Product

Recurring revenue is the difference between a kitchen and a business.

Why subscriptions beat everything else:

• Cash upfront (working capital at your position, not a nice-to-have)
• Demand becomes predictable → wastage drops → margin rises
• Zero aggregator commission
• Retention is structural, not behavioural

Target: 150 active subscriptions by Month 9 ≈ ₹4.5L MRR.

7. KPI Dashboard — Reviewed Weekly

8. What Not To Do

Explicitly, because these are the standard ways ₹25,000/month evaporates:

• Don't run broad Meta awareness campaigns. Your budget can't buy frequency. Radius-targeted conversion campaigns only.
• Don't buy follower growth or engagement. It converts to zero orders.
• Don't discount below ₹70 contribution per order. Volume at negative margin kills you faster than no volume.
• Don't hire a marketing agency at this budget. The fee would be most of the budget.
• Don't launch a second brand before Month 6. It splits attention and doubles operational complexity for the same kitchen.
• Don't chase Instagram follower count as a goal. Track orders attributed to Instagram instead — it is a much smaller and much more honest number.

Landing Page Copy — Direct Ordering Site

Single job of this page: convert an aggregator customer into a direct customer. Everything below serves that.

Replace {{BRAND}}, {{CUISINE}}, {{DISH_N}}, and prices with your finalised menu. The structure and the argument do not change.

Hero

Real food. Cooked today. Delivered in 30 minutes.

{{CUISINE}} from a kitchen in {{AREA}}, Hyderabad — made fresh for every order, never reheated, never from a central batch.

Order direct and pay 15% less than you would on any delivery app.

[ Order on WhatsApp ] [ See the menu ]

⭐ 4.5 on Swiggy & Zomato · 🍽 12,000+ meals served · 📍 Delivering across {{AREA}}

Alternate headlines to A/B test:

• "Your daily meal, sorted."
• "Cooked at 11. Delivered by 12:30. Not a minute older."
• "The food you'd cook, if you had the time."

The Value Proposition Bar

Immediately under the hero — four tiles, no scrolling required.

Why Order Direct (the conversion section)

Same kitchen. Same food. Better price.

When you order through a delivery app, roughly a quarter of what you pay goes to the app — not to your food.

Order direct and that money comes back to you as a lower price, and to us as the margin that lets us keep buying good ingredients.

Ordering takes 30 seconds on WhatsApp. No app to install, no account to create.

[ Order on WhatsApp → ]

Menu Section

Today's menu

A short menu, cooked well, changed with the season. We'd rather do twelve dishes properly than sixty badly.

Per dish, show: photograph, name, one honest sentence, price, veg/non-veg marker, spice level, allergens, and a live availability badge.

Everything is cooked after you order. If something's sold out, it'll say so here — we won't take an order we can't cook.

Subscriptions

Stop deciding what to eat every day.

Pick a plan. We deliver. You get your evening back.

Change your delivery slot, skip a day, or pause the whole plan — on WhatsApp, no questions asked.

[ Start with a trial week ]

How It Works

Four steps. Thirty seconds.

1. Message us — Tap the WhatsApp button. Say hello. 2. Pick your food — We'll send today's menu. Reply with what you want. 3. Pay — Secure link. UPI, card, or wallet. 4. Eat — Cooked fresh, sealed, at your door in about 30 minutes.

Why Choose Us

What we actually do differently

We publish our recipes in grams. Every dish has a written spec — exact quantities, exact method. That's why your third order tastes like your first. Most kitchens can't say that.

We track our own kitchen the way a factory tracks a line. Temperature logs, batch samples kept for 48 hours, wastage measured daily. Not because a regulation demands it. Because it's how you make food consistently good.

We're small on purpose. One kitchen. A short menu. We'd rather be the best option in {{AREA}} than a mediocre one across Hyderabad.

You can talk to us. Not a support ticket. The same WhatsApp number that takes your order reaches the people who cooked it.

Social Proof

What people say

"[Testimonial — consistency]" — {{NAME}}, {{AREA}} · Ordered 14 times

"[Testimonial — a specific dish]" — {{NAME}}, {{AREA}} · Subscriber since {{MONTH}}

"[Testimonial — corporate/bulk]" — {{NAME}}, {{COMPANY}}

Collect these properly. After a customer's fifth order, ask on WhatsApp. Use real names, real areas, real order counts. Do not write them yourself — fabricated reviews are both dishonest and obvious.

Corporate

Feeding a team?

We handle daily lunch for offices across {{AREA}} — fixed menus, fixed slots, monthly invoicing with GST.

From 10 meals a day. Custom menus above 50.

[ Talk to us about corporate ]

FAQ

What areas do you deliver to? {{AREA}} and within 5 km. Enter your pincode above to check — takes a second.

How long does delivery take? Around 30 minutes. Our average across the last 1,000 orders is 27. Peak dinner hours can run longer, and we'll tell you upfront if so.

Is it really cheaper than the apps? Yes — about 15% on the same dishes, plus free delivery above ₹399. Delivery apps charge us a commission on every order; ordering direct removes it.

Can I customise a dish? Within reason, yes. Less spice, no onion, extra gravy — just say so. Your note goes to the cook, not into a form field.

What are your hygiene standards? FSSAI licensed (number on every package and at the bottom of this page). Daily temperature logs, monthly pest control, 48-hour reference samples of every batch. Ask us anything specific and we'll answer.

What if my order is wrong? Message us. Missing or wrong items are refunded immediately — no photos, no forms, no argument.

Do you have vegetarian options? Yes. Clearly marked on the menu, cooked with separate utensils.

Can I pause my subscription? Any time, on WhatsApp. Skip a day, pause a week, or stop entirely. Unused meals stay on your account.

How do I pay? UPI, cards, wallets, or net banking through a secure Razorpay link. No cash on delivery.

Final CTA

Hungry?

Your first direct order gets 20% off.

[ Order on WhatsApp ] [ Browse the menu ]

Delivering to {{AREA}} · Open 11:30 AM – 3 PM and 6:30 PM – 10:30 PM

Footer

{{BRAND}} {{ADDRESS}}, Hyderabad, Telangana {{PIN}} FSSAI Licence No. {{FSSAI_NUMBER}} · GSTIN {{GSTIN}} WhatsApp {{PHONE}} · {{EMAIL}}

Menu · Subscriptions · Corporate Orders · Track Order Terms · Privacy · Refund Policy · Delivery Areas

© 2026 {{LEGAL_ENTITY}}. All rights reserved.

SEO Metadata

<title>{{BRAND}} — Fresh {{CUISINE}} Delivery in {{AREA}}, Hyderabad</title>

<meta name="description" content="Order fresh {{CUISINE}} in {{AREA}}, Hyderabad.
Cooked to order, delivered in 30 minutes, 15% cheaper than delivery apps.
Daily meal subscriptions from ₹192. Order on WhatsApp.">

<link rel="canonical" href="https://{{DOMAIN}}/">

<meta property="og:title" content="{{BRAND}} — Fresh {{CUISINE}}, Delivered in 30 Minutes">
<meta property="og:description" content="Cooked to order in {{AREA}}, Hyderabad.
15% cheaper direct. Subscriptions from ₹192/meal.">
<meta property="og:image" content="https://{{DOMAIN}}/og-hero.jpg">
<meta property="og:type" content="website">
<meta name="twitter:card" content="summary_large_image">

Target keywords (organic, local intent): food delivery {{AREA}} Hyderabad · {{CUISINE}} delivery Hyderabad · tiffin service {{AREA}} · daily meal subscription Hyderabad · office lunch delivery {{AREA}} · home style food delivery Hyderabad · healthy meal plan Hyderabad

Structured data (helps Google surface you locally)

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "{{BRAND}}",
  "servesCuisine": "{{CUISINE}}",
  "priceRange": "₹₹",
  "telephone": "{{PHONE}}",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "{{ADDRESS}}",
    "addressLocality": "Hyderabad",
    "addressRegion": "Telangana",
    "postalCode": "{{PIN}}",
    "addressCountry": "IN"
  },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday","Saturday","Sunday"],
    "opens": "11:30",
    "closes": "22:30"
  }],
  "acceptsReservations": false,
  "hasMenu": "https://{{DOMAIN}}/menu"
}

Conversion Notes

• The WhatsApp CTA must be the primary button everywhere. It has the lowest friction of any ordering method in India — no install, no signup, no password.
• Show the price comparison table above the fold on mobile. It is the single strongest argument on the page and it's factually true.
• Never claim a delivery time you can't hit. "About 30 minutes" that lands at 28 beats "20 minutes" that lands at 35. The second one generates the review that costs you twenty orders.
• Don't fabricate testimonials, review counts, or "12,000+ meals served" before it's true. Ship the page with the real number, even if it's 400. Inflated social proof is both dishonest and, in a 5km radius where customers talk, easily caught.
• A/B test in this order: hero headline → CTA button text → price comparison placement. Test one at a time; your traffic volume won't support more.

Dashboard & KPI Plan

Design rule: one screen per role, answerable in 10 seconds. If a dashboard needs scrolling to answer its core question, it is two dashboards.

Build rule: build the Founder dashboard first (M1). The rest can wait until you have someone other than yourself to show them to.

1. Founder Dashboard — /dashboard · P0

The only one that exists before Month 3. Mobile-first, because you'll read it standing in the kitchen.

Question it answers: "Are we making money, and is anything on fire?"

Top row — four tiles

Second row

Third row

• Top 5 SKUs by contribution (bar)
• Bottom 5 SKUs by contribution — flagged for delisting
• Blended aggregator rating with trend
• Open complaints count

Alert strip — always visible

🔴 Contribution below 25% for 3 consecutive days
🔴 Rating dropped below 4.2
🟠 Chicken stock below reorder point
🟠 3 reviews unanswered > 12 hrs
🟢 Direct share crossed 20%

Colour discipline: red means act today. Orange means act this week. If everything is red, the alerts are miscalibrated and you'll start ignoring them.

2. Operations Dashboard — kitchen tablet · P1

Question: "What do we cook, and are we keeping up?"

Large fonts, high contrast, no login timeout. This runs on a tablet in a hot kitchen, operated by someone with wet hands.

3. Finance Dashboard · P1

Question: "Are we actually profitable, and where is the money going?"

Aggregator settlement reconciliation is the row that catches real money. Platforms make deduction errors. Nobody checks. Check monthly.

4. Marketing Dashboard · P2

Question: "Which spend is working?"

Cohort retention grid — the most useful chart in the whole plan:

If the M1 column is improving cohort over cohort, the product is getting better. If it's flat while you spend more on acquisition, you are buying churn.

5. Customer Support Dashboard · P2

Complaint categories are a product roadmap. If "missing item" leads three weeks running, the packaging SOP is broken — that's a fix, not a refund line.

6. Inventory Dashboard · P2

7. Growth Dashboard (Month 6+) · P3

Only meaningful once you're past breakeven.

8. Master KPI Table

Every number, its owner, and its review cadence.

Any red for three consecutive days triggers a written root-cause note. Not a mental note — a dated entry in /ops-reviews/ with an owner and a date. Red numbers that nobody wrote down are how businesses fail slowly.

9. Implementation Notes

Don't buy a BI tool. At your budget and data volume, the Founder dashboard is one Next.js page reading from Supabase, and the daily digest (A1) covers 80% of what you'd check anyway.

Precompute the metrics. Write a nightly job that populates a daily_metrics table rather than aggregating raw orders on every page load. It's faster, it's cheaper, and it means historical numbers stay stable even when you change how a metric is calculated.

create table daily_metrics (
  tenant_id           bigint not null,
  metric_date         date not null,
  orders              int,
  revenue             numeric(12,2),
  contribution        numeric(12,2),
  aov                 numeric(10,2),
  direct_share        numeric(5,4),
  food_cost_pct       numeric(5,4),
  wastage_pct         numeric(5,4),
  avg_dispatch_mins   numeric(6,2),
  rating              numeric(3,2),
  primary key (tenant_id, metric_date)
);

Every metric definition lives in one place (02-unit-economics.md §6) and is implemented once in code. The fastest way to lose trust in your own dashboard is to have two screens showing different numbers for "contribution."

Risk Register

Scoring: Likelihood (L) and Impact (I) each 1–5. Score = L × I. Anything ≥ 15 needs an active, funded mitigation — not an intention.

Review monthly. Add new risks as you find them; a register that never changes isn't being used.

Critical — Score ≥ 15

R1 · Cash runs out before breakeven — L5 × I5 = 25

Your ₹1.92L operating float against an ₹86,000 monthly fixed base gives ~2.2 months at zero revenue. The 12-month model's cumulative trough is −₹1.56L at end of Month 3, leaving ₹36,000 of headroom. There is no room for a bad month.

Mitigation

• Pre-sell 30 subscriptions before launch → ₹90,000 (Marketing §1, item 1)
• Negotiate the deposit to 2 months → frees ₹30,000
• Buy 60% of equipment refurbished → saves ~₹80,000 vs new
• Founder draws zero salary until Month 4
• Weekly cash review, every Monday, without exception
• Written kill/pivot decision at Week 10 if orders/day < 22

Owner: Founder · Trigger: runway < 2 months

R2 · Aggregator rating drops below 4.0 — L3 × I5 = 15

Below 4.0, platform visibility collapses and order volume can halve within a week. This is the fastest way the business dies from a cause other than cash.

Mitigation

• QA check on every single order before dispatch (SOP-03 step 6)
• Respond to 100% of reviews within 12 hours (Agent A2)
• Refund fast and without argument below ₹500
• Never let the menu go offline during peak hours
• Weekly review of every complaint's root cause, not just its resolution
• Daily rating monitoring with an alert at 4.2

Owner: Founder · Trigger: rating < 4.2 on either platform

R3 · Single-cook dependency — L4 × I4 = 16

One person quitting, falling ill, or being poached stops production entirely. At two kitchen staff, there is no redundancy.

Mitigation

• recipes.yaml — gram-level specs for every dish, written before launch (Ops §10)
• Helper cross-trained on the 5 highest-volume SKUs by Week 8
• Two relief cooks identified and contactable before you need them
• Pay at or slightly above market; retention is cheaper than rehiring
• Written notice period in the employment agreement

Owner: Founder · Trigger: any resignation, or 2+ sick days in a month

This is also the risk that determines whether the business is ever sellable or scalable. A recipe that exists only in one person's head is not an asset.

R4 · Aggregator platform dependency — L5 × I4 = 20

At launch, 100% of revenue flows through two companies that control your pricing, your visibility, your customer relationship, and your commission rate — and can change any of them unilaterally.

Mitigation

• Reorder card (QR → WhatsApp) in every box from order #1
• Direct channel live by Week 10 (M2/M3)
• Direct share targets: 20% by M3, 40% by M6, 55% by M12
• Subscriptions live by Week 14 — structurally aggregator-proof revenue
• Corporate accounts as a third, independent channel

Owner: Founder · Trigger: direct share < 10% at Week 12

R5 · Food safety incident — L2 × I5 = 15

Low likelihood, existential impact. One publicised illness case ends the brand, and potentially triggers regulatory action.

Mitigation

• Temperature logs twice daily, recorded not remembered
• 48-hour reference sample retained for every dish batch
• Monthly pest control with signed service records
• Sick-staff exclusion policy, written and enforced
• Water potability test quarterly
• Product liability insurance from Month 4 (R14)
• Escalation protocol: any illness allegation goes to the founder within the hour; retain the sample; do not admit liability; do not offer settlement

Owner: Founder + Cook · Trigger: any illness allegation, any temperature excursion

High — Score 9–14

R6 · Discount dependency destroys margin — L4 × I3 = 12

Platform-mandated discounts creep upward to maintain visibility; contribution silently erodes until you're buying volume at a loss.

Mitigation: hard floor — never fund a discount that drops contribution below ₹70/order. Track discount-funded % weekly. Compete on consistency and speed, not price.

R7 · Vendor supply failure — L3 × I4 = 12

Your only vegetable supplier doesn't show up on a Saturday.

Mitigation: minimum two vendors per category, always. Buy 10% from the backup monthly to keep the relationship live. Maintain 2 days of dry-goods cover.

R8 · Raw material price inflation — L4 × I3 = 12

Tomatoes, onions, and cooking oil all swing violently in India. A 30% ingredient spike wipes out contribution on affected dishes.

Mitigation: monthly SKU re-costing (A4 flags this automatically). Recipes designed so seasonal items can be substituted. Reprice or temporarily delist rather than absorb.

R9 · Delivery partner failure on direct orders — L3 × I3 = 9

3PL unavailable at peak, or repeatedly late, on the channel where you own the customer relationship and therefore the blame.

Mitigation: integrate two providers, not one, with automatic fallback. Track on-time % by provider. Set customer expectations conservatively.

R10 · Technology failure during service — L3 × I3 = 9

Vercel, Supabase, WhatsApp API, or your POS goes down at 8 PM on a Friday.

Mitigation: printed menu, phone, and paper order pad in a kitchen drawer. Health-check monitoring with WhatsApp alerts. Nightly pg_dump to storage you control, in addition to platform backups. The kitchen must be able to operate with zero software.

R11 · AI agent causes a real-world error — L3 × I3 = 9

The WhatsApp agent quotes a wrong price, confirms an unavailable item, or auto-orders ₹50,000 of stock.

Mitigation: prices, availability, and ETAs always read from the database via tools — never from the prompt as ground truth. Hard ₹5,000 cap on auto-purchase. No agent issues refunds or moves money. Every agent action logged. Weekly review of all escalations.

R12 · Compliance lapse — L2 × I5 = 10

An expired FSSAI licence gets you delisted from both aggregators within days.

Mitigation: A9 Compliance Calendar Agent with 45/30/7-day alerts. CA on retainer for GST at ₹2,000/month. Renew everything 45 days early.

Medium — Score 5–8

The Three Numbers That Predict Failure

Most cloud kitchens fail for one of three reasons. Each has a leading indicator you can watch:

If all three are green, you are probably fine. If any one is red for two consecutive weeks, stop building features and fix it.

Monthly Review Protocol

First Monday of each month, 30 minutes:

1. Re-score every risk — has likelihood or impact moved?
2. Check the mitigation checkboxes — which are actually done?
3. Add risks discovered during the month
4. Close risks that no longer apply (and say why)
5. Confirm every score ≥15 has a funded, in-progress mitigation

A risk register nobody updates is theatre. If you skip two consecutive reviews, delete this file — it's giving false comfort.

Growth Experiments Backlog

Method: one experiment at a time per area. Fixed duration. Written hypothesis and success criterion before you start. Kill or keep — no "let's run it a bit longer."

Scoring: Impact (1–5) ÷ Effort (1–5). Run high scores first. At 40 orders/day you do not have the volume for subtle A/B tests, so prefer experiments with large expected effects.

Tier 1 — Run in Weeks 5–12

E1 and E2 are the same bet from two sides, and it's the most important bet in the plan. A direct order is worth 1.76 aggregator orders. Everything else on this page is secondary.

Tier 2 — Run in Weeks 10–20

E13 deserves emphasis. Most cloud kitchens under-price out of fear. A ₹20 increase on your three best SKUs adds ₹20 of pure contribution per order — at 40 orders/day that's ₹18,000/month for zero additional cost. Test it before you spend anything more on acquisition.

Tier 3 — Month 4+

Experiment Template

Copy this into /experiments/EXX-name.md before starting. If you can't fill in every field, the experiment isn't ready.

# EXX — {{Name}}

**Owner:** Founder
**Start:** YYYY-MM-DD   **End:** YYYY-MM-DD   **Duration:** N days

## Hypothesis
If we {{change}}, then {{metric}} will {{direction}} by {{amount}},
because {{mechanism}}.

## Baseline
{{metric}} = {{value}}, measured over {{period}}

## Success criterion
{{metric}} ≥ {{threshold}}  ← decided BEFORE starting, not after

## Guardrail metrics
These must not degrade: {{list}}

## Cost
₹{{amount}} + {{hours}} hrs

## Result
Measured: {{value}}
Verdict: KEEP / KILL / ITERATE
Learning: {{what this tells us about the business, not just the metric}}

Rules

1. Write the success criterion before you start. Deciding what counts as success after seeing the data is not an experiment, it's a rationalisation.
2. One experiment per area at a time. Two pricing changes at once teaches you nothing about either.
3. Run the full duration. Killing on day 3 because it looks bad is how you discard things that work.
4. Define guardrails. A change that lifts AOV but tanks your rating is a loss.
5. Write down kills too. A documented failure is worth as much as a win and costs you nothing extra.
6. Don't test what you can reason out. Whether a ₹180 dish is profitable on a 22% commission is arithmetic, not an experiment.

Ideas Parking Lot

Not scheduled, not scored — revisit quarterly.

• Late-night menu (10 PM – 1 AM) for the IT crowd
• Weekend-only premium menu at higher price points
• Meal kits (semi-prepared, cook at home)
• Corporate event and party catering
• Cook's-table content series → build a personal brand around the kitchen
• Open-sourcing the kitchen software as a lead generator for the SaaS
• Franchise/licence model once SOPs are fully documented
• Selling the forecasting model as a standalone product to other kitchens

On the last two: they're the real end state of this business, and both depend entirely on documentation quality. Every SOP you write properly now is an asset you sell later. That is the actual reason the Operations Manual is gram-level rather than approximate.