Case Study 06 · Indeats · Founder · Product Strategy · AI-Native Build

Indeats — From market gap to
live product with AI.

I identified a real unmet need in the Indian diaspora dining market, defined the product strategy, designed the full system, and shipped a live product end-to-end — using Claude as my engineering partner and applying 10 years of product design craft to direct every decision.

View live app → indeats.app
Role
Founder · Product Designer
Platform
Web · Mobile
AI Partner
Claude (Anthropic)
Pilot Cities
Fremont · San Jose · Sunnyvale · Artesia
Live URL
4
California cities in live pilot
5
Pages designed and deployed
0
Engineers hired
1
Designer who shipped the whole thing
Executive Summary

Indeats is my answer to a product gap I experienced firsthand: the Indian diaspora in California — 1.4 million people with specific dietary identities, strong dining culture, and almost no tailored discovery tool. Generic platforms like Yelp and Google Maps treat Halal, Pure Veg, and Jain as secondary filters on a platform built for someone else entirely.

I didn’t just build a product. I made a series of deliberate product strategy decisions: what problem was worth solving, who the right users were, what the MVP scope should be, how to sequence features, and where to hold the line on scope. Then I used Claude as a full-stack engineering partner to ship it — applying the same design precision I bring to enterprise client work at Cisco, Microsoft, and Walmart.

Indeats is live at indeats.app. This case study is about the thinking that preceded the building — and what the build itself revealed about AI-native product development.

Product Strategy × AI-Native Engineering × Live Deployment
Market Opportunity
A specific community with specific needs — badly served.

The Indian diaspora in California is not a niche. It is one of the most economically active, food-culturally distinct, and digitally fluent communities in the US. Fremont, San Jose, Sunnyvale, and Artesia are among the highest-density Indian-American populations in the country — and dining is central to how this community socialises, celebrates, and maintains identity.

1.4M
“Indian-Americans in California — the largest state concentration in the US — with no dedicated dining discovery platform built for how they actually make food decisions.”
— Mahesh · Market framing session

The unmet need isn’t restaurants — there are thousands. The unmet need is trust + context + deals in one place. A family deciding where to eat on a Friday night needs to know: is it Halal? Is there a Jain-safe option? Is there a live deal tonight? Is there a cultural event this weekend? None of the existing platforms answer all four questions reliably.

Wrong filter hierarchy

Generic platforms bury dietary filters as secondary options. For this community, Halal / Pure Veg / Jain OK is the first decision — not a refinement of an already-made one.

→ Market gap: dietary identity as primary filter
No live deal layer

Weekly thali specials, festival deals, and happy hour offers change constantly. No platform surfaces these in real time with auto-applied booking logic.

→ Market gap: deals with zero friction to book
Food trucks invisible

Indian food trucks and cloud kitchens are a significant part of how the community eats — particularly for younger demographics. Existing platforms treat them as afterthoughts.

→ Market gap: food format diversity
No dining events layer

Ghazal nights, Holi feasts, chef’s tables — cultural dining events are how the community creates shared experiences. Zero aggregation exists for this.

→ Market gap: cultural event discovery
Product Strategy
Three decisions before a single screen was designed.

Most side projects start with a design. I started with strategy. Three decisions shaped everything that followed — and each one was made before I opened any design tool.

01
Pilot depth over geographic breadth
I could have built a national Indian restaurant platform. I deliberately chose 4 cities in California with the highest Indian-American density. A product that deeply serves 4 cities is more defensible and learnable than a shallow product that barely serves 40. Fremont, San Jose, Sunnyvale, and Artesia weren’t arbitrary — they represent the most concentrated test bed for everything the product needs to validate.
02
Three categories, not one
The original concept was a restaurant discovery app. The product strategy decision was to elevate Food Trucks and Cloud Kitchens to first-class categories — equal in hierarchy to Restaurants, with their own sections, headers, and navigation logic. This was not a UI decision. It was a market positioning decision. Cloud kitchens are growing fastest in this segment, and home-style delivery is core to how the diaspora eats day-to-day.
03
AI as a staged rollout, not a launch feature
I built the full AI concierge — the Cloudflare Worker, the panel, the conversation logic, the contextual prompts. Then I made the strategic call to hold it. Shipping AI recommendations before the underlying data is validated produces worse outcomes than no AI at all. The coming-soon teaser communicates the vision and captures early-access intent without making a promise the product can’t yet keep. This is product discipline, not a capability gap.
AI Reframe — The New Design Practice
This is not “AI built my app.” This is design craft applied to AI.

