From Idea to App Spec: Building KitchenFlow with AI

The Problem

I wanted to build a GTK4/libadwaita recipe management app. Something like ComfyUI or n8n, but for cooking. Visual node graphs showing when to start each step, what equipment you need, how to sync multiple dishes.

I hit the classic problem: I had the vision, but not the blueprint.

Most tutorials jump straight to code. “Here’s how to make a GTK button.” They skip the messy middle part where you figure out what you’re building before you start building it.

This post documents the full process of using an AI agent to turn a fuzzy idea into a detailed, actionable spec. No fluff. Just the raw exchange and the resulting document.

The Starting Point

My initial prompt to the AI:

I’m going to try to build a gtk4 libadwaita recipe management app that is node based. I am going to try to walk users through the full process of building with opencode from within Gnome Builder. I want it to be a full end to end tutorial of how to build an app that the user has thought of live with the audience from the ground up.

As such, I want to show them the first step is coming up with a detailed product specification for their application. I would like to work with you to build mine out. I want to brainstorm a detailed product specification. The inspiration is systems like comfy ui or n8n but instead focused on recipe management for chefs of all types.

Can you help me plan this application including planning milestones what goals I should accomplish first and what other factors I should consider?

The AI asked 15 questions. Grouped into categories:

  1. Core Functionality (node types, recipe import, real-time execution)
  2. Technical Architecture (data model, language choice, Flatpak considerations)
  3. User Experience (target users, visual design, mobile support)
  4. Advanced Features (timing intelligence, scaling, API expansion)
  5. Constraints & Milestones (MVP scope, content strategy, differentiation)

This was the critical moment. Most people skip this part. They assume the AI will just know what they want. The AI can’t read minds. It needs constraints.

The Decision Process

I answered each question inline.

Easy decisions: Python. Graph viewer first, editor second. Home cooks initially. Flatpak for Flathub.

Tradeoffs required:

Node Input/Output: ComfyUI vs n8n

The AI laid out the comparison:

AspectComfyUI Stylen8n StyleKitchenFlow Decision
Data FlowExplicit ports, type-checkedImplicit, dependency-basedHybrid: Visual ports but semantic validation
ComplexityHigh learning curveLower barrierSimplified ports: Only show relevant connections
FlexibilityUnlimited connectionsLinear workflowsDAG with constraints: No cycles, max 3 inputs/outputs
Cooking ContextAbstract dataTask orchestrationTask orchestration with ingredient tracking

I chose semantic dependency tracking. Ingredients flow automatically. Equipment is explicit. Timing is automatic. Validation happens at runtime.

The AI challenged me: “Cooking is less about data transformation (ComfyUI) and more about resource coordination (n8n). The visual graph should communicate dependencies and timing, not data schemas.”

That reframed the whole design.

Visual Design: Technical vs Warm

ComfyUI uses a dark, technical aesthetic. This is a kitchen app. Should it feel like a server dashboard or a cookbook?

Warm kitchen aesthetic. Cream backgrounds, warm oranges/blues. Text instructions generated from the graph.

The Output: SPEC.md

After the Q&A, the AI generated a 40KB specification document with:

1. Executive Summary Core value proposition, design philosophy, convergence goals.

2. Technical Architecture

3. UI Specifications ASCII wireframes for:

4. Style Guide CSS variables for the warm kitchen aesthetic, node styling with animations.

5. Milestone Breakdown 10-week plan with weekly deliverables:

6. Testing Strategy Test pyramid (unit → integration → E2E), pytest examples, CI/CD configuration.

7. Flatpak Packaging Complete manifest, AppData metadata, desktop file.

8. Future Extensibility What gets built in Phase 2, 3, 4, 5 (editor, smart scheduling, professional features, mobile optimization).

9. Design Concerns & Mitigations Four major risks identified with specific mitigations:

10. Build Instructions Prerequisites, local setup, Flatpak build, testing commands.

11. Sample Recipe JSON Full working example of a roast chicken recipe as a DAG.

12. Text-Based Recipe Generation How the app converts graphs back to human-readable instructions.

What Made This Work

1. The AI Asked Questions First

Most AI interactions fail because the user dumps a vague prompt and expects magic. The AI reversed that: “Answer these 15 questions, then I’ll build the spec.”

That forced me to think through decisions I would have glossed over.

2. Tradeoffs Were Explicit

The AI didn’t just say “use this.” It showed the alternatives and why this choice fits this project.

Example: Node I/O design. It laid out ComfyUI vs n8n tradeoffs in a table, then recommended a hybrid approach with clear rationale.

3. Constraints Were Respected

I specified:

The AI didn’t try to convince me to use Rust or Electron or React Native. It worked within the constraints and optimized for them.

4. The Spec Was Actionable

This isn’t a vision document. It’s a build guide. Every section maps to code:

The milestone breakdown tells you exactly what to implement in week 1 vs week 5.

5. Testing Was Built In

The spec includes a complete testing strategy with example test code. This isn’t an afterthought. The graph layer is designed to be testable before the UI exists.

That’s critical for AI-assisted development. You can generate code, run tests, iterate. The tests validate that the AI didn’t introduce bugs.

What Happens Next

I’m making a video walking through the process live:

  1. Part 1 (this post): How I generated the spec with an AI agent
  2. Part 2: Using OpenCode inside GNOME Builder to scaffold the project
  3. Part 3: Implementing the graph layer, running tests, iterating
  4. Part 4: Building the UI, packaging as Flatpak, submitting to Flathub

The goal: show you don’t need to be a senior engineer to build complex apps.

How to Replicate This Process

If you want to build your own app with AI assistance:

Step 1: Write Your Initial Prompt

Don’t overthink it. Just describe what you want:

“I want to build [app type] that does [core function]. Inspired by [similar tools]. Target users are [audience]. I want to use [tech stack]. Help me plan milestones and consider factors I might miss.”

Step 2: Answer the AI’s Questions

The AI will ask clarifying questions. Answer them honestly. If you don’t know, say “I don’t know, what do you recommend?” The AI’s recommendations are based on patterns from thousands of projects.

Step 3: Review the Spec Critically

Don’t just accept it. Challenge it:

Iterate until it’s yours.

Step 4: Start Building

Use the spec as your guide. Implement one milestone at a time. Run tests. Fix failures. Repeat.

Step 5: Document the Process

Share what you learn. Knowledge compounds when you teach others.

The Files

SPEC.md - The 40KB technical specification (full document)

Raw Exchange Transcript - Complete conversation with AI agent (15 questions + all responses)

Both are open source. Both are free to use, modify, and learn from.

Final Thoughts

I’m a hobbyist who wants to build things. This process proved I don’t need to become a senior engineer first. I need to learn how to collaborate with AI tools effectively.

The spec took 15 minutes to generate. I would have spent 15 hours writing it alone, and it would have been worse.

AI-assisted development doesn’t write code for you. It helps you think through problems you didn’t know you had.

Build something.

This guide, the spec, and the raw AI exchange are all available for anyone to learn from, modify, and reuse. That’s the point of open source.