About Homebite
Personal story & inspiration
I built Homebite because I kept running into the same problem at the end of a long day: I wanted to cook, but I didn't know what to make — and the second I opened a recipe app, I was scrolling through options instead of actually starting.
That felt bigger than just me. Gen Z eats out more than any other generation, and a huge share of young adults don't feel confident cooking a basic meal. Cooking isn't modeled at home as often as it used to be, and with delivery and ready-to-eat food everywhere, the skill never gets built through everyday necessity. The barrier isn't always motivation — it's indecision before the first step.
Homebite is my answer to that moment: open the fridge, feel stuck, and need someone to just tell you one thing to make tonight.
What it does
Homebite turns what's in your kitchen into a single, confident dinner plan.
- One recipe from what you have — type ingredients, scan a grocery receipt, or upload a photo; set your time and vibe; get one AI-generated recipe with clear steps, not a feed to scroll.
- Recipes of the Week — browse a stable catalog of real dishes from TheMealDB, filter by name, category, or cuisine, or hit Surprise me when you're bored.
- Cook with backup — re-roll for a different idea, save recipes for later, or use the floating chat for swaps and step help while you cook.
- Product Pulse — an in-app view of Novus product memory and early funnel data, synced with Pendo analytics.
The core idea is simple: remove the "what do I even make?" step so cooking feels doable instead of daunting.
How I built it
Homebite is a full-stack web app on TanStack Start and TanStack Router (React 19), with Vite and Nitro for production builds and deployment on Vercel. Server functions keep API keys on the server — Gemini calls, MealDB fetches, vision OCR, and chat never expose secrets to the browser.
| Layer | What it powers |
|---|---|
| TanStack Start | UI, routing, SSR, and server-side API calls in one codebase |
| Google Gemini | Recipe generation (structured JSON), receipt/fridge OCR, and the cooking chat |
| TheMealDB | Real recipe catalog for browse, filters, and random picks |
| Novus + Pendo | Auto-mapped pages, events, and funnels; Product Pulse mirrors the Novus dashboard |
The UI uses Tailwind CSS 4, shadcn/ui, and Framer Motion. Recipe photos come from MealDB when available, with an optional Pexels fallback. Session state for the active cook flow lives in a lightweight client store; saved recipes persist in localStorage for now.
I instrumented key user actions (ingredients_submitted, recipe_generated, recipe_saved, browse_events, and more) so Novus could map 6 pages, 25 events, and 11 funnels from the codebase without hand-written product docs.
Challenges I ran into
Gemini free-tier limits. Early on, recipe generation hit 429 rate limits during testing. I added in-process quota guards, smarter retry behavior (skip retries on rate limits), and separate text vs. vision models so OCR and generation don't compete blindly for the same budget.
Saved recipes that didn't show up. Saving a recipe and navigating to /saved sometimes landed on an empty page — a race between navigation, React state, and localStorage. I fixed it with a same-tab session handoff, a refreshed storage snapshot, and a loading state so the saved list only renders after client storage is ready.
Browse felt random every visit. The original browse flow called MealDB's random endpoint on load, so the grid reshuffled constantly. I replaced it with a stable weekly catalog built from fixed category and area filters, with client-side filtering and pagination so the experience feels curated, not chaotic.
Making Novus data feel real in the app. Product Pulse needed to reflect what judges would see in the Novus dashboard — persona, product areas, funnels, and honest early session numbers — not inflated marketing copy. That meant syncing a Novus snapshot into the app and wording metrics carefully (sessions started, not "visitors").
Full-stack framework learning curve. TanStack Start, server functions, and Nitro deployment were new to me. Getting SSR, client-only storage, and server-only AI calls to coexist without hydration mismatches took iteration.
Accomplishments that I'm proud of
- Shipping a live, public URL on Vercel that anyone can use — not just a localhost demo.
- A complete ingredients → recipe flow with receipt OCR, photo upload, re-roll, edit-and-regenerate, and error recovery.
- Product Pulse — surfacing Novus memory and funnel insights inside the product itself.
- Thoughtful analytics instrumentation across the core cook journey, with Novus auto-mapping the structure from code.
- A polished UI with dark mode, conversational recipe copy, and a chat assistant that reads session context.
- Fixing real bugs (save persistence, quota handling, stable browse) that made the demo reliable under pressure.
What I learned
- The hardest part of cooking apps isn't recipes — it's decision fatigue. Designing for one recommendation changed how I thought about the whole UX.
- Server functions are a sweet spot for AI apps: keep keys safe, call models from the server, stream results to a simple client flow.
- Free-tier AI requires product-level guardrails, not just error messages — rate limits, model selection, and retry policy all matter.
- Product analytics isn't an afterthought. Wiring Pendo early and letting Novus map the codebase gave me funnel data I wouldn't have had from gut feel alone — like seeing ~92% of sessions drop off before users even start the ingredient flow.
- TanStack Start + Nitro + Vercel is a viable stack for a modern full-stack React app with minimal deploy config.
What's next for Homebite
- Auth and cloud saves — Firebase (already stubbed in env) so saved recipes and pantry state follow users across devices.
- Onboarding guides — Novus flagged zero in-app guides; short prompts on Home could address the biggest funnel drop-off.
- Smarter ingredient matching — richer MealDB integration and better "what you have vs. what you need" logic.
- Pantry mode — remember staples you always have so users don't re-enter them every session.
- Meal planning — weekly plans built from saved recipes and the browse catalog.
- Stronger Product Pulse — live Novus sync instead of a snapshot file as session volume grows.
Built With
- framer
- gemini-api
- github
- javascript
- mealdb
- node.js
- novus
- pendo
- pexels-api
- react
- tanstack
- typescript
- vercel
- vite
Log in or sign up for Devpost to join the conversation.