Beauty Forward

donation-delivery-app/functions/src/services/dispatch.service.ts:26–100 gates courier dispatch on Givebutter payment verification with three fallback paths: verified → dispatch immediately; Givebutter unreachable or slow → mark awaiting_payment and rely on the webhook backstop; verification rejected → mark payment_verification_failed and send a recovery email. The webhook handler at donation-delivery-app/functions/src/index.ts:448–605 re-dispatches when payment confirms later. It guards against the third-party APIs being down or slow, and keeps working anyway.

Confirmation emails can fire from three places: the donor-submit callable, the Firestore onCreate trigger, and the Givebutter webhook recovery path. A sendEmailOnce() pattern in donation-delivery-app/functions/src/services/resend.service.ts stores confirmationEmailSentAt on the donation document and checks it before sending, so duplicate sends from concurrent triggers are impossible by construction — not merely unlikely.

Intake used to mean typing every donated product in by hand. Now the warehouse manager points the phone camera at an item and the form fills itself. inventory-management-system/functions/src/index.ts:219–287 sends the photo to Gemini 2.5 Flash at temperature 0.2 (low, near-deterministic), under a JSON-schema constraint covering a 30-entry product-type enum plus a high/medium/low confidence field. The prompt tells the model to leave fields blank when it isn't sure rather than guess, and the confidence value drives a UI hint that flags low-confidence extractions for a human glance before they save. Barcode scanning is the second intake path: scan the UPC and, when the photo read is thin, a fallback chain fills the gaps — Open Beauty Facts → Open Food Facts → UPCitemdb → text-only Gemini, in that order. Same record either way; the manager picks whichever is faster for the item in their hand.

A model reading a label gives you whatever the label says — "moisturising lotion," "body moisturizer," "daily lotion" are three strings for one thing. Inventory only works if they collapse to one category, so the real engineering here is in the normalization, not the model call. [path — fill in] takes the free-form extracted text and matches it against a fixed set of predefined categories, so totals, batching, and downstream reporting count the same product as the same product every time instead of fragmenting across near-duplicate labels. The enum constrains what the model is allowed to return; this step handles everything that still slips through as raw text.

Intake isn't only what's physically scanned at the warehouse. Donations captured in the donation-delivery-app — what's coming, from whom, how much — flow straight into the inventory-management-system and surface as a tab the warehouse manager works from. [path — fill in] wires the cross-app read, so incoming product shows up as something to receive against rather than something to re-key from scratch. The two apps share one picture of what's in the building and what's on the way.