Planning with an AI co-author

Whenever I build new products with Claude Code I generally follow the same process: plan/ideate with Claude -> create architecture document -> craft a PRD -> map dependencies and create roadmap -> build -> refine. This whole process isn't "generate a spec and paste it in." It's a genuine back-and-forth: I push back on decisions, Claude surfaces tradeoffs, and we land somewhere more considered than either of us would have arrived at alone.

With this project the process also revealed real tension in building an AI-native product: when your planning tool is the same as your implementation tool, it's easy to end up with a plan that defaults to AI everywhere. Not because AI is the right answer in each case, but because AI is what's top of mind.

That's exactly what happened with the mood and scene feature. The original plan called for Claude to generate a fresh set of ingredients every time a user entered a prompt. Novel, contextual, impressive-sounding. But also slow, expensive, and inconsistent. Two users entering similar prompts could get meaningfully different results for no good reason.

I caught it, but only after I'd committed to the feature design. Reworking it mid-build was the inflection point that shaped the rest of the project.

The AI Touchpoint Analysis

After rethinking the mood feature, I went back through the entire product and audited every place I'd planned to make a Claude call. I started asking a harder question than "can AI do this?" The question was: does AI need to be here, and if so, in what form?

That line of thinking became what I now call the AI Touchpoint Analysis. For each feature, I evaluated it across a few dimensions:

• Uniqueness: does this genuinely require language understanding, or could a rule-based or static solution do the same job?

• Latency tolerance: is the user waiting on this call, or can it happen in the background?

• Stakes of failure: if the output is wrong or inconsistent, does the experience break, or is it recoverable?

• Frequency: how often does this fire? A call that fires on every ingredient add compounds quickly.

• Alternatives: is there a faster, simpler, or more predictable way to achieve the same outcome? Static data, rule-based logic, and pre-computation should always be considered before defaulting to a live AI call.

Running every AI touchpoint through that filter produced a cleaner, more defensible architecture. The key distinction that emerged was between AI that runs offline, enriching static data at build time, and AI that runs online in the user's hot path.

Mood and scene discovery was the clearest win from this thinking. Instead of generating ingredients fresh on each prompt, I built a curated library of 100+ ingredients and had the mood prompt produce intelligent filters over that library. The user gets a contextual, editorial result that feels generated, but the underlying data is stable and instant. Claude's work happens upstream and the runtime experience is fast and consistent.

Ingredient sensory data followed the same logic. Rather than calling Claude every time a user opened an ingredient detail panel, I used AI to enrich the seed data upfront, generating taste profiles, aroma notes, and natural pairings for each ingredient in the library. Static at runtime, AI-powered at build time.

The pizza-aware analysis is where I kept Claude in the hot path, but deliberately. Comparing a specific ingredient against the actual pizza a chef is currently building is an inherently contextual problem. No static lookup can do that. The latency is real and the user knows they're waiting on something meaningful. That's the right place for a live API call.

The framework didn't eliminate AI from the product. It clarified where AI earns its place.

Building solo, with AI in the loop

The development process was split across two tools. Design and product decisions happened here in Claude.ai, where I could think through problems conversationally. Implementation happened in Claude Code, where I'd provide context through a /Context directory containing the PRD, architecture docs, and a CLAUDE.md file, so the coding environment had everything it needed before scaffolding anything.

This separation of concerns turned out to be important. The conversational planning mode and the implementation mode serve different cognitive jobs, and keeping them distinct helped me stay clearer about which mode I was in. When I blurred the line, trying to make product decisions inside a coding session or trying to get implementation specifics out of a planning conversation, things got muddier.

The build itself followed a phased roadmap, working from data integrity through to deployment. The ingredient seed file, the API architecture, the prompt engineering, the UI components, and the harmony scoring system each got their own phase. Shipping incrementally and being willing to revisit earlier decisions when later phases surfaced problems was what made the solo build sustainable.

Prompt engineering as a design problem

Getting Claude to return reliable, structured JSON across four different prompt types (mood extraction, ingredient pairing, harmony scoring, and conflict detection) turned out to be a more deliberate design problem than I expected. The outputs feed directly into UI components, which means a malformed response isn't just a backend error, it's a broken interface.

The solution was treating each prompt like a component with a contract: a clearly specified output schema, explicit instructions on format, and defensive parsing on the client side that handled edge cases gracefully. The API timeout also had to be tuned twice during the build. Real Sonnet latency was higher than I'd planned for, and a timeout that's too tight turns a slow response into a confusing failure.

This is the kind of thing that only shows up when you're building, not planning.