SELF-BUILT PRODUCT
NURISHI
An AI health coach for Indian parents that plans with you, in the food you already cook.
Nurishi is a health coaching app for older Indian parents, built around two AI coaches, Noor for nutrition and Rishi for fitness, who work with the food and routines a household already has, instead of asking someone to replace them.
I conceived, designed, and built the product to explore one question: what does it take for an AI coach to feel like a plan, not a chatbot waiting to be interrogated?
Role
Product concept, UX, voice design, and AI-assisted build
Format
Web and mobile health coaching product
Status
Self-built, in active development
Core rule
Arrive with a plan. Refine it by talking. Keep eating what you already cook.
WHY I MADE IT
Most health apps assume a default user who counts calories, has gym access, and is willing to replace their diet with something unfamiliar. That default fails a large and specific group: older Indian parents whose diet, language, and daily rhythm were never built into the product in the first place.
The deeper problem wasn't nutrition literacy. Indian parents largely already know what's healthy. What was missing was a coach that treated their existing food as the foundation, not the obstacle, and a voice that didn't sound like one more authority lecturing them about a lifestyle they've had for sixty years.
I wanted a coach that sounded like it was on their side, not one more institution asking them to change everything at once.
The coach should sound like someone who already knows what's in your kitchen.
THE PRODUCT RULE
The product is organized around a single constraint: a user should never open the app to an empty conversation. The moment onboarding finishes, Nurishi generates a real plan, a daily meal skeleton with a protein target, and a Week 1 workout plan grounded in equipment the person actually has, before any chat begins.
There is nothing to figure out how to ask. The plan is already there, and the coach's first message references it directly.
That rule shaped everything downstream: what onboarding needed to capture, what the coach's first message could say, and why the chat interface exists to refine a plan rather than generate one from scratch.
TWO PRINCIPLES
01
WORK WITH WHAT'S THERE
A meal plan built from dal, roti, sabzi, and paneer is more useful than one built from ingredients a household doesn't already buy. Nurishi treats the existing diet as the foundation, and finds protein and nutrition gains inside it, not around it.
02
A COACH, NOT AN AUTHORITY
Noor and Rishi are voiced like the user's own adult children, the people already encouraging them to take their health seriously. Warmth first, guidance second, never a lecture.
HOW IT WORKS
Nurishi's onboarding is short but specific: health conditions, dietary restrictions, and, for anyone training with Rishi, the equipment, time, and mobility limits that make a workout plan realistic instead of generic.
The moment onboarding completes, the app generates the user's first plan and drops it directly into the coach's opening message. From there, chat becomes the place to refine a plan that already exists, not to build one from nothing.
01
ONBOARD
Share health conditions, dietary needs, and, if training, equipment and mobility limits.
02
GENERATE
Nurishi builds a daily meal skeleton with a protein target, and a Week 1 workout plan if relevant.
03
ARRIVE
Land in chat with the plan already visible and the coach's first message referencing it.
04
REFINE
Ask Noor or Rishi to adjust: swap an ingredient, change a session length, work around a bad knee.
05
RETURN
Come back day to day with a plan that's already yours, not a blank box to start over in.
DIARY, PROGRESS, AND THE REWARD LAYER
The plan is only the starting point. Diary, Progress, and a lightweight reward layer turn repeated use into something the user can actually see and return to.
01
GAMIFICATION
A lightweight reward layer gives repeated check-ins a sense of momentum without making the experience feel competitive.
02
DIARY
A private diary turns individual check-ins into a personal record users can return to over time.
03
PROGRESS
Progress tracking makes consistency and change visible, so users can see what their repeated entries are building toward.
The three work as one system: users record experiences through the Diary, build continuity through repeated use, and see that continuity reflected back through Progress and the reward layer.
A COACH THAT LEADS, NOT WAITS
The hardest product decision was also the simplest: the coach needed to go first.
Most chat-based products wait for the user to know what to ask. That default works for people comfortable interrogating software. It doesn't work for someone unfamiliar with structured self-tracking, who will simply close the app rather than figure out a good opening question.
Nurishi inverts that. The AI generates a complete plan the moment onboarding ends, and the chat exists downstream of that plan, as a place to negotiate it, not originate it.
The plan also carries real constraints, not just preferences. Health conditions and mobility limits shape what the coach is allowed to suggest, so guidance stays medically sensible for an age group where hypertension, diabetes, and joint issues are common.
KEY PRODUCT DECISION
Deliver the plan before the conversation, not after it.
VISUAL DIRECTION
Nurishi needed to feel calm and legible rather than clinical or gamified, an interface an older parent could sit with, not a dashboard demanding to be optimized.
Type sizes, tap targets, and contrast were set for an older-adult audience first, with the coach personas carrying warmth through language rather than through decoration.
The desktop layout keeps the plan visible at all times, alongside the conversation, so the two never feel like separate destinations.
FROM IDEA TO PROTOTYPE
The project began with a diagnosis, not a feature list: the app had a chat interface with nothing to say. I mapped the full journey from onboarding through plan generation, chat, and weekly regeneration before touching any UI.
AI-assisted development, built in partnership with Lovable, let me move from spec to a working prototype quickly, and made a lot of decisions concrete that would have stayed abstract in a deck: where the plan should live on screen, what the coach's first message should say, what happens when a plan fails to generate.
Writing the plan-first specification forced a lot of small but real product decisions: what happens when equipment is left blank, how a regeneration limit should behave, what a user sees while a plan is being generated instead of a blank loading screen.
Onboarding-to-plan flow
01
Onboard
Health conditions, dietary needs, equipment and mobility limits
02
Generate
Meal skeleton, protein target, and Week 1 workout plan
03
Arrive
Chat opens with the plan already visible
04
Refine
Adjust the plan through conversation with Noor or Rishi
05
Regenerate
A new plan each week, still grounded in the same constraints
loops back to onboard
The mapped journey moved from onboarding through plan generation into an ongoing, plan-aware conversation. A generalized representation of the flow, not a product screenshot.
WHAT I WOULD TEST NEXT
The plan-first bet is strong, but untested at scale. These are the first questions I would test with real users:
01
Does receiving a plan immediately increase Day-2 return rate, or does it just shift the point where users drop off?
02
Is a repeatable meal skeleton satisfying over multiple weeks, or does it need more variety than cost and cultural fit initially suggested?
03
Does voicing the coach like an adult child build trust, or does it read as presumptuous to some users?
04
Does the 24-hour regeneration limit feel like a sensible pace, or like an arbitrary restriction?
These are proposed validation questions, not claims about completed user research or product performance.
WHAT I LEARNED
Nurishi clarified that gamification is only useful when it helps people notice continuity. The Diary and Progress views mattered because a single entry has limited value on its own; the product becomes useful when repeated entries form a record users can understand. The reward layer needed to support that accumulation rather than distract from it.