이거먹어

The daily "what should I eat?" looks trivial but carries a real decision cost. And it isn't solved by taste alone - the core is the clash between "what you want to eat" and "what you should eat." You're on a diet so you can't have what you crave; you're sick and should eat porridge but hate porridge; on a cold day you want something with broth. Delivery apps recommend off order history and popularity/ads, but that's "what you bought in the past," not "you in your current state." And since their goal is order conversion, a recommendation like "go light today" is something they structurally never make. The result: facing an endless menu scroll, the decision just gets pushed back further.

Built alongside my PO/PM transition - a mobile-app experiment that frames an everyday problem (decision fatigue) as "we decide, existing platforms execute." Built end to end solo as a monorepo (Expo app + FastAPI + food-graph pipeline). Payment and delivery aren't handled directly; they're handed off via deeplinks to delivery apps and maps. That's both the hypothesis (just nail the decision layer) and a practical choice to avoid the business-registration burden.

Everyday people who hit "what should I eat today?" daily - especially those who can't just eat what they crave because of constraints like dieting, health, or allergies.

Recommend with a two-layer structure - a stable base taste (gathered via the onboarding grid) plus your current context (diet, illness, mood) - and you can give a "current-you" answer in 1-3 picks, better than a delivery-app search. And the substitution recommendation - "can't eat X -> a similar, satisfying Y" - becomes the heart of the app.

• Built food-relation graph v1 - tagged 182 dishes with a local LLM (Ollama qwen2.5:7b), built a similarity graph via embeddings (nomic-embed-text), then overlaid a human-review correction layer (overrides.yaml)
• Recommendation pipeline - hard filter (allergens, hard excludes, constraints) -> context adjustment (normal, diet, when sick, hangover, late-night) -> base-taste scoring -> LLM selection, reasoning, substitution
• Substitution engine - for input like "I hate porridge," it offers alternatives each with a one-line "why this is okay instead of porridge"
• Adaptive onboarding grid (YouTube Music-style) - lays out food photos and gathers base taste quickly via multi-select
• Expo (React Native) app - the full flow runs on a real device (Android): splash -> login -> onboarding -> recommendation -> handoff
• Handoff deeplinks - delivery routes to a search, dining-out routes to a nearby search on KakaoMap, leaving execution to existing apps
• Validation tools built ahead - a manual concierge kit and a fake-door landing page to probe the hypothesis without code

• Decision killer - not "show many" but narrow hard to 1-3. Endless scroll is the cause of decision fatigue, so it deliberately gives less
• Separate "not now" from "never" - so today's not-feeling-it (temporary) doesn't harden into a permanent block
• LLM only after retrieval - filter real candidates first, then the LLM only selects, explains, and substitutes within them. Hallucinating a dish that doesn't exist is blocked structurally
• Display name and code name kept separate - the marketing name (이거먹어) can change without tearing up the codebase, since the display name and the internal code name run on separate layers
• Payment and delivery via handoff - the transaction goes to existing platforms; only the decision layer is owned

Phase 0 (food graph) complete + a substantial part of the Phase 1 MVP working. The full flow runs on a real device (Android, EAS dev build). But the backend (API, Postgres, Ollama, images) is all on the dev Mac locally, so deployment is the biggest next task, and Kakao login is still a dev stub. User metrics not yet measured.

Confirmed how hard the assertive "we decide for you" value is to land. Narrowing to 1-3 is easy, but for that narrowing to be trusted, recommendation quality and speed came first. First-recommendation latency moved the felt experience a lot, so I handled negation with a deterministic parser, guaranteed Korean output, and switched models to get roughly 4x faster. The next round's hypothesis: the first gate for this product is trust that "it never violates a constraint," more than how natural the recommendation's "reasoning" sounds.

• Finishing the app flow first while keeping the whole backend on the dev Mac locally produced a "works, but only I can use it" state. I should have wedged in deployment earlier, even just one piece.
• I grew the build while deferring "who actually pays" - the very thing I'd written into the spec as "decide this first." Since that decision changes the product's shape, next time it goes ahead of building.