Vibe coding — generating production code through natural language with an AI model — is a genuine shift in how products get built. But the discourse around it misses the most important point: the quality of what AI builds is directly proportional to the quality of design thinking directing it. Imprecise designers produce imprecise AI output. Precise designers produce production-quality products.

The Core Reframe
AI collapsed the implementation gap. The design gap remained.

For 10 years, the gap between what a designer could envision and what a team could ship was constrained by engineering bandwidth, sprint planning, and hand-off loss. AI collapses that gap. But it replaces it with a different constraint: the designer’s ability to describe interactions with enough precision to be implemented correctly.

Every time Claude produced output that didn’t match my intent, the root cause was my description — not the model. Vague design thinking produces vague implementation. The same principle that governs design critique governs AI direction: specificity is everything.

What changed
Implementation speed

What previously required a sprint (filter system, scroll behaviour, mobile UX) now happens in a session. The constraint is no longer build capacity — it’s decision clarity.

What stayed the same
Design thinking

Problem framing, information architecture, interaction design, edge case reasoning, and aesthetic judgment — none of this is automated. It’s more critical than ever because there’s no engineering team to push back on unclear specs.

What this means for designers
New leverage point

The designer who can direct AI with the same precision they’d use to brief an engineer ships products that previously required a team. That’s not replacement — it’s amplification of craft.

“The workflow looked like a design review session, not a search query. ‘The filter bar needs to be sticky below the nav, with dietary chips on the left and a separator before the quick filters. On mobile it scrolls horizontally without a scrollbar, and the separator collapses.’ That level of specificity, applied consistently, is what produced a production-quality product.”
— Mahesh · Indeats build session notes
Design System
Built from first principles. Not borrowed from a component library.

The Indeats design system was established in the first session before a single page was designed. Every token, every component rule, every interaction pattern was defined and documented as a persistent reference that traveled across every session with Claude. This is the equivalent of a design handoff doc — but written for an AI partner, not an engineer.

System Philosophy
Warm, cultural, food-forward.

The system rejects clinical white UIs and generic food-tech palettes. Dark navy creates contrast and anchors the navigation. Warm beige communicates food, comfort, and cultural familiarity. Terracotta accent carries the visual heat of Indian cuisine without being clichéd. The serif headlines bring warmth and editorial character. The sans-serif body stays readable and precise.

Every token decision traced back to the audience: a community that values cultural identity, warm hospitality, and authentic experience over polished tech minimalism.

Colour Tokens

TokenValueRationale
--nav#071827Dark navy — nav bar, hero sections, footer. Grounds the product in authority and contrast.
--bg#f6f1eaWarm beige — primary page background. Not white. Evokes food, warmth, parchment.
--surface#ffffffWhite — cards, inputs, filter chips. Contrast against the beige body.
--accent#f2551cTerracotta orange — CTAs, active chips, arrow links. Primary action colour.
--text#1a1410Near-black with warmth — avoids the coldness of pure #000.
--muted#6b6259Warm grey — secondary text, metadata, labels, muted copy.
--line#e6d8c8Warm sand — dividers, borders, chip outlines. Never a cold grey.
deal badge#c9320aDarker terracotta — deal badges only. Distinct from the primary accent.
diet chip active#171717Near-black active state for Halal / Pure Veg / Jain OK chips. Signals dietary identity, not just a filter.

Typography

TypefaceWeightsUseRationale
Playfair Display700, 800 (italic)Hero headlines, section titles, stats, brand nameWarmth, editorial character, cultural reference to South Asian print tradition
DM Sans400, 500, 600, 700All body copy, nav, chips, labels, metadataClean, humanist, readable at small sizes. Works at 10px label through 17px body.

Card System

Discover Cards (.disc-card)

