Solo DesignerHealth & Nutrition SaaSWeb and Mobile

NutraHive

Designing a nutrition platform where the pricing cannot be gamed, the signup does not stall, and a plan cannot go out incomplete

NutraHive connects metro city working professionals with certified nutritionists for personalized, week based diet plans, backed by a physical cafe where clients can eat meals that actually match their plan. The founders came to me with a validated idea and a working prototype, but it hadn't been designed. My job was to turn that raw concept into a considered product across web and mobile, each with two sides: a client experience and a nutritionist experience.

RoleUI/UX Designer (Solo)

CompletionPre launch

PlatformWeb and Mobile

Design focusClient and nutritionist experience across both platforms

The client app as it opens, where finding a nutritionist is the first step into the whole flow.

My Role

Shaping a rough prototype into a considered product

I joined with a validated idea and a functional but undesigned prototype already in place. My job was end to end UX and UI across web and mobile, for both the client and nutritionist sides, including building the visual and illustration language from scratch and working closely with the development team to refine flows during build. For some flows, I used AI tools to generate a rough baseline direction early, then critiqued and reworked it into the final UI myself; it helped early iteration move faster, but every interface decision in this project was mine.

An original watercolor illustration system built for onboarding, explored across several directions before landing on the final style.

Key Decisions

Four decisions where rethinking the logic behind a flow, not just the interface, made a nutritionist's or client's task noticeably simpler.

Pricing per week instead of per month

ProblemPlans are built and delivered in weeks, twenty one meals at a time, but every plan was priced as one lump sum for its whole length. A client was comparing ₹4,074 against ₹28,224 with no way to tell which was the better deal.

DecisionShowed every plan as a price per week, with the meal count and cancellation allowance beside it. The base rate is ₹4,200 a week, twenty one meals at ₹200 each, and every plan price is that figure minus its discount.

WhyThe unit a client pays in now matches the unit they receive in, which makes the four durations directly comparable at a glance.

Before

Select duration screen with one, two, four and eight week cards priced as a single total

After

Select duration screen with one, two, four and eight week cards priced per week

The same four cards before and after. Only the price line changed, and that was enough to make the durations comparable at a glance.

Closing a loophole in the installment plan

The 4 week plan costs ₹14,280 and can be paid in 2 partsThe second part is due after 2 weeks. So a client can pay the first part, eat for 2 weeks, and then walk away. If ₹14,280 was split 50-50, that first part would not match what the 2 week plan costs. The 2 week plan gets 10% off and the 4 week plan gets 15% off, so the client would be leaving with the bigger discount after the shorter stay.

Case AA client buys the 2 week plan.

Case BA client buys the 4 week plan, pays half of it now, then leaves after 2 weeks.

What you pay

₹0₹2,000₹4,000₹6,000₹8,000

₹7,560

₹7,140

₹420

Case ACase B

Both clients ate for the same 2 weeks. Case B paid ₹420 less for it.

₹7,140The money a client would have paid if ₹14,280 was split 50-50. This is Case B.

₹7,560The money I decided to charge for the first part, which is 52.9% of ₹14,280. It matches the 2 week plan, and that is Case A.

So I did not cut ₹14,280 in half. The first part is ₹7,560 and the second part is ₹6,720, so leaving early saves nothing. The 8 week plan works the same way, with parts of ₹7,560, ₹6,720, ₹6,972 and ₹6,972, where the first two parts add up to ₹14,280, which is exactly the 4 week price.

Review and activate screen showing plan summary, bill summary and the two payment options

The same 2 parts as a client sees them at checkout.

ProblemThe 4 week plan is paid in 2 parts. A 50-50 split would let a client pay once, eat for 2 weeks, and leave having paid ₹420 less than the 2 week plan costs.

DecisionPriced the first part at ₹7,560, which is exactly what 2 weeks costs, and the second at ₹6,720. The 8 week plan is split by the same rule.

WhyLeaving early no longer saves anything, so every discount stays tied to the length a client actually commits to.

Deferring onboarding data collection until after first use

ProblemCollecting full onboarding data, height, weight and physical activity level, upfront at signup added friction before a client had experienced any value from the product yet. The menu still had to show a client something sensible while that profile did not exist.

DecisionPulled those questions out of initial signup and moved them to appear after a client's first two to three orders, making them compulsory only if a client is still booking an appointment without having filled them in. Until the profile exists, the menu is ordered by what is popular and what that client has ordered before, rather than by anything personal.

WhyA new client can start ordering right away without a long form in the way, the app never has to personalise from data it does not have yet, and the profile is still guaranteed before the one place it is actually needed.

Signup asks for an account and nothing else.

Height, weight, activity, goals and health concerns, all moved here.

Booking is the one place it becomes required, so Continue stays disabled until it is filled.

Locking the diet plan flow into one direction

ProblemBuilding a plan means entering several dependent pieces in order, the client, the plan, the meals, then the note. An open ended form made it easy to jump around and end up sending something incomplete or mismatched.

DecisionThe weekly meal template and the client facing note stay locked until a plan is selected, and the send action stays disabled until at least one meal is on the week, so there is only one path through the form.

WhyA predictable order stops plans from reaching a client with missing meals or the wrong template.

Nothing opens until a plan type is chosen, and the send action stays off until a meal is on the week. Each step unlocks only the one after it.

Additional Work

Nutritionist portal

Sending a plan to a client shows a confirmation toast with a 10 second undo, so a nutritionist can catch a mistake before it reaches the client.

Add blocked slots modal with a calendar, open slots and locked booked slots

Nutritionists can block their own dates directly, rather than the system only ever showing open slots. Already booked slots stay locked, with a note explaining why.

Nutrient values such as fiber, fat and protein update automatically based on the add-ons selected on a meal, not just the base dish.

Client ordering and cafe pickup

Wallet credit from cancelled meals applies straight against the bill, so the total drops to zero when the balance covers it.

Tracking an order on its way from the cafe.

Confirmation once an order is placed.

Outcome

NutraHive hasn't shipped yet, so this reflects intended impact, not measured results. Each decision targeted a specific friction from the original concept: pricing shown in a unit the plan was never built in, an installment split that let the longest plan undercut the shorter ones, an onboarding flow that asked for too much too soon, and an open ended plan builder.

Discounts that hold their shape.Pricing each installment at what those weeks cost on their own should keep every plan length worth choosing, rather than letting the longest plan undercut the rest.

A lighter first-time experience.Deferring onboarding questions until after first use should reduce signup drop-off without losing the data long term.

Fewer incomplete plans.Locking the plan builder into one direction should stop plans from going out with missing meals or against the wrong template.

This case study will be updated with real results once NutraHive is live.