Source notes
RecipeFix
How this project works, the decisions behind it and its known limits. Ask quotes and cites these passages when it answers.
Notes reviewed 20 September 2026
Explore the projectProduct
Product
Keep the recipe. Change what does not work for you. RecipeFix helps people cook the food they actually want while working around ingredients, dietary preferences and nutrition targets. It adapts the ingredients and the method together instead of returning a list of unrelated substitutions.
The problem it solves
A substitution can change texture, cooking time, nutrition and even the identity of the dish. A tool that swaps words without reconsidering the recipe can leave a technically compliant but disappointing meal. Searching, adapting, shopping and remembering what was cooked also tend to happen in disconnected tools.
The experience
The current product loop is Find → Fix → Create when necessary → Save → Plan → Shop → Cook → Remember. Search results and saved recipes are assessed before a new recipe is generated. When a request would substantially change the dish, RecipeFix presents a trade-off rather than quietly calling the result the same recipe.
Availability
RecipeFix is publicly available on the web and on the App Store. The iOS app is a separate native wrapper around the web product, so a feature described here can reach the web before it reaches the App Store build.
Engineering
Backend and architecture
The React application uses React Router and TanStack Query over Supabase authentication and Postgres. Privileged adaptation and integration work lives in Deno Edge Functions; database policies protect user-owned records. Pure TypeScript modules express candidate fit and the Find/Fix/Create decision, while the client displays the canonical server feasibility verdict rather than recomputing it. The iOS product has a separate native-wrapper repository, released on its own schedule, so the web and native versions can temporarily differ. A move to an owned backend is documented in the repository; the architecture described here is the Supabase one.
Technology by responsibility
Client: React, TypeScript, Vite, TanStack Query. Backend: Supabase, PostgreSQL, Deno Edge Functions. Integration: Recipe extraction, AI adaptation, MCP tools.
Data, trust and failure behavior
Fit classification and recipe provenance are distinct: an external recipe is not automatically good, and a saved recipe is not automatically cooked. Missing nutrition or feasibility evidence stays unknown rather than being filled in. Recording a cook writes a history event and then updates the recipe's recency; those two writes are not one atomic transaction, and the MCP path retries with a reduced payload after an insert error, so exactly-once cook recording is not claimed.
Find before generating
The decision module ranks known cookbook and external candidates, prefers a fitting recipe, considers an adaptation next, and creates only when neither is suitable. Unknown evidence is not promoted to a positive fit.
Explain feasibility
The shared verdict distinguishes a straightforward adaptation from a major transformation, conflicting goals, insufficient evidence and a request the system should not claim it can satisfy.
Remember actual cooking
Cook sessions record a completed cook separately from saving a recipe. Servings, plan association, source, notes and a later rating belong to that event, including an unsaved recipe.
Connect kitchen workflows
The application joins a cookbook, planning and cooking history. The MCP mark-recipe-cooked tool writes a cook-history event as well as updating the recipe recency field.
Decisions
Preserving the dish while changing it
A canonical feasibility result is shared across discovery and adaptation surfaces. The product can recommend a similar dish or ask the person to prioritize a goal instead of forcing every request through conversion. Trade-off: An honest stop or clarification is less immediately gratifying than always returning a recipe; it avoids disguising an entirely different dish as a small fix.
Separating intent from outcomes
The saved recipe library and completed-cook diary represent different facts. Later feedback amends a cook rather than deliberately treating a rating as another cook. Trade-off: The browser and Deno writers have separate adapters and a denormalized recency field. That makes consistent error handling and retries a cross-surface concern rather than a property of either adapter alone.
Limits
Known limits
Being on the App Store does not mean every newer feature is already in the iOS build. RecipeFix does not claim that every recipe, dietary requirement or allergy can be handled safely, and it makes no clinical, allergy-safety, accuracy or customer-volume claim.
Questions Ask answers from here
Why does RecipeFix find before it creates?
An existing fitting recipe can answer the request without paying for a fresh generation. A close candidate can be adapted. Creating is the fallback, not the automatic first step.
Does saving a recipe mean it was cooked?
No. Saving belongs to the cookbook; completed cooks belong to cook_sessions. That distinction supports honest history and personalization.
How does RecipeFix avoid ruining a dish?
It evaluates feasibility and dish identity, coordinates ingredient and method changes, and can stop or offer a different route. These safeguards do not guarantee a successful meal under every condition.