Tastebook

People don't need more recipes. They need to remember the meals they already love.

Tastebook is an iOS app that treats your meal history like a photo feed. TikTok-style vertical browsing through your own meals, household sharing with a partner, and AI-assisted grocery lists that turn a week plan into a shopping trip. The core insight: a photo of your ratatouille from last Tuesday is more useful than a stranger's recipe for ratatouille.

The project started as a rough idea in a Claude Code conversation. I described the core concept (photo-first meal catalogue, social-media-style browsing, household sharing) and let Claude probe for gaps.

That single session produced a full product spec: personas, six user flows, an MVP feature set with pre-defined tag taxonomy, empty state copy, and a business model. Claude asked the questions a good PM would ask. What happens when the catalogue is empty? How does household sharing work technically? What's the post-trial experience for non-paying users?

I made every product decision. Claude structured them into a spec that could later drive implementation with minimal drift.

The grocery list feature shows how spec-first thinking paid off when building AI-powered functionality.

The challenge: Tastebook is intentionally not a recipe app. Most meals have no ingredient data. Takeout meals need no groceries at all. So the AI grocery feature had to work with incomplete information and degrade gracefully when there was nothing to work with.

I wrote a detailed feature spec through Claude Code that defined baseline (non-AI) behavior first, then layered premium AI features on top. Two AI capabilities made the premium tier:

• Generate Groceries: Given just a meal title, tags, and notes, Claude Haiku suggests 5-12 practical grocery items.
• Smart Tidy: One tap to merge duplicates ("scallions" + "green onions"), group items by shopping aisle, and normalize formatting.

The spec defined every edge case before a line of code was written. Takeout meals filtered from suggestions. Empty states for all-takeout weeks. What happens when a user removes a planned meal after groceries were generated.

The AI features needed to feel safe. Grocery apps live or die on whether users trust the list they're carrying into the store.

Every AI interaction follows a suggestions-not-answers pattern. When Claude Haiku generates groceries for "Mom's Lasagna," the results appear in a review sheet where users toggle items on or off before anything persists. Smart Tidy shows a categorized preview with an explicit "Apply" action and a snapshot-based undo banner after the fact.

Concrete guardrails in the implementation:

• No silent changes. Both features require explicit user initiation. Nothing runs in the background.
• No quantities or units. The prompt instructs Claude to omit measurements entirely, avoiding confident-sounding hallucinations like "2 cups flour" for a meal that might serve one person or ten.
• Clear AI labeling. Sparkle icons mark every AI entry point. Users always know when they're invoking AI vs. using baseline features.
• Undo everything. Smart Tidy captures a full snapshot before applying changes. One tap to revert.

Claude Code wasn't a coding assistant on this project. It operated as a small engineering team.

During the spec phase, I used Claude Code conversationally, treating it as a product collaborator that could challenge assumptions and structure decisions. During implementation, I delegated to specialized subagents from my playbook: a builder agent that reads project conventions before writing code, a code reviewer that audits changes against established patterns in isolation (so it catches issues the builder's context would gloss over), and a doc verifier that checks whether documentation still matches the implementation.

The key discipline is context isolation. A reviewer that didn't write the code catches different problems than the developer who just finished writing it. Each agent reads only the project conventions and the relevant code, without the implementation history that might bias its review.

My role throughout was the same as a tech lead running a team: setting direction, reviewing agent output, making judgment calls, and maintaining coherence across the full product surface. The agents handled volume. I handled taste.

Tastebook is a complete iOS app submitted to the App Store, built in under a week of active development. The feature set includes:

• Full-screen vertical meal browsing with randomized, non-repeating scroll
• Meal capture in under 10 seconds (photo, title, done)
• Weekly meal planning with "Made It" tracking
• Household sharing via CloudKit CKShare with multi-device conflict resolution
• Offline-first Core Data + CloudKit sync with HEIC image pipeline
• Baseline grocery lists with manual entry, copy-forward, and share/copy
• AI grocery generation and Smart Tidy as premium features (StoreKit 2 freemium)

The spec-to-code fidelity is the part I'd point to. Every user flow in the product spec has a corresponding implementation. Every edge case in the grocery spec (takeout filtering, orphaned items, all-takeout empty states) is handled. The feature spec's "Implementation Status" section reads like a checklist with every box marked [IMPLEMENTED].

That fidelity comes from the workflow, not from working faster. Specs written through AI conversation are already in a format that AI agents can execute against. The same document that captured the product decision ("AI outputs must be trustworthy: clearly labeled as suggestions, easy to accept/remove/edit") became the implementation constraint that shaped the review-before-persist pattern across every AI feature.