Case Study
Nutravoe
A D2C subscription platform for a fresh-food brand in Bengaluru, built from scratch, live since April 2026.
Why it exists
The problem wasn't a website. It was a system.
Harshita was running a food brand from her kitchen in Bengaluru. Orders came in on WhatsApp. She'd reply manually, batch deliveries in her head, and pray nothing overlapped. She had a product people loved and genuinely no system beneath it.
The complication wasn't just "she needs an e-commerce site." It was that no existing platform understood her constraints: fresh food with a 24-hour shelf life, a subscription model that needed wallet logic, and a customer who orders at 11 PM expecting delivery by 8 AM. Shopify assumes you have inventory. Swiggy assumes you want a marketplace. Neither assumes you're making things the same morning they're delivered.
The operational insight behind the product: fresh-food D2C and fashion D2C are fundamentally different businesses. One is pull (the customer shops when ready); the other is push (the brand controls supply, timing, and the customer's morning routine). The platform had to be built around that push model: subscription-first, delivery-window-first, small-batch-first.
System Architecture
How the system is wired
The stack has four distinct layers: content management, data and auth, payments, and geo-validation. Each layer is independently replaceable, a decision made deliberately, since early-stage products swap vendors.
Guest checkout flow: Customer selects bowls → cart state held in React context → checkout form submits to /api/orders/request → server-side price recalculation (never trusting client totals) → Razorpay modal → webhook confirms payment → order row updated → confirmation email via Brevo.
Subscription flow: Customer logs in → selects plan type (Spread Week or Flexible Wallet) → configures day-by-day bowl selections → Postgres RPC atomically approves payment and creates delivery order rows per scheduled date → admin reviews in dashboard → marks delivered.
Design Decisions
Five calls that shaped everything
No Swiggy. No Zomato.
Marketplaces flatten differentiation. A ₹299 bowl becomes one item in a scroll next to fourteen competitors. The brand story, the subscription relationship, the founder-customer connection: all of it disappears. Zomato's algorithm decides your visibility, not your quality.
Tradeoff: Lower discovery reach. The brand has to do its own acquisition work. Worth it, because the customers acquired through direct channels have a 35% repeat rate, a number that aggregators would destroy by attracting one-time deal seekers.
Two subscription types: Spread and Flexible Wallet
Spread subscribers commit to a fixed weekly schedule. Flexible subscribers prepay into a wallet and pick bowls day-by-day. The wallet model exists because customers want flexibility but operations need predictability. Prepayment gives the brand cash certainty; the wallet gives the customer optionality.
Tradeoff: The wallet adds significant backend complexity: reservation logic, top-up flows, atomic debit operations, and balance reconciliation. Every edge case in subscription management doubles when you add a wallet.
Sanity CMS for menu management
Menu changes (a bowl going out of stock, a price update, a seasonal addition) should not require opening a code editor. Sanity gives the founder a visual interface to manage this without a developer dependency.
Tradeoff: Adds a CMS layer, a separate deployment (Sanity Studio), and a build step for content-driven changes. For a solo founder, the independence is worth that overhead.
Ola Maps over Google Maps for delivery validation
Google Maps API costs scale quickly with geocoding requests. Ola Maps (Krutrim) is Indian-first, more accurate for Bengaluru address strings, and significantly cheaper at volume. Delivery radius validation happens on every checkout; the cost per call matters.
Tradeoff: Smaller developer community, thinner documentation, less stable SDK. A Nominatim fallback was added for resilience.
Server-side price recalculation on every order
The client sends item selections; the server recalculates the total independently before creating the Razorpay order. The client total is never trusted. This prevents the classic cart manipulation attack where a modified frontend sends a lower price.
Tradeoff: An extra DB read per checkout. Completely worth it.
Operational Thinking
The constraints that actually govern the system
AI System Thinking
Why there's no AI in this product
Nutravoe doesn't use AI. That was a choice, not an oversight.
The problems here are operational, not generative: does the customer's address fall within the delivery zone? Did the payment clear? Is tomorrow's bowl available? These are deterministic questions with deterministic answers. Adding an LLM to answer them would introduce latency, cost, and probabilistic behaviour into a system where reliability is the product. When someone's breakfast depends on it, you don't want "mostly correct."
The closest thing to AI in the current stack is Ola Maps' geocoding, inferring a valid deliverable address from a typed string. That's the right level of intelligence for this problem: fast, deterministic-enough, and invisible to the user.
V2 possibilities worth exploring: demand forecasting from subscription patterns to reduce over-preparation waste; a WhatsApp chatbot for subscription management (pause, swap, top-up wallet) without needing the web app; smart reorder suggestions based on purchase history. But only once the deterministic foundation is stable and the webhook is wired.
Let's talk.
Open to full-time roles and consulting engagements.
Based in India · Open to relocate globally.