# Recipe Site > A digital recipe book that replaces handwritten collections with powerful search, filtering, and kitchen-friendly features - HTML version: https://robbiepalmer.me/projects/recipe-site - Status: live - Started: 2026-02-14 - Source code: https://github.com/Robbie-Palmer/personal-site - Live demo: https://robbiepalmer.me/recipes - Technologies: GitHub, React, Next.js, Mise, Tailwind CSS, Turbopack, pnpm, Vitest, CodeRabbit, Terraform, Cloudflare Pages, Claude Code, Husky, GitHub Actions, Terraform Cloud, GitHub Secrets, shadcn/ui, Fuse.js, Renovate, Cloudflare DNS, Cloudflare Images, Cloudflare Terraform Provider, CodeQL, TypeScript, Shortcut, CLA Assistant, PostHog, DVC, cooklang-rs, Better Auth, Cloudflare Workers, Neon, Hono, Drizzle, Hyperdrive, Google OAuth, GitHub OAuth, Google Gemini, Greptile, Codex, Qodo, Trivy, SonarQube, zizmor, actionlint, OpenTelemetry # Vision A digital recipe book that replaces our handwritten collection with a searchable, editable, shareable platform that works better in every scenario — especially the kitchen. We have used a handwritten recipe book for years. It has genuine UX strengths: no lock screens, no risk of water or food damage to an expensive device, easy to prop open on a counter. But the limitations are severe enough that we lose recipes, avoid making changes, and work around the format constantly. A digital version should preserve what works about the physical book (glanceable, kitchen-friendly) while eliminating everything that doesn't. # Problem Statement A handwritten recipe book creates friction at every stage of the recipe lifecycle: **Collecting recipes is inconvenient.** Adding a recipe requires being physically with the book and having time to transcribe by hand. Recipes discovered online, from friends, or from social media (saved Instagram videos, bookmarked websites, Facebook posts) pile up across different platforms and many are lost. The barrier to entry is too high for casual additions. **Editing is destructive.** Adapting a recipe often means destroying the original page and rewriting entirely — there's no room for new instructions, and scoring out old text makes the page illegible. This discourages experimentation. Recipes need multiple attempts before settling on a final form, but the cost of each iteration is a full page rewrite. **Finding recipes is slow.** Locating a specific recipe means flicking through every page. There's no search, no filtering by cuisine or cooking time, no way to answer "what can I make in under 30 minutes?" without reading every entry. **Shopping is manual transcription.** To shop for a recipe, we manually copy ingredients from the book into a notes app on our phones to use as a checklist in the supermarket. This is tedious, error-prone, and completely unnecessary with digital data. **Portioning is error-prone.** Scaling recipes up or down requires mentally converting every ingredient amount. When ingredients appear mid-recipe in the instructions, it's easy to forget to convert them and use the amount on the page — resulting in failed dishes. The page should display the truth of what you want, not require mental arithmetic. **Unit confusion.** We collect recipes from different countries with different measurement systems — cups, Fahrenheit, metric. These often don't match our measuring utensils and cause confusion during cooking. **The book can be lost.** A single physical copy with no backup. If it's lost, damaged, or destroyed, years of collected recipes are gone. These aren't just our problems. The [competitor analysis](#competitor-analysis) below reveals a fragmented market where no product combines AI-powered recipe capture with a polished cooking experience — and accelerator backing for apps like Flavorish validates that the gap is widely felt. We're building for ourselves first, but the pain points are universal. # User Stories **For the cooks (us):** * I want to search and filter recipes by cuisine, ingredient, or cooking time, so I can quickly decide what to make without flicking through every page * I want to adjust portion sizes and see all ingredient quantities update automatically, so I never miscalculate when scaling a recipe * I want to convert between measurement units (metric, imperial, cups), so recipes from any country work with my utensils * I want a cooking mode with large text and step-by-step progression, so I can follow a recipe in the kitchen without fiddling with a device * I want inline timers in recipe steps, so I don't need to context-switch to a separate timer app or shout at a voice assistant * I want to save recipes as drafts without worrying about perfection, so I actually capture recipes when I find them instead of losing them * I want to edit recipes non-destructively, so I can iterate and improve without losing the original * I want to generate shopping lists from one or more recipes, so I never have to manually transcribe ingredients again * I want to access my recipes from any device, anywhere, so I'm not dependent on being physically near a book **For friends and family:** * I want to browse their recipes on a shared website, so I can try dishes they've recommended * I want to share a link to a specific recipe, so I can send it to someone who asks "how do you make that?" **For future users (with accounts):** * I want to add recommended recipes to my own collection, so I can personalize and adapt them * I want to favorite and rank recipes, so my most-loved dishes are easy to find * I want to track what I've cooked and when, so I can identify popular vs neglected recipes and avoid repeating meals too frequently # Features ## Core (MVP) ### Recipe Browsing & Discovery * **Full-text fuzzy search** across recipe titles, descriptions, cuisines, and ingredients * **Multi-filter system** — filter by cuisine, ingredient, prep time, total cooking time * **Recipe cards** with images, cuisine badges, and time estimates ### Recipe Detail & Cooking * **Serving size adjustment** — increase or decrease portions with all ingredient quantities scaling automatically * **Unit conversion** — global preference toggle (e.g., "show everything in metric") and per-ingredient inline conversion (tap to toggle between metric/imperial/cups) * **Structured ingredients** — grouped by category (e.g., "Spice Mix", "Sauce"), with quantities, units, and preparation notes * **Step-by-step instructions** — numbered, clear, scannable ### Content Management * **Draft status** — `draft | published` workflow so recipes can be captured immediately and refined later * **Attribution** — track recipe origin (e.g., "Grandma's book", "BBC Good Food", "Instagram @chef") *Current implementation: Recipes are structured content files validated at build time and kept in version control. That gives us fast iteration, error checking, and clear history today without locking the long-term content model prematurely (see [Architecture](#architecture)).* ## Phase 2: Kitchen Experience ### Cooking Mode A simplified, large-font, step-by-step view optimized for kitchen use. One step at a time with large tap targets to move forward and back. Designed for messy hands and quick glances — the digital equivalent of a propped-open book, but better. ### Inline Timers Recipe steps that mention durations (e.g., "simmer for 20 minutes") get a tap-to-start countdown timer. Multiple timers can run simultaneously for complex recipes. Eliminates the need to context-switch to a separate app or shout at a voice assistant. ### Offline Access & Installability Recipes should remain available with poor signal, especially in kitchens and supermarkets. If the web experience benefits from it, home-screen installation should be possible without requiring native app distribution. ## Phase 3: Shopping & Meal Planning ### Smart Shopping Lists * Generate a shopping list from a single recipe or aggregate across multiple recipes for meal planning * Deduplicate and merge ingredients (e.g., two recipes both needing onions combines into one entry) * Checkbox interface for ticking off items while shopping * Works offline for use in supermarkets with poor signal ### Meal Planning Calendar * Drag recipes onto days of the week * Auto-generate aggregated shopping lists for the planned period * Visual overview of the week's meals ## Phase 4: Recipe Ingestion Pipeline > Import tooling is being explored in parallel with Phases 2-3, not sequentially after them. > The phasing here reflects when ingestion features ship to users, not when the underlying > work starts. ### Photo-to-Recipe Extract structured recipe data from images — handwritten recipe pages, printed cookbook photos, recipe cards. Enables batch digitization of existing physical recipe collections and low-friction capture of any recipe image. ### Website Import Import recipes from URLs when sites already expose useful structure, with a fallback path for messier pages. The goal is one-click capture rather than manual transcription. ### Social Media Import Extract recipes from Instagram posts/reels, TikTok videos, YouTube cooking videos, and Facebook posts. This addresses the core pain point of recipes scattered across platforms and is likely the hardest ingestion problem, but also one of the most differentiated. ### Review Workflow Imported recipes should enter a review flow before becoming part of the collection. The exact mechanism can evolve; the important point is preserving quality control and editorial oversight. ### Portable Recipe Data Recipes should remain exportable in a broadly understood structured format. That supports SEO, interoperability, and long-term portability without turning the collection into a closed system. ## Phase 5: Personalization & Social ### User Accounts Accounts for personalization, not privacy — all recipes remain publicly accessible. Accounts enable: * **Favorites** — bookmark recipes for quick access * **Personal rankings** — rate and sort by preference * **Cooking log** — tap to record what was cooked and when * **Recipe recommendations** — suggest recipes to friends, who can add them to "their recipe book" * **Personalized variations** — fork a recipe with edits, maintaining lineage to the original ### Recipe Reviews & Collaboration Multi-user comments and adaptations on shared recipes. The complexity is modelling reviews on forked recipe variants — when users personalise a base recipe, the review system needs to handle both the original and its derivatives. A [Cooklang blog post](https://cooklang.org/blog/09-cooklang-vs-paprika-vs-mealie/) describes a family in Italy using Mealie to preserve a 100-year-old recipe collection across three generations who contribute, comment, and adapt recipes — this multi-generational collaboration model is a direct reference for how this should work. ### Usage Analytics * Identify popular vs rarely-cooked recipes * Sort by "haven't made in a while" to encourage variety * Track cooking frequency over time ## Phase 6: Nutrition & Intelligence ### Nutritional Analysis Structured digital ingredient data enables: * Per-recipe nutritional breakdown (calories, macros, micronutrients) * Dietary pattern analysis — what ingredients appear most, what gaps exist * Cooking log integration — what nutrients were consumed over time, similar to aspects of Zoe but with different emphasis (recipe-centric rather than food-logging-centric) ### Portion Adjustment Memory Remember the last portion size used per recipe — if the pasta bake is always made for 6, default to 6 instead of the base recipe's 4. ## Future Ideas ### "What Can I Make?" Enter ingredients on hand, find matching recipes. The ingredient graph already supports reverse lookups — this is primarily a UI feature. Photo-based pantry scanning (Honeydew's "Pantry Mode") is [out of scope](#out-of-scope) due to reliability concerns — this will be manual input only. Cooklang's CLI already implements this pattern (pantry management with recipe matching) and could serve as a reference. ### Seasonal Suggestions Tag ingredients as seasonal, surface relevant recipes by time of year. ### Voice / Hands-Free Navigation Web Speech API for voice-controlled step navigation during cooking mode. Eliminates the need to touch the screen with messy hands — directly preserving the physical book's "no fiddling" advantage. Requires cooking mode (Phase 2) as a prerequisite. ### Printed Recipe Book Partner with a hardback book printing company to let users print their own physical recipe book from their account as a gift. Emphasis on this being a novelty souvenir/gift — a complement to the digital experience, not a replacement for it. # Why Digital Beats Physical | Dimension | Physical Book | Recipe Site | | ------------------ | -------------------------------------------- | ---------------------------------------------- | | **Access** | Must be near the book | Any device, anywhere | | **Search** | Flick through every page | Instant full-text search | | **Filter** | Read every recipe's details | One-click by cuisine, time, ingredient | | **Edit** | Destructive — rewrite entire page | Non-destructive — full version history | | **Share** | Physically hand over the book | Send a link | | **Backup** | Single copy, can be lost | Git + Cloudflare artifacts | | **Shopping** | Manual transcription to phone | Auto-generated checklist | | **Portioning** | Mental arithmetic, easy to forget mid-recipe | Click a button, page shows the truth | | **Units** | Whatever the source used | Converted to your preference | | **Adding recipes** | Must be with book, manual handwriting | Paste, import, or photograph from anywhere | | **Kitchen UX** | Easy to prop open, no lock screen | Cooking mode: large text, step-by-step, timers | # What This Preserves From the Physical Book The physical book isn't all bad. The recipe site should preserve its strengths: * **Glanceability** — cooking mode replicates the "propped open book" experience with large, readable text * **No fiddling** — large tap targets, no tiny buttons, no accidental navigation * **Resilience** — PWA works offline; no "phone died mid-recipe" failure mode * **Tangibility** — the printed recipe book feature lets users create physical artifacts when the occasion calls for it # Product Design The product has been designed end-to-end as a mid-fidelity prototype — every surface, in both desktop and mobile, rendered in a warm "paper and handwriting" visual language (a soft paper palette with Caveat, Kalam, and JetBrains Mono type) that deliberately evokes the physical recipe book this replaces. It spans 17 surfaces: the recipe box and recipe read/cook views, scan/import, the kitchen (pantry + freezer), shopping and meal planning, sharing, cookbooks, a public profile, a profile-wide diet, a full shared-household system, recipe lineage/provenance, a cook log, the logged-out home and discover feed, onboarding, a recommendations inbox, notifications, and a settings hub. Much of it is interactive — cooking-mode timers run live, and a "tweaks" panel re-casts household size, diet model, and activity density across the artboards. This is a design exploration of the full vision above, not a commitment to build all of it — it exists to pressure-test the ideas and seed the backlog. Breaking it into prioritised epics is the next step. *(Interactive DesignEmbed component — view it on the HTML page)* The prototype above is a self-contained build; the editable design source (tokens, shared components, and one file per screen) is vendored alongside this document under [`designs/`](https://github.com/Robbie-Palmer/personal-site/tree/main/ui/content/projects/recipe-site/designs). # Competitor Analysis The recipe app market is fragmented. No single product does everything well, and most users cobble together 2-3 tools. As the Cooklang team [put it](https://cooklang.org/blog/09-cooklang-vs-paprika-vs-mealie/): "every step between 'I want to make that' and 'I'm cooking' is a chance to order takeout instead." The best cooking experiences are locked to Apple's ecosystem. The 2024-2026 wave of AI-powered import apps can capture recipes from anywhere but lack kitchen UX. The self-hosted tools have the right data philosophy but no polish. Nobody combines a great cooking experience with intelligent recipe ingestion on a platform that enables rapid iteration. There's external validation that this space has legs: Flavorish has secured backing from Google Cloud for Startups, YSpace, and Treefrog Accelerator — investors see a gap worth funding in AI-powered recipe management. But even the funded competitors are solving only half the problem (capture without kitchen UX), leaving the full-stack opportunity open. ## Market Landscape | Segment | Examples | Core focus | | ----------------------------- | -------------------------------------------------- | ---------------------------------------------- | | **Recipe managers** | Paprika, Crouton, Mela, Copy Me That, AnyList | Store, organise, and cook your own collection | | **Self-hosted / open-source** | Mealie, Tandoor, RecipeSage, Nextcloud Cookbook | Privacy, data ownership, developer audience | | **AI-powered capture** | Flavorish, Honeydew, Recify, Recipe One, Preplo | Import from social media, photos, URLs with AI | | **Meal planning / diet** | Ollie, Zoe, Mealime, Samsung Food | Weekly plans, grocery delivery, nutrition | | **Editorial platforms** | NYT Cooking, BBC Good Food, AllRecipes, Epicurious | Discovery, community reviews, curated content | We span segments 1, 2, and 3 — personal library, open-source data ownership, and AI-powered capture. An ML pipeline for photo-to-recipe extraction is scaffolded (`ml-pipelines/recipe-parsing/` — DVC stages, evaluation framework, and ground-truth dataset built; model in development). The roadmap extends into meal planning and nutrition. The editorial platforms and pure diet apps are adjacent — they solve different problems for different audiences. ## Key Competitors **[Paprika Recipe Manager 3](https://www.paprikaapp.com/)** — The incumbent. iOS, Android, Mac, Windows (one-time \~$5 per platform). Mature feature set: built-in web browser for recipe capture, auto-detected timers, full-screen cook mode, ingredient scaling, offline access. But no web version, dated UI, and per-platform purchase model is annoying. ([2026 review](https://flavor365.com/paprika-3-recipe-manager-our-honest-2026-review/)) **[Crouton](https://crouton.app/)** — Best-in-class cooking UX. Apple Design Award winner. One step at a time with large font, highlights ingredients in the current step, wink-to-advance navigation, multi-recipe cooking mode. Beautiful design. But Apple-only (iOS/macOS), $3 one-time, no web, no Android. ([MacStories review](https://www.macstories.net/reviews/crouton-review-an-elegant-modern-recipe-manager-and-cooking-aid/)) **[Mealie](https://mealie.io/)** — Self-hosted, open source (Vue + Python), REST API, schema.org Recipe format, ML-powered ingredient parsing. Multi-user with granular permissions and comment threads — the Cooklang blog [describes](https://cooklang.org/blog/09-cooklang-vs-paprika-vs-mealie/) a family in Italy using Mealie to preserve a 100-year-old recipe collection across three generations who contribute, comment, and adapt recipes. This multi-generational collaboration model is directly relevant to our recipe forking and personalisation roadmap (Phase 5). But zero kitchen UX investment — no cooking mode, no timers, no wake lock, no PWA. Shows the gap between "recipe database" and "cooking tool." ([GitHub](https://github.com/mealie-recipes/mealie)) **[RecipeSage](https://recipesage.com/)** — Open source, web-based, with meal planning, shopping lists, and fuzzy search with synonym mapping. Notable for being one of the few apps that [scales instruction text quantities](https://docs.recipesage.com/docs/tutorials/recipes/edit-recipe/) using curly-brace markup — though it requires manual annotation. **[Recify](https://www.recify.app/)** — AI import from YouTube, Instagram, TikTok, Pinterest, and blogs. Distraction-free cooking mode with swipe navigation, voice commands, timers, and screen wake lock. 4.9/5 app store rating. But critical limitations: recipes are saved to device only with no cloud sync — meaning a lost or replaced phone means losing your entire collection. No sharing or social features. Only 6 free AI imports, then requires a subscription (pricing unclear — reports range from $4.99/week to $5.99/month). Native app only (iOS/Android), no web version. Combines AI capture with cooking UX on mobile, but the device-only storage is a dealbreaker for anyone building a long-term recipe collection. **[Flavorish](https://www.flavorish.ai/)** — The most credible AI-import-first competitor, and notable for its accelerator backing: [Google Cloud for Startups](https://cloud.google.com/startup), [YSpace](https://yspace.yorku.ca/) (York University), and [Treefrog Accelerator](https://treefrog.com/) — validating investor interest in the recipe app space. Toronto-based, 1M+ recipes saved, 4.7+ stars. Imports from Instagram, TikTok, YouTube, Facebook, and photos of handwritten recipes. Grocery lists by aisle, serving scaling, cross-platform (iOS, Android, web). Free with unlimited storage; Premium $4.99/month removes AI import limits. "No ads. No data-selling." But no cooking mode — strong on capture, weak on the kitchen experience. **[Honeydew](https://honeydewcook.com/)** — AI extraction from social media and websites, AI meal planner, family sharing (up to 6 members), Instacart integration, works offline, metric/imperial support. Free with 10 AI imports/month; Plus $4-7/month for unlimited. No cooking mode. "Pantry Mode" lets you photograph your pantry for recipe suggestions — an interesting concept, though the reliability of photo-based pantry recognition is questionable. **[Copy Me That](https://www.copymethat.com/)** — The closest to a web-based personal recipe manager. iOS, Android, and web. Free for 40 recipes, $1/month unlimited. Web clipper, meal planner, shopping list sorted by aisle. But minimal cooking experience — no true step-by-step mode, no timers, dated UI. **[Cooklang](https://cooklang.org/)** — The closest philosophical match and a potential architectural building block. We share many of the same pain points and motivations — their [comparison post](https://cooklang.org/blog/09-cooklang-vs-paprika-vs-mealie/) articulates the same friction we identified with physical recipe books, and their conclusion — "the best recipe manager isn't the one with the most features, it's the one that removes barriers between you and cooking" — aligns directly with our building philosophy. Recipes are plain-text `.cook` files stored in git, with inline annotations for ingredients (`@flour{200%g}`), cookware (`#pot{}`), and timers (`~{25%minutes}`). The core [`cooklang-rs`](https://github.com/cooklang/cooklang-rs) Rust crate (MIT licensed, actively maintained) provides a clean parse → scale → convert pipeline with WASM/TypeScript bindings, meaning it can run in-browser. The [CLI](https://github.com/cooklang/cookcli) (Rust/Axum) includes a local web server, shopping list generation with ingredient aggregation across recipes, pantry management (find recipes makeable from what you have), AI-powered import from URLs using multiple providers (OpenAI, Claude, Gemini, Ollama), and full-text search. The ecosystem includes parsers in 12+ languages, editor support (VS Code, [Obsidian plugin](https://github.com/cooklang/cooklang-obsidian) with 308 stars, LSP), and a community recipe index. Because ingredients are inline-annotated in the markup, the parser inherently knows which quantities in instructions to scale. It also supports fixed quantities (`@salt{=1%tsp}` — the `=` prefix prevents scaling for things like baking powder that shouldn't change with servings), recipe references (`@./Shakshuka sauce{100%g}` — sub-recipes as composable ingredients), and named timers (`~eggs{3%minutes}`). The ecosystem is broader than just the CLI — there are native iOS and Android apps with iCloud/CookCloud sync, offline support, shopping lists grouped by store section, and recently-added timer support. But the UX maturity is limited: the iOS app has a [3.8/5 rating](https://apps.apple.com/us/app/cook-cooklang-recipe-app/id1598799259) with only 4 reviews and reports of bugs (accidental recipe deletion, crashes). Their own [blog](https://cooklang.org/blog/09-cooklang-vs-paprika-vs-mealie/) positions it honestly — Cooklang removes friction "through simplicity" while Paprika does it "through polish" — and the audience is primarily developers and data scientists. There's no dedicated cooking mode optimised for kitchen use (large text, step-by-step, wake lock). The data model and parsing infrastructure are strong — worth evaluating as a foundation to build a polished kitchen experience on top of, rather than reimplementing from scratch. **[Zoe](https://zoe.com/)** — Adjacent, not competitive. Personalised nutrition based on gut microbiome testing ($10-25/month plus \~$350 test kit). Has recipes and meal planning, but [recipe UX is buggy](https://www.trustpilot.com/review/zoe.com) per user reports, adding homemade food is laborious, and the recipe submission experience is poor. Recipes are a byproduct of the nutrition platform, not a core focus. ## Feature Comparison | Feature | Paprika | Crouton | Mealie | Flavorish | Recify | Honeydew | **Recipe Site** | | ---------------------- | ------------- | ------------ | --------- | --------- | --------------------- | -------- | ------------------ | | **Web-based** | No | No | Self-host | Yes | No | No | **Yes (PWA)** | | **Cooking mode** | Yes | Excellent | No | No | Yes | No | **Planned (P2)** | | **Ingredient scaling** | Yes | Yes | Yes | Yes | Yes | Yes | **Yes (MVP)** | | **Inline timers** | Auto-detect | Tap-to-start | No | No | Yes | No | **Planned (P2)** | | **Unit conversion** | Basic | Basic | No | No | No | Yes | **Yes (MVP)** | | **Offline / PWA** | Native app | Native app | No | No | Device-only (no sync) | Yes | **Planned (P2)** | | **AI URL import** | Browser | Yes | Yes | AI | AI | AI | **Planned (P4)** | | **AI photo import** | No | No | No | AI | AI | AI | **Scaffolded** | | **Shopping list** | Yes | No | Yes | Yes | No | Yes | **Planned (P3)** | | **Voice / hands-free** | No | Wink | No | No | Yes | No | **Future** | | **Version history** | No | No | No | No | No | No | **Yes (git → DB)** | | **Free (no sub)** | \~$5/platform | $3 | Free | Freemium | Sub (6 free imports) | Freemium | **Free** | ## Where We Differentiate **Iteration velocity.** The current developer tooling — TypeScript + Zod schemas, git-backed content, static site on Cloudflare Pages, CI/CD pipeline — is not a user-facing competitive edge. It's an enabler. Type-safe schemas and build-time validation mean we catch errors before deployment. PR-based workflows mean every change is reviewed. Zero-ops infrastructure means we spend time on features, not servers. The competitive edge this drives is speed: we can ship and iterate faster than competitors burdened with heavier infrastructure, app store review cycles, or database migrations. The specific data format may evolve (e.g. Cooklang markup, database-backed models), but the velocity principles remain. **PWA-based cooking experience.** The premium cooking UX ([Pestle](https://9to5mac.com/2022/01/21/pestle-cooking-app-for-ios-release/), Crouton, Mela) is exclusively Apple native apps. The web-based options (Copy Me That, Samsung Food) have minimal cooking investment. No competitor offers a high-quality PWA cooking experience that works offline, installs to the home screen, and rivals native app UX. A web-based approach means cross-platform by default, URL-shareable recipes, no app store overhead, and no per-platform purchase. The Web Wake Lock API enables screen-on. Service workers enable offline. Structured recipe data also enables full-text portion scaling — where quantities in instructions update alongside the ingredient list, not just the ingredient list alone (a [documented limitation](https://help.anylist.com/articles/scale-recipe/) in virtually every competitor including [AnyList](https://www.anylist.com/)). **AI-powered recipe ingestion.** The 2024-2026 wave of AI-import apps (Flavorish, Honeydew, Recify) validates the market demand for intelligent recipe capture — from social media, URLs, and photos. But most of these apps treat capture as their *only* feature, without pairing it with a strong cooking experience. Meanwhile, the established recipe managers (Paprika, Crouton) rely on basic web clipping or manual entry. An ML pipeline for photo-to-recipe extraction is scaffolded (`ml-pipelines/recipe-parsing/` — DVC-managed with prepare → infer → evaluate stages, evaluation framework and ground-truth dataset built, model in development). Handwritten recipe OCR remains an [unsolved problem industry-wide](https://flavor365.com/how-to-scan-recipes-the-definitive-2026-guide/) — no app reliably handles older cursive handwriting — making this a genuine technical differentiator if we can solve it well. **Zero cost, no vendor lock-in.** Most competitors charge $4-10/month or require per-platform purchase. Self-hosted options need server infrastructure. We're free, deployed on Cloudflare Pages free tier. No account required to browse. No data silo. Recipes are portable structured data that we own. **Version history per recipe.** No competitor surfaces version history. Edits are overwrite-in-place or untracked. Git-backed content means every edit is already a commit with a full diff. The user-facing version history UI (browsing past versions, comparing changes) is planned for a future phase. Longer term, version history moves to a proper database as content management needs outgrow git workflows. Either way, this directly addresses the physical book's "destructive editing" problem in a way nobody else does. **The physical book replacement angle.** No competitor explicitly positions as "your handwritten recipe book, but better in every way." The Cooklang blog [captures this instinct](https://cooklang.org/blog/09-cooklang-vs-paprika-vs-mealie/) through a user who photographed her grandmother's recipe cards "just to have a backup" — then found the digital version became the primary. The emotional story of replacing a treasured physical book — preserving glanceability, resilience, and tangibility while eliminating the limitations — is under-exploited in the market. ## Where Competitors Are Ahead ### On our roadmap | Capability | Market leader | Our timeline | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | **AI recipe import** | [Flavorish](https://www.flavorish.ai/), [Honeydew](https://honeydewcook.com/), [Recify](https://www.recify.app/) | In exploration | | **Voice / hands-free cooking** | [Pestle](https://9to5mac.com/2022/01/21/pestle-cooking-app-for-ios-release/) (voice + wink), SideChef (voice + narrator) | Future (after cooking mode lands) | | **Recipe reviews** | [NYT Cooking](https://cooking.nytimes.com/) (community notes), [Mealie](https://mealie.io/) (multi-user comments + adaptations) | Future (complex — needs to handle forked recipe variants where users personalise a base recipe, similar to Mealie's multi-generational collaboration model) | ### Out of scope **Grocery delivery integration** ([Honeydew](https://honeydewcook.com/)/Instacart, [Ollie](https://ollie.ai/)/Amazon Fresh/Walmart) — integrating with delivery APIs that change frequently is a maintenance nightmare. Not a strong enough differentiator to justify the ongoing cost. **Smart appliance integration** ([Samsung Food](https://samsungfood.com/), SideChef/Home Connect) — same maintenance concerns, fragmented smart home ecosystem. A feature that sounds impressive on a feature list but rarely works well in practice. **Pantry photo scanning** ([Honeydew](https://honeydewcook.com/)'s "Pantry Mode") — the "What Can I Make?" concept is genuinely interesting, but photo-based pantry recognition is technically unreliable. We'd rather approach this via manual ingredient input (already planned as a future feature) than invest in computer vision we can't trust. ### Future consideration **AI meal planning** ([Ollie](https://ollie.ai/), Honeydew, Samsung Food) — worth evaluating once shopping lists and meal planning are built. The infrastructure for this (structured recipes, ingredient data, user preferences) will already exist. # Architecture ## Current: Static Site The recipe site is a section of the personal site — a Next.js 15 static export deployed to Cloudflare Pages. Recipes are TypeScript objects with Zod schema validation, stored in git. This architecture is intentionally simple: * **No backend** — no servers, no database, no auth * **No cost** — Cloudflare Pages free tier * **No ops** — static files served from a CDN * **Type-safe** — Zod schemas catch errors at build time * **Version-controlled** — every change is a git commit ## Future: Dynamic Features Features like user accounts, cooking logs, shopping list state, and favorites require persistent user state. The likely direction is to add dynamic infrastructure only where user-specific state actually requires it, while keeping the core recipe experience simple and fast. Recipes themselves may remain version-controlled content while user-specific data moves to a database-backed layer. The exact runtime, storage choices, and content model are future decisions that should be made through ADRs when the constraints are clearer. ## Recipe Ingestion Short/medium term: import tooling for photos, websites, and social media that feeds a human review workflow. Longer term: content management can evolve if the collection or contributor model outgrows the current approach. # Building Philosophy This project follows my [building philosophy](/projects?tab=philosophy). The recipe site is a textbook case for several principles: * **Short feedback loops** — ship the static recipe list first, learn from real kitchen use, then build features * **Build flywheels** — every recipe added makes the site more valuable. The ingredient graph, search index, and filtering all improve with more content. Structured data compounds into nutritional analysis, shopping lists, and meal planning * **Leverage tech debt** — start with recipes as version-controlled structured content. It's not scalable for non-technical users, but it's perfect for a tiny initial contributor set. Move to a richer content workflow when the constraint actually bites * **Less is more** — built on the existing personal site infrastructure. No new deployment pipeline, no new hosting, no new CI/CD. The recipe site is a route, not a separate application # Risks ## Adoption friction The primary users (us) need to actually use this instead of the physical book. If the digital experience is worse in the kitchen — too small, too fiddly, too many taps — we'll default back to the book. Cooking mode is the critical feature that determines whether this replaces or merely supplements the physical book. **Mitigation:** Build cooking mode early (Phase 2, not Phase 6). Test in actual cooking sessions. Optimize for the messiest, most stressful moments — hands covered in flour, timer going off, three things on the stove. ## Content migration effort 18 recipes are already digitized, but the physical book likely contains many more. Batch digitization requires the ML parsing pipeline to work well enough to be faster than manual entry. **Mitigation:** The photo-to-recipe pipeline infrastructure is built (`ml-pipelines/recipe-parsing/` — DVC stages, evaluation framework, ground-truth dataset). The model itself is in development. Even imperfect parsing that requires manual correction is faster than transcribing from scratch. And the draft workflow means partially-parsed recipes can be saved immediately and refined later. ## Feature creep The feature list above is ambitious. Building everything before shipping anything would violate every principle in the building philosophy. **Mitigation:** Strict phasing. MVP is already live. Each phase ships independently and delivers value on its own. No phase depends on a later phase being built. ## Architecture Decision Records - [ADR 000: Github Public Repo](https://robbiepalmer.me/projects/recipe-site/adrs/000-github-public-repo.md) — Accepted, 2025-10-18 (inherited from personal-site) - [ADR 001: Monorepo](https://robbiepalmer.me/projects/recipe-site/adrs/001-monorepo.md) — Accepted, 2025-10-18 (inherited from personal-site) - [ADR 002: React](https://robbiepalmer.me/projects/recipe-site/adrs/002-react.md) — Accepted, 2025-10-18 (inherited from personal-site) - [ADR 003: Next.js](https://robbiepalmer.me/projects/recipe-site/adrs/003-next-js.md) — Accepted, 2025-10-18 (inherited from personal-site) - [ADR 004: Mise En Place](https://robbiepalmer.me/projects/recipe-site/adrs/004-mise.md) — Accepted, 2025-10-18 (inherited from personal-site) - [ADR 005: Tailwind CSS](https://robbiepalmer.me/projects/recipe-site/adrs/005-tailwindcss.md) — Accepted, 2025-10-18 (inherited from personal-site) - [ADR 006: Turbopack](https://robbiepalmer.me/projects/recipe-site/adrs/006-turbopack.md) — Accepted, 2025-10-18 (inherited from personal-site) - [ADR 007: Pnpm](https://robbiepalmer.me/projects/recipe-site/adrs/007-pnpm.md) — Accepted, 2025-10-18 (inherited from personal-site) - [ADR 008: Vitest](https://robbiepalmer.me/projects/recipe-site/adrs/008-vitest.md) — Accepted, 2025-10-18 (inherited from personal-site) - [ADR 009: CodeRabbit](https://robbiepalmer.me/projects/recipe-site/adrs/009-code-rabbit.md) — Accepted, 2025-10-19 (inherited from personal-site) - [ADR 010: Terraform](https://robbiepalmer.me/projects/recipe-site/adrs/010-terraform.md) — Accepted, 2025-10-19 (inherited from personal-site) - [ADR 011: Cloudflare Pages](https://robbiepalmer.me/projects/recipe-site/adrs/011-cloudflare-pages.md) — Accepted, 2025-10-19 (inherited from personal-site) - [ADR 012: Claude Code](https://robbiepalmer.me/projects/recipe-site/adrs/012-claude-code.md) — Accepted, 2025-10-19 (inherited from personal-site) - [ADR 014: Husky Precommit](https://robbiepalmer.me/projects/recipe-site/adrs/013-husky-precommit.md) — Accepted, 2025-10-19 (inherited from personal-site) - [ADR 015: Static Site Generation](https://robbiepalmer.me/projects/recipe-site/adrs/014-ssg.md) — Accepted, 2025-10-19 (inherited from personal-site) - [ADR 016: GitHub Actions](https://robbiepalmer.me/projects/recipe-site/adrs/015-github-actions.md) — Accepted, 2025-10-19 (inherited from personal-site) - [ADR 017: Terraform Cloud](https://robbiepalmer.me/projects/recipe-site/adrs/016-terraform-cloud.md) — Accepted, 2025-10-19 (inherited from personal-site) - [ADR 018: GitHub Secrets](https://robbiepalmer.me/projects/recipe-site/adrs/017-github-secrets.md) — Accepted, 2025-10-19 (inherited from personal-site) - [ADR 019: Shadcn](https://robbiepalmer.me/projects/recipe-site/adrs/018-shadcn.md) — Accepted, 2025-10-19 (inherited from personal-site) - [ADR 022: Fuse.js](https://robbiepalmer.me/projects/recipe-site/adrs/019-fuse-js.md) — Accepted, 2025-10-26 (inherited from personal-site) - [ADR 024: Renovate](https://robbiepalmer.me/projects/recipe-site/adrs/020-renovate.md) — Accepted, 2025-11-02 (inherited from personal-site) - [ADR 028: Cloudflare DNS](https://robbiepalmer.me/projects/recipe-site/adrs/021-cloudflare-dns.md) — Accepted, 2025-11-26 (inherited from personal-site) - [ADR 029: Cloudflare Images](https://robbiepalmer.me/projects/recipe-site/adrs/022-cloudflare-images.md) — Accepted, 2025-12-14 (inherited from personal-site) - [ADR 030: Downgrade Cloudflare Terraform Provider](https://robbiepalmer.me/projects/recipe-site/adrs/023-downgrade-cloudflare-tf.md) — Accepted, 2025-11-26 (inherited from personal-site) - [ADR 032: CodeQL](https://robbiepalmer.me/projects/recipe-site/adrs/024-codeql.md) — Accepted, 2025-12-18 (inherited from personal-site) - [ADR 033: In-Memory Content Graph](https://robbiepalmer.me/projects/recipe-site/adrs/025-content-graph-indexes.md) — Accepted, 2025-12-30 (inherited from personal-site) - [ADR 034: Shortcut](https://robbiepalmer.me/projects/recipe-site/adrs/026-shortcut.md) — Accepted, 2025-12-28 (inherited from personal-site) - [ADR 037: AGPL-3.0 License](https://robbiepalmer.me/projects/recipe-site/adrs/027-agpl-license.md) — Accepted, 2026-01-11 (inherited from personal-site) - [ADR 040: PostHog Analytics](https://robbiepalmer.me/projects/recipe-site/adrs/028-posthog-analytics.md) — Accepted, 2026-02-14 (inherited from personal-site) - [ADR 029: DVC](https://robbiepalmer.me/projects/recipe-site/adrs/029-dvc.md) — Accepted, 2026-02-21 - [ADR 030: Cooklang](https://robbiepalmer.me/projects/recipe-site/adrs/030-cooklang.md) — Accepted, 2026-03-01 - [ADR 031: OpenRouter](https://robbiepalmer.me/projects/recipe-site/adrs/031-openrouter.md) — Proposed, 2026-05-23 - [ADR 032: Better Auth](https://robbiepalmer.me/projects/recipe-site/adrs/032-better-auth.md) — Accepted, 2026-05-25 - [ADR 033: Backend Platform for Authenticated Features](https://robbiepalmer.me/projects/recipe-site/adrs/033-backend-platform-for-authenticated-features.md) — Accepted, 2026-05-27 - [ADR 034: Authorization Model](https://robbiepalmer.me/projects/recipe-site/adrs/034-authorization-model.md) — Accepted, 2026-05-27 - [ADR 035: Application Security Baseline](https://robbiepalmer.me/projects/recipe-site/adrs/035-application-security-baseline.md) — Accepted, 2026-05-27 - [ADR 036: Google OIDC Login](https://robbiepalmer.me/projects/recipe-site/adrs/036-google-oidc-login.md) — Accepted, 2026-06-19 - [ADR 037: GitHub OAuth Login](https://robbiepalmer.me/projects/recipe-site/adrs/037-github-oauth-login.md) — Accepted, 2026-06-19 - [ADR 041: Gemini Code Assist](https://robbiepalmer.me/projects/recipe-site/adrs/038-gemini-code-assist.md) — Accepted, 2026-06-20 (inherited from personal-site) - [ADR 042: Greptile](https://robbiepalmer.me/projects/recipe-site/adrs/039-greptile.md) — Accepted, 2026-06-20 (inherited from personal-site) - [ADR 043: Codex](https://robbiepalmer.me/projects/recipe-site/adrs/040-codex.md) — Accepted, 2026-06-21 (inherited from personal-site) - [ADR 044: Codex Code Review](https://robbiepalmer.me/projects/recipe-site/adrs/041-codex-code-review.md) — Accepted, 2026-06-21 (inherited from personal-site) - [ADR 045: Qodo](https://robbiepalmer.me/projects/recipe-site/adrs/042-qodo.md) — Accepted, 2026-06-21 (inherited from personal-site) - [ADR 046: Custom Agentic Code Review](https://robbiepalmer.me/projects/recipe-site/adrs/043-custom-agentic-code-review.md) — Proposed, 2026-06-21 (inherited from personal-site) - [ADR 047: Trivy Security Scanner](https://robbiepalmer.me/projects/recipe-site/adrs/044-trivy.md) — Accepted, 2026-06-21 (inherited from personal-site) - [ADR 045: SonarQube](https://robbiepalmer.me/projects/recipe-site/adrs/045-sonarqube.md) — Accepted, 2026-06-26 - [ADR 049: Zizmor & actionlint (GitHub Actions Security)](https://robbiepalmer.me/projects/recipe-site/adrs/046-zizmor.md) — Accepted, 2026-06-27 (inherited from personal-site) - [ADR 047: PostHog Logs for Backend Observability](https://robbiepalmer.me/projects/recipe-site/adrs/047-posthog-logs.md) — Accepted, 2026-06-28 - [ADR 048: Cloudflare Workers Observability Destinations (Beta)](https://robbiepalmer.me/projects/recipe-site/adrs/048-cloudflare-observability-destinations.md) — Accepted, 2026-06-28 --- Markdown index of this site: https://robbiepalmer.me/llms.txt