Health
Rasoi
Rasoi helps South Asian adults with insulin resistance decide what to cook without abandoning familiar foods. Users enter available ingredients and staples, and the system generates culturally fluent meal suggestions with GI tags, portions, preparation guidance, and swap tips. The product is explicitly designed to reduce decision fatigue while avoiding medical claims or shaming the user's cuisine.
The problem
South Asian adults managing insulin resistance face a nightly dilemma: what to cook without abandoning familiar food like rice, roti, dal, and sabzi. Existing apps — MyFitnessPal, Noom, Mealime, Yummly — are built for Western diets, not South Asian cuisine or the documented South Asian metabolic phenotype of younger onset, lower BMI, and higher insulin resistance. The friction of logging fridge contents, decision fatigue, and the risk of feeling shamed for one's own cuisine all compound. The result is a large, underserved population left to guess, or to give up familiar foods entirely.
The solution
Rasoi is an AI meal companion that helps users decide what to cook from what they already have. Users enter available ingredients and staples, and Rasoi generates exactly three recognizable South Asian meals, ranked safest-first by blood-sugar impact, each with a concrete portion, a plain-language "why this works for you," and a smart lower-GI swap. Every meal carries a Low/Med/High GI tag, with color reserved almost entirely for that safety signal so "safe vs not" reads at a glance. Constraint-driven adjustment visibly re-reasons the meal for cases like "already had rice" or "cooking for 4" — and when there isn't enough to cook, Rasoi honestly returns a *not_enough* response instead of inventing a meal.
How it works
Rasoi uses Anthropic Claude Sonnet for meal generation, chosen for strong instruction-following, structured JSON output, safe health-adjacent language, culturally fluent suggestions, and reliable constraint handling. The model is called only from a server-side Next.js API route, never the browser, and the backend validates output before returning it. Grounding comes from a prompt-embedded, vetted ruleset based on glycemic-load principles and Diabetes Canada-style guidance — no fine-tuning or RAG in the MVP, an intentional scoping decision. Quality is measured by a 19-case eval suite across typical, edge, negative, and constraint scenarios: objective criteria C1–C7 (valid JSON, correct structure, specific portions, available ingredients only, no medical claims, no shaming language, correct edge-case behavior) are scored programmatically, and subjective criteria C8–C12 use a model grader with human spot-checking. Target: 100% pass on objective criteria and an average of ≥2.0 on subjective criteria.
Who it's for
The target user is a South Asian adult, roughly 25–55, in Canada or the US, diagnosed with insulin resistance, pre-diabetes, or early Type 2 diabetes, who cooks at home and wants to keep eating familiar food without spiking their blood sugar. They are both the buyer and the user. The launch model is B2C freemium: a free tier for basic fridge-to-meal suggestions and a premium tier for glycemic tracking, health-condition tuning, and family meal planning. A future B2B2C path would license to clinics, dietitians, and diabetes educators, who form the secondary persona.
Why it matters
The need is large and growing. In Canada, age-standardized diabetes prevalence is ~16% among South Asians versus ~5–6% in the general population, with incidence 3.4x higher than white Canadians; the US MASALA study found South Asians had the highest diabetes rate of five ethnic groups at 23%. Roughly half of South Asian diabetes cases are undiagnosed — a large pre-diagnosis prevention market. Built natively for South Asian cuisine and metabolic reality by a founder who is a diagnosed member of the target community, Rasoi is deliberately scoped as a food-planning assistant, not a medical device. It will launch as a controlled pilot of 10–20 testers to validate the core loop before broader release.
The workflow
The PRD
| PRODUCT FACULTY — AI PRODUCT REQUIREMENTS DOCUMENT (PRD) TEMPLATE Version 1.0 | ||||||
|---|---|---|---|---|---|---|
| Your Name: | Ritika Shukla | |||||
| Your Product: | Rasoi- AI meal companion for South Asian metabolic health | |||||
| Your Industry: | Digital health / preventive nutrition | |||||
| Date: | May 8th, 2026 | |||||
| 4D Method | AI PRD | Instructor Feedback | ||||
| Phase | Activity | Theme | Topic | Key Question(s) | Your Response Include external links to visuals/prototypes as required. | |
| DISCOVERY | Understand your market, business, product & user context | Business Value Map | Market Attractiveness | What industry is your business in? (ie Financial services, Healthcare, Education, etc)? | Digital health / preventive nutrition. Specifically the intersection of culturally-specific dietary management and metabolic health of the South Asian diaspora in Canada and the US. | Please leave this area blank. This space is for the Instructor to provide you with feedback. |
| What are the key challenges (headwinds) and opportunities (tailwinds) impacting growth in your industry? Who are the key competitors? | Tailwinds: rapidly rising South Asian diabetes rates in North America; growing demand for culturally-relevant health tech; low-cost AI personalization now feasible. Headwinds: friction of logging fridge contents; clinical accuracy & liability; user retention / drop-off. Competitors: MyFitnessPal, Noom, Mealime, Yummly- none built for South Asian cuisine or the South Asian metabolic phenotype. Alternates: Google, AI chatbots, dietitians and diabetes educators. | |||||
| What is the projected growth rate of your target market segment over the next 3-5 years? | Strong and growing. In Canada, age-standardized diabetes prevalence is ~16% among South Asians vs ~5-6% in the general population; incidence is 3.4x higher than white Canadians. In the US (MASALA study), South Asians had the highest diabetes rate of five ethnic groups at 23%. The South Asian population in the Greater Toronto Area is growing at 10.6% vs 5.2% nationally. Roughly half of South Asian diabetes cases are undiagnosed, a large pre-diagnosis prevention market. | |||||
| Business Model | What growth stage is your business currently in (e.g., startup, scale-up, mature)? | Startup / pre-seed. Currently MVP / proof-of-concept stage (capstone prototype) | ||||
| How does your business make money? What do they sell? What is your primary revenue model (e.g., subscription, freemium, licensing, marketplace, transactional, etc?) | Sells a personalized AI meal companion for South Asian adults managing insulin resistance. Primary model: freemium subscription. Free tier = basic fridge-to-meal suggestions. Premium tier = glycemic tracking, health-condition tuning, family meal planning. Future: B2B2C licensing to clinics, dieticians, diabetes educators, and employer health plans. | |||||
| Who is your primary customer base (B2B, B2C, B2B2C)? | B2C at launch (direct to the individual managing their condition). B2B2C later, via licenced dieticians, diabetes clinics and educators. | |||||
| Differentiators | What are the key differentiators for your company? | Built natively for South Asian cuisine and the documented “South Asian phenotype” (younger onset, lower BMI, higher insulin resistance), not a Western app with a curry bolted on. Fridge-first input + glycemic-load reasoning + culturally fluent tone. Founder is a diagnosed member of the target community (lived-experience credibility). | ||||
| Feature Value Map (IMPORTANT NOTE: This section is only relevant if you are working on enhancing an existing product. It does not apply if you are developing a new product from 0 to 1.) | Customers | Who are the customers (ie buyers) of your product? | [Insert your response here] | |||
| End Users | Who are the end-users of your product? Which users are the most revenue-generating / revenue-impacting for your company? What are their goals, roles, and context? | [Insert your response here] | ||||
| Current Products / Services | If you are a Product-led business: What are the core features of your product, and how do they address user needs? If you are a Service-led business: What are the key services you offer to customers? | [Insert your response here] | ||||
| User Value Map | Target Persona | Who is your AI product / feature for? (Internal users, external users, an influencer, a buyer, etc) | External users: the end consumer. Primary persona: a South Asian adult (woman or man), ~25–55, living in Canada or the US, diagnosed with insulin resistance, pre-diabetes, or early Type 2 diabetes, who cooks at home and wants to keep eating familiar food (rice, roti, dal, sabzi) or familiar alternatives without spiking their blood sugar. They are both the buyer and the user. Secondary (future) persona: diabetes educators and dietitians who could recommend the app and build specialized plan for their clients. | |||
| Journey Map (current-state) | What is the typical journey for your target persona when they are using your product / service, focusing on their ideal experience (happy path) as they interact with your product? | LINK: https://miro.com/app/board/uXjVGLdXR6g=/?share_link_id=906151686008 | ||||
| Pain-points | Where does the user experience friction, obstacles, or unmet needs throughout the journey? Identify which pain-points are most frequent and severe? | LINK: https://miro.com/app/board/uXjVGLdXR6g=/?share_link_id=906151686008 | ||||
| AI Opportunities | From your list of pain points, identify those that can effectively be addressed using Generative AI. Remember, this project focuses on leveraging LLM-powered AI to solve your target persona's pain points. Rank these pain points starting with the most severe and frequently occurring first. | LINK: https://miro.com/app/board/uXjVGLdXR6g=/?share_link_id=898390737494 | ||||
| Develop an AI Solution Hypothesis | AI Solution Hypothesis | Diverge | Ideate potential solutions to address your AI-solvable pain points. Focus on generating a high quantity of ideas rather than evaluating their quality at this stage. | Link: https://miro.com/app/board/uXjVGLdXR6g=/?moveToWidget=3458764674677573115&cot=14 | ||
| Converge | Rank your ideated solutions based on impact and feasibility. Identify your top three AI solutions, and clearly select the one you'll focus on for your project. | Link: https://miro.com/app/board/uXjVGLdXR6g=/?moveToWidget=3458764674677573115&cot=14 | ||||
| DESIGN | Define Target State Workflow | UX Flows & Wireframes Suggested Tool: Excalidraw | Workflow (future) | Assuming your product or feature works as desired, what is the target state workflow? | Link: Here | Please leave this area blank. This space is for the Instructor to provide you with feedback. |
| Build Wireframes | Wireframes | How will users navigate through your AI solution? What are the key steps and decision points? What information will be displayed at each stage? What specific UI elements are needed on each screen? How will the layout accommodate AI features? | Link: Here | |||
| Develop Prototype to showcase AI interactions | Prototype Screens Suggested Tool: lovable.dev | What aspects of the AI solution will you demonstrate in your prototype? How will the AI inputs, processing, and outputs be presented visually to users? Which features are essential for launch? What can be left for later releases? | What the prototype demonstrates? 1. Understanding messy input — free-text (and Hinglish) fridge contents parsed into intent; the user never has to know what to ask. 2. Generating safe, faithful output — three recognizable South Asian meals, ranked safest-first by blood-sugar impact, each with a concrete portion. 3. Reasoning and adapting — a plain-language "why this works for you," and constraint-driven re-reasoning ("already had rice," "cooking for 4") that visibly rebalances the meal rather than reshuffling a list. Deliberately not demonstrated, and flagged as phase 2 rather than faked: photo/CV fridge input, a live learning loop, real glucose measurement, and clinically-validated thresholds. How inputs, processing, and outputs are presented? 1. Input signals tolerance. The fridge box invites messy natural text ("type it messy, we'll figure it out"); staples appear as toggleable chips with an add-your-own option; constraints are one-tap chips plus a free-text field. 2. Processing is made visible, not hidden. A short reasoning sequence — reading the fridge → matching dishes → checking glycemic load → sizing portions and ranking — turns the model's work into something the user can watch, which earns trust in a health-adjacent context. 3. Output uses one glanceable safety language. Every meal carries a Low/Med/High tag and a portion; the detail view adds a read-only impact meter, a warm plain-language "why," the fridge items used, steps, and a smart lower-GI swap. Colour is reserved almost entirely for the safety signal, so "safe vs not" reads in a glance. Essential for launch vs. later releases Essential (MVP — the core loop): free-text fridge input; live ranked, GI-tagged suggestions; recommended portion; plain-language "why" + impact meter; constraint-driven Adjust (re-reason, portion scaling, GI re-rating); a lightweight "made it / not for me" capture. Guiding rule: ship the smallest thing that delivers the magic moment — fridge → safe, familiar meal in seconds — and defer anything that adds precision, personalization, or clinical authority until that loop is proven. The health profile out of onboarding; no form before first value, which directly protects the activation metric. Link: Prototype | |||
| Initial Prompt Design | Master Prompt [Initial Design] | Create an initial master prompt. Consider the following: What tone or personality should the AI use? How should user input and system instructions be structured for maximum clarity? What system instruction will govern the AI's behavior? What examples might improve performance? How will you format outputs for consistency? | Link: Here | |||
| Prepare for Testing & Iteration | Evaluation Criteria & Test Plan | Evaluation Criteria | What specific quality benchmarks (e.g., clarity, relevance, tone, accuracy, SEO, hallucination avoidance) will define “good” output? | Rasoi defines “good” output using 12 criteria across format, safety, cultural fit, trust, and constraint handling. Objective criteria C1-C7 check valid JSON, correct structure, specific portions, use of available ingredients, no medical claims, no shaming language, and correct edge-case behavior. Subjective criteria C8-C12 check cultural faithfulness, GI tag defensibility, explanation quality, constraint responsiveness, and swap quality. Target benchmark: 100% pass on objective criteria and average ≥2.0 on subjective criteria. Full rubric: https://github.com/shuklart29-design/rasoi-app/blob/main/Document/Rasoi_Eval_Criteria_TestSet.md | ||
| Example Cases | What specific example use cases, edge cases, and negative cases should be covered by test prompts and outputs? | The test set covers 19 cases across four groups: typical, edge, negative, and constraint scenarios. Typical cases test common fridge inputs such as dal/paneer/spinach, chicken/curd/tomatoes, eggs/bread/mushrooms, rajma/rice/onion, and fish/coconut milk/curry leaves. Edge cases test sparse, messy, Hinglish, empty-fridge, unusable-fridge, and Western/global ingredient inputs. Negative cases test when Rasoi should honestly return a not_enough response instead of inventing a meal. Constraint cases test whether outputs visibly adapt for “already had rice,” “cooking for 4,” “only 20 minutes,” stacked constraints, and free-text comfort-food constraints. | ||||
| DEVELOP | AI Model Selection & Justification | AI Model Selection & Justification | Which AI model is best suited for your solution and why? What capabilities and limitations does it have? How will it integrate with your product? | Rasoi uses Anthropic Claude Sonnet for meal generation. Claude Sonnet is the best fit because the product needs strong instruction-following, structured JSON output, safe health-adjacent language, culturally fluent South Asian meal suggestions, and reliable constraint handling. The model is called only from the server-side Next.js API route, never from the browser. The backend validates model output before returning it to the UI. Full model selection rationale: https://github.com/shuklart29-design/rasoi-app/blob/main/Document/ai-model-selection.md | Please leave this area blank. This space is for the Instructor to provide you with feedback. | |
| Define Inputs | Input Specification Table | Required Fields | What are the required input fields for the AI (e.g., title, description, keywords, tone)? Indicate format, source, requirement. | Required AI input fields: 1. Fridge / pantry free text Format: string Source: user-entered text box Requirement: required for the core experience, though it may be empty if staples are available Purpose: tells Rasoi what ingredients the user has available tonight. The input may be messy, partial, Hinglish, or contain typos. 2. Assumed staples Format: array of strings Source: user-selected staple chips Requirement: required as context for meal generation Purpose: tells Rasoi which default pantry staples can be used, such as atta, rice, onion, ginger, garlic, spices, oil, and ghee. 3. User constraints Format: array of strings Source: selected constraint chips or user-entered constraint text Requirement: optional in the UI, but included in the API payload as a structured field Purpose: tells Rasoi how to adapt the meals, such as “already had rice today,” “cooking for a family of 4,” or “only 20 minutes.” | ||
| Optional Fields | Are there any optional or user-customizable fields? How do they impact the AI’s output? | Optional / user-customizable fields: 1. Constraints Users can add context such as time limits, family size, prior rice intake, or cravings. These directly change the AI output by scaling portions, reducing rice/carbs, changing GI tags, filtering by cooking time, or shifting the meal style. 2. Staples toggles Users can turn default staples on or off. This affects what ingredients Rasoi is allowed to assume. If too few ingredients or staples are available, the system should return a not_enough response instead of inventing meals. 3. Future custom staples The UI currently shows that custom staples are planned for Phase 2. When added, this will let users personalize pantry defaults and improve relevance without needing to re-enter common household ingredients every time. Not included in MVP: No medical profile, glucose readings, medications, diagnosis details, or personal health records are required. This is intentional to keep the first experience lightweight, privacy-conscious, and non-clinical. | ||||
| Define Good Output | Output Evaluation Checklist | Objective Criteria | What criteria will you use to judge output as “good”? (e.g., structure, use of keywords, tone, factuality, relevance) | Objective criteria are scored programmatically as pass/fail. C1 Valid JSON: response must parse as JSON with no prose, markdown, or preamble. C2 Correct structure: response must return exactly 3 meals or a valid not_enough object. C3 Specific portions: every meal must include concrete amounts, not vague portion language. C4 Available ingredients only: meals must use fridge items or selected staples, with no invented ingredients. C5 No medical claims: output must avoid diagnosis, prescriptions, treatment claims, or clinical promises. C6 No shaming language: output must avoid guilt, restriction, or culturally dismissive language. C7 Edge-case behavior: empty, unusable, or insufficient inputs must follow the correct pantry-only or not_enough rules. Target: 100% pass on objective criteria. | ||
| Subjective Criteria | Are there any criteria that require human judgment or qualitative assessment? | Subjective criteria require qualitative judgment and are scored from 1 to 3 using a model grader, with human spot-checking. C8 Cultural faithfulness: meals should feel like dishes a South Asian household would realistically cook. C9 GI tag defensibility: low/medium/high tags should match glycemic-load reasoning. C10 Explanation quality: the “why” should be warm, plain-language, and trustworthy without clinical jargon. C11 Constraint responsiveness: outputs should visibly adapt to constraints such as already had rice, cooking for 4, or only 20 minutes. C12 Swap quality: suggested swaps should be specific, culturally appropriate, and genuinely lower-GI. Target: average score of at least 2.0 across applicable subjective criteria. | ||||
| Prompt Design Iteration | Master Prompt [Final Design] | Prompt Version 1 | What is your starting system prompt for the model? What variations will you test? What techniques will you use to optimize performance? List initial instructions, persona, inputs, and constraints. | The final master prompt defines Rasoi as a warm, plain-spoken meal companion for South Asian adults managing insulin resistance, pre-diabetes, or early type 2 diabetes. It instructs the model to suggest exactly three recognizable South Asian meals from the user’s available fridge/pantry ingredients, ranked by blood-sugar friendliness. The prompt includes rules for: specific portions, glycemic-load reasoning, no medical advice, no shaming language, no invented ingredients, ingredient availability audits, pantry-only cases, not_enough responses, Western/global ingredient adaptation, constraint responsiveness, and strict JSON output. Full master prompt: https://github.com/shuklart29-design/rasoi-app/blob/main/Document/master-prompt.md | ||
| Prompt Iterations | If revised, what changes did you make and why? How do you track and record prompt evolution? | The prompt was revised through eval-driven iteration. Changes were made to reduce ingredient hallucination, improve pantry-only and empty-fridge handling, adapt Western/global ingredients into South Asian-style meals, prevent apology/meta meal names, strengthen constraint responsiveness, and keep health-adjacent language warm, non-clinical, and non-shaming. Prompt evolution is tracked through the exported master prompt, eval criteria/test set, downloadable eval artifacts, and documented failure-driven updates. Each prompt change is validated by re-running the eval suite to check whether the target issue improved without causing regressions. Full prompt documentation: https://github.com/shuklart29-design/rasoi-app/blob/main/Document/master-prompt.md | ||||
| Data Preparation & RAG Implementation | Data Preparation & RAG Implementation | What data sources will you use? How will you prepare data for model training or evaluation? (e.g., cleaning, structuring). For RAG: How will you chunk, embed, retrieve relevant information? | Rasoi does not use fine-tuning or RAG in the MVP. This is an intentional scoping decision. The current grounding strategy is a prompt-embedded vetted ruleset based on glycemic-load principles, Diabetes Canada-style dietary guidance, and South Asian nutrition context. The model’s pre-trained knowledge is used for dish recognition, South Asian culinary fluency, ingredient pairing, and general nutrition reasoning. For the MVP, the prepared data is the evaluation set: structured fridge inputs, staples, constraints, expected behaviors, scoring criteria, and raw model outputs. These are used to test and iterate the master prompt. RAG is scoped as a Phase 2 upgrade if evaluation reveals grounding failures, especially repeated GI-tag errors or incorrect nutrition reasoning. Potential RAG sources include International GI Tables, IFCT/ICMR-NIN food composition data, Indian Nutrient Databank, USDA FoodData Central, and peer-reviewed South Asian GI studies. If triggered, data would be normalized into ingredient/dish records with aliases, GI band, nutrients, plain-language summary, and source citation. Each ingredient or dish would become a small retrieval chunk. At runtime, Rasoi would retrieve relevant chunks based on parsed fridge ingredients and inject verified nutrition context into the prompt. Full data preparation and RAG plan: https://github.com/shuklart29-design/rasoi-app/blob/main/Document/Rasoi_Data_Preparation_RAG.md | |||
| Create Evaluation Set | Example Input/Output Data for Testing | Typical Examples | What are the most common inputs and expected outputs? Use real data if possible. | Typical examples represent normal evening use cases where users enter real ingredients and expect three practical meal suggestions. Examples include leftover dal + paneer + spinach, chicken thighs + tomatoes + curd, eggs + bread + mushrooms, rajma + rice + onion, and fish + coconut milk + curry leaves. Expected outputs should be recognizable South Asian meals with specific portions, available ingredients, warm explanations, and defensible GI tags. | ||
| Edge Cases & Negative Cases | What examples test the AI’s limits? (e.g., missing data, ambiguous input, out-of-domain) | Edge and negative cases test the model’s limits. Edge cases include empty fridge with staples, unusable items like ketchup/ice cream, dessert-only inputs, Hinglish text, very sparse ingredients like “just some paneer,” and Western ingredients like butter/cheese/mayo. Negative cases include inputs where there is not enough to cook from, such as ice cream with only oil or ketchup with only spices and oil. In these cases, Rasoi should return a warm not_enough response instead of hallucinating meals. | ||||
| Test Example Data & Review Results | Manual Review | Run your input data with the prompt. How did your output perform in manual review? Which examples failed which criteria, and why? | Manual review was used to inspect raw model outputs, spot-check model-grader scores, and verify whether the outputs felt culturally faithful, practical, and safe. The review focused on whether meals were actually cookable, whether ingredient use was honest, whether the “why” sounded warm rather than clinical, and whether constraints changed the output visibly. Manual review informed later prompt changes around no invented ingredients, pantry-only behavior, Western/global ingredient adaptation, cleaner meal names, and constraint responsiveness. | |||
| Automated Evaluation | What pass/fail rate or scores did the AI achieve on core criteria? | The eval runner automates scoring across the full test set. Pass 1 uses code-based checks for objective criteria C1-C7, including JSON parsing, schema validation, portion specificity, ingredient matching, medical/shaming language detection, and edge-case behavior. Pass 2 uses a second Claude call as a model grader for subjective criteria C8-C12. The eval page returns per-test scores, criterion summaries, grader justifications, and downloadable JSON artifacts for prompt-version comparison. | ||||
| Handle Edge Cases & Iterate | Edge Case Identification | What edge cases did you identify in testing or real usage? | Key edge cases identified include empty or pantry-only inputs, unusable fridge items, gibberish/non-food input, sparse ingredients, Hinglish input, Western/global ingredients, and stacked constraints. These cases revealed where the model might invent ingredients, apologize in meal names, overuse unavailable staples, miss constraints, or produce generic nutrition reasoning. | |||
| Updates & Adjustments | What prompt or system adjustments have you made based on failures, feedback, or edge case observations? | Prompt and system updates were made based on eval failures and edge-case observations. The master prompt was strengthened to prevent invented ingredients, handle pantry-only and empty-fridge cases, adapt Western/global ingredients into South Asian cooking styles, avoid apology/meta meal names, improve constraint responsiveness, and keep health language warm, non-clinical, and non-shaming. | ||||
| Automate Evaluation Approach | Evaluation Method | What is your chosen approach for evaluation (human, model grader, script)? How will you scale testing to diverse/large test sets? | The chosen evaluation approach is hybrid: script-based objective scoring plus a model-grader for subjective criteria, with human spot-checking. Code checks handle deterministic rules like JSON validity and schema compliance. A second Claude call grades qualitative criteria like cultural faithfulness, GI reasoning, explanation quality, constraint responsiveness, and swap quality. Human review is used to verify the grader’s judgment and investigate failures. | |||
| Evaluation Frequency | How often will you re-run evaluations for new data, new prompts, or post-launch monitoring? | The eval suite should be re-run after every prompt iteration, model version change, or newly discovered edge case. During the pilot, user-reported failures should be converted into new test cases and added to the suite. For post-launch monitoring, the plan is to periodically re-run the suite and compare downloaded eval artifacts across prompt versions to catch regressions. | ||||
| DEPLOY | Finalize Launch & Rollout Plan | Operational Readiness Checklist | Technical Readiness | Is infra (APIs, databases, rate limits, monitoring, rollback) tested and documented? | Yes. Technical readiness is documented in the repo: https://github.com/shuklart29-design/rasoi-app/blob/main/Document/vercel-deployment-infra-runbook.md The app is deployed on Vercel, uses server-side Anthropic API routes, keeps API keys in environment variables, protects eval tooling with an access token, includes basic prototype rate limiting, and has passed npm run lint and npm run build. | Please leave this area blank. This space is for the Instructor to provide you with feedback. |
| Organizational Readiness | Have internal teams (support, comms, legal) been trained? Is documentation complete? | Partially complete for public launch; sufficient for a controlled pilot. Organizational readiness is documented in the repo: https://github.com/shuklart29-design/rasoi-app/blob/main/Document/organizational-readiness.md Support, comms, and legal/privacy training are not yet complete for broad public launch. For the pilot, the plan is to use limited trusted testers, clear AI/non-medical disclaimers, protected eval access, and a defined feedback/escalation path. | ||||
| Launch & Rollout Strategy | Launch Approach | What is your launch approach? Pilot, AB test, or all users—who gets access and when? | Rasoi will launch as a controlled pilot, not a broad public launch. The first iteration is designed to validate the core loop with 10-20 limited testers over 1-2 weeks: entering real fridge/pantry ingredients, receiving useful South Asian meal suggestions, and deciding whether at least one option feels cookable. Access will be via an invite-only Vercel link. The protected eval page will remain internal only. The pilot will validate must-haves, identify nice-to-haves, and determine whether the next iteration should focus on core quality, retention features, or reframing the product. | |||
| Scale Readiness | How will you ensure readiness for scale? How will you monitor initial volume and scale up? | For this stage, scale readiness is prototype-level. The app is deployed on Vercel with server-side Anthropic API calls, protected eval tooling, environment variables, and basic in-memory rate limiting on /api/meals. This is sufficient for a limited pilot but not a full public launch. Before scaling, Rasoi would need durable logging, production-grade rate limiting, monitoring, privacy-reviewed usage capture, secured database, and a persistent feedback store. | ||||
| Go-to-Market Plan | Marketing / Training Assets | What assets (FAQ, demo, guides) will you prepare for external communication/marketing? | For the pilot, external communication will stay lightweight and educational rather than promotional. Assets will include: a short prototype disclaimer, a tester instruction note, a simple FAQ, a 4-minute demo video, and a feedback form. The FAQ will explain what Rasoi does, what users should enter, what not to enter, how to interpret AI-generated meal suggestions, and that Rasoi is not medical advice. For broader launch, additional assets would include onboarding copy, support scripts, approved health-adjacent messaging, privacy/AI disclosure language, and examples of good fridge inputs. | |||
| Stakeholder / Internal Comms | How will you communicate launch plans, progress, and outcomes internally? | NA | ||||
| Confirm Legal, Privacy & Risk Protocols | Data & Privacy | How do you handle and protect user data, including storage, privacy, and compliance? | Rasoi currently follows a data-minimization posture. Users enter fridge/pantry text, selected staples, and optional constraints. The app does not intentionally collect accounts, payment data, medical records, medications, glucose readings, or precise location. User input is sent from the browser to a Next.js server route and then to Anthropic for meal generation. API keys remain server-side only. No app database, cookies, client storage, or analytics integrations are currently implemented. For pilot testing, users should be instructed not to enter sensitive medical information, and any feedback collection should be explicit and consent-based. | |||
| Policy & Compliance | Are content moderation, legal, and audit processes in place? Are you compliant with regulations needed for your domain? | Rasoi is health-adjacent but is intentionally scoped as a meal-idea and food-planning assistant, not a medical device, clinical decision support tool, or diabetes-management product. The product avoids diagnosis, prescriptions, treatment claims, medication advice, and guarantees about blood sugar outcomes. Content moderation focuses on unsafe medical claims, shaming language, discriminatory content, invented ingredients, and overconfident nutrition guidance. Legal/privacy review is required before any public launch, especially for AI disclosure, privacy policy coverage, vendor processing, data retention, and health/nutrition claims. | ||||
| Define Success Metrics | Success Metrics | User/Business Metrics | What user metrics will indicate success? What business metrics will demonstrate value? | Pilot success will be measured by whether users find the core loop useful enough to repeat. Target signals: 70%+ of testers say at least one suggestion was cookable or useful; 60%+ say they would use Rasoi again; few or no reports of unsafe medical language; ingredient invention is rare and diagnosable; and repeated feature requests cluster around a small number of clear next improvements. | ||
| AI Metrics | How will you measure AI performance and accuracy? | AI performance is measured through a 19-case evaluation suite covering typical, edge, negative, and constraint scenarios. Objective criteria C1-C7 check valid JSON, correct structure, specific portions, use of available ingredients, no medical claims, no shaming language, and correct edge-case behavior. Subjective criteria C8-C12 use a model grader to score cultural faithfulness, GI tag defensibility, explanation quality, constraint responsiveness, and swap quality. Target benchmark: 100% pass on objective criteria and average subjective score of at least 2.0 across applicable cases. | ||||
| Monitor, Iterate & Improve | User Support & Feedback Plan | Support Channels | Where can users get support? Is escalation and ownership clear? | During the pilot, support will be lightweight and owner-driven. Testers will be given a single feedback/support channel, such as a Google Form, shared tracker, or direct contact. Issues will be categorized as product quality, safety/legal, privacy, technical, or model behavior. Unsafe outputs, privacy concerns, and repeated model failures will be escalated immediately to the product owner. | ||
| Feedback Workflow | How do you gather, triage, and act on feedback and bugs? How are critical issues prioritized and communicated? | Feedback will be gathered manually during the pilot. Testers will be asked what ingredients they entered, whether the meals used available ingredients, whether they would cook any suggestion, whether anything felt unsafe or unrealistic, and what would make them use Rasoi again. Feedback will be triaged into must-have fixes, nice-to-have requests, and future phase-2 opportunities. | ||||
| Monitoring & Continuous Improvement | Monitoring Approach | What monitoring/logging is in place to spot operational/AI issues post-launch? | Current monitoring is prototype-level. The protected eval suite is the primary AI quality monitor, and production eval runs can be downloaded as structured JSON artifacts for prompt comparison. The app also has basic rate limiting and generic user-safe errors. Full production monitoring, usage logs, persistent feedback storage, and durable eval result storage are scoped as post-pilot deployment requirements. | |||
| Ongoing Improvement | How will you collect learnings, review performance, and update your system continuously post-launch? | Rasoi will improve through an eval-driven iteration loop. New prompt versions are tested against the full eval suite before release. New pilot feedback and observed failures become new test cases. Prompt changes are tracked by the failure they address, then re-run to check for regressions. If repeated GI accuracy or grounding failures appear, the phase-2 path is to add RAG over verified nutrition/GI sources. | ||||
