RecipeLab

RecipeLab helps food creators develop better recipes through Versions—preserving what changed, what happened, and what to try next instead of overwriting the learning between cooking attempts.

Comment

Inspiration

I run a food YouTube channel, Meals with Rui, and develop recipes through repeated cooking attempts. My working recipes were scattered across Apple Notes, handwritten notebooks, photos, and memory. I could often remember changing something, but not exactly what changed, why I changed it, or how that decision affected the taste, texture, color, and camera-readiness of the dish.

Most recipe apps focus on collecting, importing, or publishing finished recipes. My problem happened earlier: during recipe development, when every attempt creates new evidence.

That led to RecipeLab’s core idea:

A Recipe is the dish. Every cooking attempt is a Version.

Instead of overwriting yesterday’s recipe, RecipeLab preserves the history between attempts so creators can understand what changed, what happened, and what to try next.

What it does

RecipeLab is a private mobile workspace for food creators and serious cooks who develop the same dish across multiple attempts.

Users can:

  • create a Recipe and its first editable Version;
  • organize ingredients and steps into sections;
  • record Result Notes, Next Adjustment, photos, and key cooking variables;
  • create a new Version from scratch or duplicate a previous attempt;
  • compare two Versions side by side;
  • preserve both Drafts and the current best-so-far Final;
  • copy a clean recipe when it is ready to use elsewhere;
  • organize Recipes with categories, tags, search, filters, and grid or list views.

The core experience is not about declaring an automatic winner. RecipeLab presents the evidence neutrally so the creator can make the decision.

How I built it

RecipeLab is an Expo and React Native mobile application with a Supabase backend for authentication, Postgres data, atomic save operations, and image storage. The application also includes an in-memory demo service that follows the same Recipe and Version boundaries, allowing judges to explore the product without creating an account or configuring Supabase.

I built the product through an extended collaboration with Codex and ChatGPT. I retained ownership of the audience, product model, scope, visual direction, tradeoffs, and acceptance decisions. Codex helped turn those decisions into working software, diagnose implementation problems, generate design alternatives, edit local files, run tests, and verify the application in iOS Simulator.

During OpenAI Build Week, GPT-5.6 Sol became available directly inside Codex. Previously, visual iteration required me to send Expo screenshots to ChatGPT on the web, request a critique, and manually transfer the resulting instructions back to Codex. With GPT-5.6 in Codex, the complete loop could happen in one environment:

  1. open the real app in Simulator;
  2. capture and review the interface;
  3. diagnose the underlying hierarchy or workflow problem;
  4. generate multiple visual directions;
  5. let me select and refine the direction;
  6. implement it in the local codebase;
  7. return to Simulator for visual and interaction QA.

That continuous design-to-implementation loop was the largest acceleration GPT-5.6 brought to the project.

Challenges I ran into

The hardest challenge was protecting a simple product model while building a fairly deep application. Ingredients, steps, notes, photos, sources, and variables must belong to a specific Version without being accidentally flattened onto the Recipe.

Save reliability was another major challenge. A Version can span multiple tables and uploaded images, so partially saving an edit would damage the development record. I introduced an explicit save boundary and atomic Supabase operations so Save commits the complete Version state while Discard commits nothing.

The UI was also difficult. Early versions felt like an engineering form rather than a calm kitchen tool. The app was functional, but I was dissatisfied enough with the interface that I considered stopping the project. GPT-5.6 made it practical to audit the actual screens, identify system-level problems, compare mockups before changing code, and apply a consistent mobile design foundation.

Finally, I had to resist attractive but distracting features. Social feeds, AI recipe scanning and import, grocery lists, and meal planning could make the app appear larger, but none would test the core question: does preserving Version history help a creator make a better next attempt?

Accomplishments that I’m proud of

I am proud that RecipeLab is a working, coherent mobile MVP rather than a collection of disconnected demo screens.

The product now supports an end-to-end loop:

Create → Cook → Capture → Adjust → Compare → Final

Other accomplishments include:

  • a distinctive Recipe-to-Version information model;
  • side-by-side comparison with equal visual weight;
  • reliable multi-table Version saves;
  • a polished iOS-first interface designed for kitchen use;
  • a no-account demo with realistic sample Recipes;
  • a public Product Brief and detailed User Guide;
  • 70 committed test files covering product, interaction, layout, and regression contracts;
  • clear documentation distinguishing the pre-existing product from the GPT-5.6 work completed during Build Week.

What I learned

I learned that AI-assisted product development works best when the human is not reduced to writing prompts or transferring output between tools. My highest-value contribution was defining the problem, maintaining product coherence, exercising taste, rejecting weak directions, and deciding what evidence was sufficient for acceptance.

I also learned that visual quality depends on a review loop, not a single generation. The strongest results came from examining the real interface, diagnosing why it felt wrong, comparing genuinely different alternatives, implementing one direction, and verifying the exact result.

Most importantly, I learned that a finished recipe and a useful development record are different products. A finished recipe tells someone what to cook. A Version history explains what was learned and supports the next decision.

What’s next for RecipeLab

RecipeLab currently proves functional delivery and firsthand utility in my own recipe-development workflow. It does not yet prove broad market demand, and I do not want to present founder use as external validation.

The next step is a structured pilot with 5–8 food creators. Each participant will develop a real dish across two attempts so I can observe whether they:

  • save a meaningful first Version;
  • reopen or compare it before creating Version 2;
  • identify stored evidence that influenced the next change;
  • trust RecipeLab to preserve their work;
  • begin another learning loop without prompting.

I also plan to introduce RecipeLab through my YouTube channel and relevant food-creator and creative-coding communities. Those channels will support discovery, but the primary success signal will not be views or sign-ups. It will be whether saved evidence changes a creator’s next cooking decision.

Built With

Share this project:

Updates