QuickPan

People living alone, on tight budgets, or just exhausted at the end of the day face the same situation. Food in the fridge, no idea what to make with it. So they order out, or they don't eat properly. The problem isn't missing ingredients. It's missing ideas.

One framing decision shaped everything that followed: QuickPan is a tool the user operates, not a conversation they are having. That single distinction determined the layout, the input behaviour, and how results are displayed. Everything traces back to it.

The idle state is a single contained surface. The input field sits at the top, the filters sit inside the same container, and as you add ingredients they appear as chips below. Everything the user needs to set up their request lives in one place before they hit generate.

The chip pattern was the right call over a plain text field or comma-separated list. Chips are discrete, scannable, and individually removable. The input stays clean regardless of how many ingredients are added. The filters sit inside the same container deliberately, keeping the controls grouped so the user configures everything in one interaction before generating.

Two filters cover everything a user needs to configure before generating.

Effort handles how much time and energy they want to spend, from a 15 minute lazy cook to going all in on something serious.

Taste handles cuisine direction, from familiar local meals detected automatically through their location to globally inspired dishes they likely haven't tried before.

This is what makes QuickPan a tool rather than a chatbot. The AI doesn't return a wall of text. It returns structured visual components. Each card surfaces everything the user needs to make a cooking decision: the recipe name, time, effort level, taste profile, ingredient match, and missing items, all readable before expanding.

Effort level is shown through color coded bar indicators rather than text labels. One green bar means Lazy. Three red bars means Serious. You read it before you consciously process it.

Three cards, equal visual weight. No featured result, no number one pick. The product doesn't decide which recipe is best. It gives options and gets out of the way. The user decides.

Building QuickPan solo meant every layer was mine to own. No engineer to hand off to, no back and forth on implementation. The build had to be as deliberate as the design, and that required a clear methodology for working with AI as an implementation partner rather than just a tool you prompt reactively.

The process had a specific sequence. The PRD went into the codebase first. The design system followed. Then components were built in isolation before a single page was assembled. That order wasn't arbitrary. Each step created the foundation the next one depended on. By the time the pages were assembled, everything was already made to fit together.

Before a component was touched, the PRD was extracted into a markdown file and added directly to the project as a live file. Not a document sitting in a separate tab — an actual file inside the codebase.

Claude has no memory between sessions. Loading the PRD at the start of every build session kept the AI grounded in the scope, the constraints, and the decisions already made. It also kept me grounded. Scope creep in an AI assisted build doesn't just come from the AI. It comes from you too. The PRD is what pulls you back.

With the PRD grounding the build, the next step was giving the AI everything it needed to construct the visual foundation. Colour tokens, typography scale, spacing, and corner radius were all extracted from Figma into a markdown file first, not directly into CSS.

That sequence matters. The markdown checkpoint catches naming inconsistencies before they land in the codebase. A formatting issue across some tokens was caught and fixed at that stage. From the clean markdown, the CSS variables file and Tailwind config were generated. Same values, same naming structure, no manual translation, no drift.

Every token defined in Figma became a real variable in the codebase. As a designer, handoff has always been where control ends. This workflow removed that gap entirely.

Every component was built independently before a single page was assembled. The Figma MCP extracted the structure and properties of each component directly from the design file. Because everything in Figma was built with auto layout, the responsive structure translated cleanly into flexbox in code. How you build in Figma directly affects how clean the output is.

Once all components were built, a dedicated showcase page was generated to preview every component and every variant in one place before connecting anything to real data. That step caught something immediately. The ingredient input didn't build correctly on the first pass. Because it was isolated, it was fixed before anything else was built on top of it. If it had been caught inside a fully assembled page, fixing it would have meant untangling a much bigger mess.

With the PRD grounding the context, the design system extracted, and every component verified, the pages were assembled. Everything worked on the first attempt. That wasn't luck. It was the compounding return of doing the work in the right order. The PRD kept the build focused. The design system gave accurate values. The components were verified before composition. By the time assembly started, everything was already made to fit together.

QuickPan is live and deployed. It went from problem to a working URL across every layer: strategy, design, and production build, solo.

The tools exist. The process works. The gap between designer and builder is smaller than most designers think.