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!
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.
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!