We shipped recipe import, and the "send this to AI" decision surprised even us
Quick context: Mise is a meal-planning app (swipe recipes, build a week, get a grocery list, cook). We launched the app a little under two months ago, and we just shipped Recipe Import on both iPhone and Android. Our users can now bring in a recipe from TikTok, Instagram, a recipe site, a screenshot, or pasted text.
The part I actually want to talk about isn't the feature itself; it's a decision we made underneath it.
Most recipe-import tools default to sending your link, photo, or video straight to a cloud AI service. We didn't want that as the default path. Mise tries on-device parsing first. It only falls back to a cloud pass - we named it Smart Import - when key details come back incomplete, or when someone chooses it directly. And even then, it only sends the extracted recipe text. Not the original link, the image, the video, or anything that identifies who's asking.
The other constraint we kept: it never auto-accepts a result. Every import lands as an editable draft. If it got the ingredient list wrong or missed the cook time, you fix it before it saves. We decided it was better to show you an imperfect draft than presume our processing/thinking was perfect from the jump.
It's also one recipe at a time, by design - we opted against bulk import. That was a trickier call than it sounds; it's slower for the user in the short run, but it keeps the parsing quality (and the legal footing around scraping) honest.
Curious how other people building AI features into consumer apps have drawn the on-device-first-vs-cloud-fallback line, and what convinced you to fall back sooner or later than we did.
Curious to hear how others have dug into this feature/option!
Interesting insight on the AI decision! It makes sense that users want control over what gets sent to external services. We're building ToolVault with the same privacy-first philosophy — all processing happens locally in the browser, so users never have to worry about their data being sent anywhere. The "send to AI" opt-in model is definitely the right approach.
The interesting decision here seems less about on-device vs. cloud and more about where you want the product to stop making assumptions for the user.
Curious whether the “editable draft” principle ends up mattering more to trust than the underlying parsing accuracy.
Agreed! I generally enjoy the ability to make changes and updates, but I also occasionally prefer for AI to simply handle it. We shall see how it goes!
That makes sense. It’ll be interesting to see which side users actually prefer once you have more usage data.
The detail I'd hold onto is that you send extracted text on the cloud pass, not the source URL or media. That quietly changes what you are: a parser that occasionally borrows a model, rather than a pipe into someone else's service. It also means the fallback can't be used to identify the user later, which is a much easier thing to promise than "we don't store prompts."
Where I'd push: on-device-first vs cloud is usually presented as a privacy line, but for you it's really a latency-and-quality line, and those can be tuned separately. The thing worth instrumenting is the fallback trigger. "Key details came back incomplete" is a heuristic that will slowly widen — one missing cook time today, one weird unit tomorrow — until most imports quietly take the cloud path and the default you designed no longer describes the product. If you log the fallback rate per source type (TikTok vs pasted text vs screenshot), you'll probably find one source drags the whole average and can be fixed on-device rather than routed away.
On editable drafts: I think that matters more than parsing accuracy, but only if the edit is fast. A draft that needs six taps to fix is worse than a wrong result the user shrugs at. Do you know what share of imports get edited before save, and whether that number is falling as parsing improves?
The "never auto-accept, always land as an editable draft" choice matches something we landed on for a different reason. Our app estimates calories and macros from a food photo via a cloud vision call, no on-device option, so the privacy line you drew isn't one I have direct experience with, but the trust question after the AI answer comes back is the same problem.
We started with a plain low/medium/high confidence label on scan results and found low-confidence read as "the AI failed," which made people trust the whole feature less, even on the scans it got right. Ended up merging the confidence signal into a specific line about what might be off, like a sauce or an unclear portion, instead of a vague score, then making that same field directly editable so a wrong guess is a two-second fix instead of a reason to distrust the number.
Sounds like the same instinct as your editable draft, just applied one layer up: don't just let the user correct a bad result, show them specifically why it might be off in the first place.
The constraint I find most interesting isn't on-device-first, it's that a fallback only ever sends extracted text and never the link or image. That's the part most teams quietly skip, because sending the raw URL is what makes the cloud pass accurate — you're giving up recall to avoid handing over "who is asking for what." Worth being honest with yourself about the cost there: the cases where on-device parsing fails are probably exactly the messy TikTok/screenshot ones where text-only gives the model the least to work with, so your fallback is weakest precisely where it's needed most. I'd watch the edit rate on Smart Import drafts specifically, split from local ones; if people are heavily correcting the fallback results, the privacy line is costing more than it looks. The editable-draft default seems like the right call regardless, since it turns a wrong parse into a 10-second fix rather than a trust event — and it's the kind of thing that only shows up as retention, not as a launch metric. On bulk import: is the reason really speed, or is it that one-at-a-time keeps the correction loop tight while your parser is still young?
Your “extracted text only” fallback boundary is the strongest part for me. In food logging, we found a similar pattern: the trust win isn’t pretending the model is always right; it’s preserving a reviewable draft and making provenance visible before anything is saved. I’d be curious whether you’re measuring correction rate separately for on-device and Smart Import—those edits may tell you when the fallback should happen earlier.