A mobile app that rescues your stranded recipes — bringing them to your phone and surfacing them when you're ready to cook.
I have a Whole Foods Chantilly cake recipe saved on my computer, with my own notes on it. I've never made it again. By the time I'm in the kitchen with my phone, finding that file is more friction than just searching online — and the version I find isn't mine. So I watch a YouTube video instead, and the Chantilly cake sits on my desktop for another year.
I started designing this product thinking the barrier was retrieval. The file is in the wrong place — get it to my phone and I'll cook it. That's a reasonable hypothesis. It turned out to be wrong, or at least incomplete.
The Chantilly cake doesn't get made not because I can't find it. It never rises to the top of consideration.
I'm not standing in the kitchen thinking "I want to make Chantilly cake but I can't find the recipe." I'm standing in the kitchen thinking "what should I make?" — and the Chantilly cake never enters the answer. That's a discovery problem. Getting the recipe onto my phone is a necessary precondition, but it doesn't solve the problem on its own.
This realization came mid-process, through stress-testing my own assumptions. It changed what the product is. Import became the foundation. Re-engagement became the actual product.
Two users. Both have a collection of recipes they love but rarely cook from. Both default to whatever's easiest instead. The similarity ends there.
The distinction matters for more than just import path. The keeper of cards is the more emotionally invested user. If parsing fails on a handwritten card scan — and it will, more often than on a clean PDF — she's not having a software inconvenience. She's watching the app struggle with something in her grandmother's handwriting. The correction experience needs to feel like collaboration, not error recovery.
I'm including the evolution here deliberately. These decisions didn't arrive fully formed — they got sharper through questioning. That process is part of what I want to show.
The original framing was a retrieval app: import your recipes, find them easily, cook them. The import is the product. Everything else is secondary.
Stress-testing that assumption revealed the flaw. Import solves the access problem. It doesn't solve the consideration problem. A library full of rescued recipes on your phone still sits unused if the app doesn't bring the right recipe to the surface at the right moment.
Heirloom's re-engagement layer — ingredient search, "you haven't made this in a while" surfacing, recipes never cooked rising to the top — isn't a nice-to-have sitting on top of an import utility. It's the mechanism that actually changes cooking behavior. Without it, the product has solved the wrong problem.
The original PRD buried ingredient search in the features list as one item among many. Recognizing re-engagement as the core mechanism promoted it to its own section and changed how the home screen is designed — the app opens with a reason to cook, not a catalogue to browse.
The original design had ingredient search as the primary search surface. Type what you have on hand, find a recipe. That's a strong re-engagement feature. It also completely missed the case where you know what you want to make.
If I want to make Chantilly cake, I don't want to remember it uses apricot jam and almond extract. I want to type "Chantilly" and find it. The original design made that impossible — there was no recipe name search at all.
The solution is unified search: one search surface that handles both intents without asking the user to declare upfront which one they have. Type "chicken" and get both recipe name matches and ingredient matches in grouped results. The user self-selects. A user who came looking for Mom's Chicken Soup might notice they can also make Roasted Pepper Chicken with what's already in the fridge — re-engagement happening incidentally, which is the best kind.
This gap wasn't in the original design at all. It was found by asking "what mode are users in when they open the app?" — and realizing the answer was sometimes "I already know what I want to make," which the product had no answer for. The PRD, wireframe, and bottom navigation were all updated after this was caught.
The correction wireframe — inline editing, wavy underline on uncertain ingredients, accept-all always available — is designed to feel like spell-check rather than error recovery. Fast, forgiving, not mandatory. That's the right design for the digital archivist correcting a clean PDF that parsed at 87%.
It's a different experience for the keeper of cards correcting a scan of a faded, handwritten recipe card. For her, high correction rates aren't a product failure — they're an accurate reflection of difficult input. The framing of correction needs to match that reality. "We got most of Grandma's recipe — help us fill in the rest" is a different message than "2 ingredients need review."
The app knows which input type it received. A photo capture of a handwritten source is a different signal than a PDF upload. In v1 the correction experience is one-size-fits-all. That's a known limitation, not an oversight.
This distinction emerged from asking what the correction experience means emotionally for each user, not just functionally. The onboarding flow was also revised during this process — it originally had no failure recovery path for a completely unparseable import. The first import failing silently is the highest-risk moment in the product. It now triggers guided retry immediately, not a queue.
Surfacing recipes by ingredient and by recency changes cooking behavior — people reach for recipes they love but stopped making.
Some recipes were saved out of mild curiosity, not genuine intent. Bulk import fills the library with noise that dilutes the signal and makes surfacing feel random.
Rate of recipe opens via re-engagement strip versus direct library navigation. If users ignore the strip and go straight to library, it isn't doing its job.
Recipes cooked at least once, segmented by import method. Keeper of cards recipes may have higher cook rates than bulk-imported files — the intentionality of import matters.
Users engage with the app and cook from it, even if not every recipe gets made. A library with some dormant recipes is fine. A library nobody cooks from is not.
Behavior-based surfacing that learns which recipes actually matter to each user reduces the noise from bulk import and makes re-engagement feel personal rather than generic.
The correction experience is fast and forgiving enough that users don't quit after their first failure. One or two corrections feels like collaboration, not work.
Correction tolerance scales badly. Five corrections on one recipe feels like the app didn't do its job. The keeper of cards scanning handwritten cards will see higher correction rates than the digital archivist — measuring them together masks the signal.
Correction rate segmented by import type — photo capture vs. file upload. A high correction rate on handwritten card scans may be expected and acceptable. The same rate on PDF uploads is a parsing failure.
Keeper of cards retention after first correction. If she quits, the tone was wrong — not the correction count. This is a qualitative signal that retention numbers alone won't surface.
The correction screen speaks to both users the same way. Input-aware framing — warmer and more collaborative for handwritten scans — is a v2 refinement.
The effort of correction is worth it even when corrections are required. If users who correct recipes cook from them at the same rate as users whose recipes parsed cleanly, the correction experience is working.
Showing both recipe name and ingredient results for ambiguous queries serves both user intents without forcing an upfront choice — and creates incidental re-engagement moments.
Mixed results feel noisy rather than useful. Users who know what they want to make find ingredient results irrelevant. Users in open-question mode find recipe name results distracting.
Which result type users tap more often — recipe name or ingredient — and whether that varies by time of day. "What can I make tonight?" is a different mode than Sunday afternoon recipe planning.
If ingredient results are almost never tapped from ambiguous queries, a name-first search with ingredient search as a secondary mode may be less noisy and equally useful.
V1 establishes the foundation: import works, the library is built, basic re-engagement is in place, signal is accumulating. These are the limitations V1 accepts consciously, with a clear rationale for why they belong in V2.