MenuCraft — from a fridge photo to a cooked recipe

The scan spine

A photo is resized on device, uploaded, and enqueued. A worker drains the queue into the AI service, which extracts ingredients from the image, normalises them onto a controlled food vocabulary, suggests merges with what is already in the kitchen, and writes an editable draft. The user confirms, and only then does anything become real inventory. Service credentials stay server-side; the client never holds them.

Getting confirmation right

Confirming a scan is the one operation that must never double-apply — a retried confirm should not add the same eggs twice. I made it idempotent, with quantity-summing merges, so a flaky network costs nothing. On the client side, device upload had to move off the standard multipart path after it threw in React Native.

Recipes from a confirmed kitchen

• Recipes generate from confirmed inventory, with a second pass to avoid repeats
• The daily menu runs as its own background worker
• Finishing a cooked recipe subtracts what it used from the inventory
• Six kinds of push reminder, fanned out server-side and idempotent per send

Budgeting a model that can stall

Vision calls are slow and occasionally hang. The service runs inside a strict transport budget — bounded per-attempt timeout, bounded retries, total time kept under the queue lease so a stalled call can never poison the queue — with limited vision concurrency. An offline fixture harness catches classification drift between model versions before it reaches users.

Scope note

A second contributor owns the subscription SDK integration, the shipped OAuth flow, account deletion and the deployment infrastructure. The scan pipeline, the app and the AI service are mine.

Status

Built through to a release candidate. Not publicly listed on the App Store at the time of writing.