Image-first, 148px image height, 14px border-radius, white bg, no border, shadow 0 2px 14px rgba(17,24,39,.08). Deal badge top-left (#c9320a, rect pill). Heart top-right. No buttons — whole card is the tap target. On hover: translateY(-2px) + shadow deepens.

Deal Cards (.deal-card)

Same radius/shadow/bg as Discover cards. 148px image height (up from 110px in v1). Keeps deal text, expiry badge, diet tags, and Unlock Deal button — appropriate for the evaluation context of a deals page.

Filter Bar (.diet-bar)

Sticky at top:64px (below nav). Diet chips left — active state dark (#171717). Separator (1px vertical, --line). Quick chips right — active state accent orange. Scrolls horizontally on mobile without scrollbar. Applies globally across all sections simultaneously.

Navigation (.nav)

Dark navy sticky bar, z-index 100. Desktop: single row. Mobile: flex-wrap with nav-tabs at order:99 — creates clean two-row layout (logo+actions / tabs). Active tab: white text + 2px accent underline. Applied consistently across all 4 pages.

Mobile UX Pattern — Two-Step Discover

StepBehaviourImplementation
Step 1 (default)Horizontal scroll rows. Cards at 72vw so the next card peeks — inviting swipe. All 3 sections visible simultaneously.flex-direction: row, overflow-x: auto, scroll-snap-type: x mandatory
Step 2 (expanded)Tap → arrow or “See all” → other sections hide, active section expands to full single-column stacked list. ← Back appears..page-body.expanded + .discover-section.expanding via expandSection()
Desktop guardexpandSection() returns early on desktop. Resize to desktop auto-collapses.isMobile() = window.innerWidth ≤ 760
Key Product Decisions
Seven decisions. Each one made from evidence, not assumption.
01
Dietary filter as identity, not preference
This was the most important product decision in the entire build. Every other Indian restaurant aggregator treats dietary filters as refinements. I made them the primary signal — sticky, always visible, globally applied before any other filter. Halal, Pure Veg, and Jain OK are not preferences for this audience. They are the first question that gates every other decision. Getting this architecture right is what makes Indeats feel like it was built for this community, not adapted for it.
02
One filter bar, not three
Early version had per-section filter chips embedded in each section header — different chips for Restaurants, Trucks, and Cloud Kitchens. This was technically reasonable but experientially wrong: it required users to re-apply dietary preferences every time they changed sections. A unified global filter bar that applies across all three sections simultaneously respects that dietary identity doesn’t change between scrolling a restaurant row and a food truck row. This was a product decision about user mental models, not a design preference.
03
Three sections over one grid
The first version was a single restaurant grid. The product decision was to elevate Food Trucks and Cloud Kitchens to first-class categories with equal hierarchy, distinct headers, and their own navigation logic. This is a positioning decision: Indeats is not a restaurant discovery app with some trucks thrown in. It is an Indian food discovery platform that treats every format the community uses as a primary category.
04
Mobile: horizontal scroll first, expand on intent
Studied Uber Eats mobile UX extensively before deciding on the two-step pattern. Step 1 (horizontal scroll) gives content density without forcing a commitment to scroll through one category. Step 2 (tap See all) is a deliberate intent signal. The two-step model preserves browsing breadth while still giving access to depth — which matches how this audience makes dining decisions: scan broadly, then commit.
05
Deals cards retain full information
I was tempted to simplify Deal cards to match Discover cards for visual consistency. I chose not to. Discover and Deals serve different user jobs: Discover is browsing (image + name is sufficient), Deals is evaluation (offer text, expiry, social proof, and a clear CTA are all necessary). Forcing visual consistency across different functional contexts produces a system that looks unified but fails users at the moment they need information most.
06
AI concierge as staged rollout
The AI layer is architecturally complete. The Cloudflare Worker is deployed. The conversation logic, contextual greetings, and recommendation model are built. I made the deliberate product call to hold activation until the data layer validates. An AI that makes recommendations from incomplete restaurant data produces worse user trust than no AI at all. The coming-soon teaser communicates the vision, captures early-access intent, and keeps the door open — without shipping prematurely.
07
Ship live from day one, iterate in public
I deployed a live URL before the product was complete. The footer was unstyled. Some cards had no photos. Navigation was broken on mobile. Every issue was found and fixed faster on a live domain than it would have been in local development. Shipping early collapses the gap between what you imagined the product to be and what it actually is — and that gap is where bad design decisions hide.
Trade-offs — What I Chose Not to Build
Scope discipline is a product skill.

Every deferred feature was a deliberate call. Indeats is a pilot. The goal of v1 is to validate the core loop — dietary-first discovery + deals + booking intent — not to build every feature the product could eventually have.

Live restaurant data API
All cards use curated data with real food photography. A live API integration requires restaurant partnerships, data agreements, and ongoing maintenance. None of that is valuable before the core user loop is validated.
→ Deferred: pending partnership agreements
Authentication + user accounts
The Sign In / Get Started flow leads to a coming-soon state. Full auth requires a backend. The UX is designed — the infrastructure is deferred until there is enough user demand to justify the maintenance cost.
→ Deferred: post-validation
Live AI concierge activation
Built, tested, and ready. Held until the restaurant data layer can support recommendations that are actually better than a user’s own search. Shipping AI on sparse data is worse than no AI.
→ Deferred: pending data quality
Section destination pages
Food Trucks and Cloud Kitchens “See all” links are live but go to a placeholder. Full category pages are designed — building them before validating that users actually use these sections would be premature investment.
→ Deferred: post-engagement data
Before & After
From generic restaurant grid to a community-specific discovery platform.
Before — v1
What the first version looked like
  • Single restaurant grid, no category hierarchy
  • 12 filter chips scattered across 3 section headers
  • Food trucks buried at the bottom as a scroll strip
  • No Cloud Kitchens category
  • Mobile: full-width stacked cards, no scroll pattern
  • Nav tabs invisible on mobile
  • Footer: unstyled plain text
  • Solid color placeholders, no food photography
  • Deal cards: narrow image, bottom-right save button
After — v2 (Shipped)
What shipped to indeats.app
  • Three distinct sections, each a first-class category
  • One unified filter bar — 7 chips, globally applied
  • Food Trucks: own section, header, chips, navigation
  • Cloud Kitchens: own section, exclusive to Indeats
  • Mobile two-step UX: scroll rows → expand → back
  • 2-row mobile nav, consistent across all 4 pages
  • Footer: dark navy, 4-column, fully styled
  • 18 cards with real Unsplash food photography
  • Deal cards aligned to Discover visual language
Outcomes
One founder. One AI. One live product.
4
Cities in Live Pilot
Fremont, San Jose, Sunnyvale, and Artesia — the highest-density Indian diaspora areas in California, chosen deliberately for maximum signal density.
5
Pages Shipped
Discover, Deals, Events, Bookings, and Restaurant Detail — all deployed, live, and navigable at indeats.app.
0
Engineers Hired
Every line of production HTML, CSS, and JavaScript was generated through conversation with Claude and reviewed by me before deployment.
Reflection
What I confirmed. What I’d do differently.
01
Product thinking is not separable from AI direction
The decisions that made Indeats good — dietary identity as primary filter, one global filter bar, AI held until data is ready — were product strategy decisions made before any code was written. AI compressed the cost of implementation to near-zero. It did not replace the thinking that made the implementation worth doing. The designer who can think at product level and direct AI at implementation level has a capability combination that didn’t exist five years ago.
02
Ship live, iterate in public — the feedback loop compresses
The most valuable QA session of the entire build was reviewing the live site at indeats.app on a real mobile device. Issues that were invisible in local development — nav tabs overflowing, back button visible on desktop, footer unstyled — were immediately obvious. The live URL is not a milestone. It is a tool. The earlier you have it, the faster you improve.
03
What I’d do differently
I would define the design system SKILL file — a persistent AI memory document carrying all tokens, component rules, and interaction patterns — before writing a single line of product code. Rebuilding context at the start of each session was the primary source of friction. A well-maintained AI context file is the new design system documentation. It just has a different reader.
04
What this project says about the next five years
Indeats is evidence that the product designer role is expanding, not contracting. The designers who thrive will be the ones who can hold product strategy and technical implementation simultaneously — not because they’re doing both, but because they can direct both. AI gives product designers a lever that reaches all the way to production. The question is whether you have the craft and the judgment to use it well.
“I didn’t build Indeats despite being a designer with no engineering background. I built it because of what design taught me: think precisely about the problem, be specific about the solution, and know when the output is right.”
— Mahesh Guntivenkata · Indeats · Founder