Chicky Drip: catering by on-device AI, with cloud fallback

Describe your party, and Gemini Nano on your own device plans a real catering order. If your device can't, Firebase AI Logic falls back to the cloud, so it works for everyone.

Comment

Inspiration

Chicky Drip is a real small catering business with 10 signature sauces. Catering customers don't know how much food to order for "40 people, half like spicy, $300", and owners lose hours on phone calls working it out. An AI planner fixes that, but a catering order is also personal: names, phone numbers, event dates, budgets. We wanted the planning to happen on the customer's device when it can (private, instant, free), and to still work on any device through the cloud when it can't. That is exactly what Firebase AI Logic hybrid inference is for.

What it does

  • Drip Planner: type "feeding 40 people, half like spicy, budget $300". The planner returns a complete order (items, flavors, sides, dips, drinks, quantities, total) built only from the real menu. One click adds it to the cart.
  • Hybrid by design: on desktop Chrome the prompt runs on Gemini Nano (Prompt API) and never leaves the device. On other browsers, or while Nano is downloading or unavailable, the same request runs on cloud Gemini automatically.
  • Honest UI: each plan has a badge, ⚡ On-device (Gemini Nano) or ☁ Cloud (Gemini via Firebase AI Logic), and a status line with a Download Gemini Nano button (Chrome needs a click to start the download).
  • Dependable output: both paths are constrained to the same JSON schema, then every item is validated against the real menu, portions are repaired deterministically (feed every guest, fit the budget, honor the spicy split) and prices are always recomputed from the menu, never trusted from a model, so a small on-device model can't produce a bad order.
  • Owner insights: the admin's paid-order summary uses the same hybrid path to phrase numbers computed server-side.
  • Checkout (pre-existing): PayPal sandbox checkout, rewards Drip Meter, admin tools.

How we used Firebase AI Logic

  • getAI(app, { backend: new GoogleAIBackend() }) + getGenerativeModel(ai, { mode: InferenceMode.PREFER_ON_DEVICE, onDeviceParams, inCloudParams }) in src/lib/firebase/hybrid-model.ts. Every model call in the app goes through that file; there is no other AI API and no AI secret.
  • Structured output on both paths: onDeviceParams.promptOptions.responseConstraint for Gemini Nano and inCloudParams.generationConfig.responseSchema (+ application/json) for the cloud, from one shared JSON schema whose product enum is the real menu.
  • System prompt on both paths: onDeviceParams.createOptions.initialPrompts and inCloudParams.systemInstruction carry the full menu and rules.
  • initializeDeviceModel() called from a button click with download progress; until Nano is ready PREFER_ON_DEVICE falls back to cloud without errors.
  • response.inferenceSource drives the on-device/cloud badge, so the demo shows which path ran.
  • App Check (initializeAppCheck with ReCaptchaEnterpriseProvider, debug-token support, optional limited-use tokens) protects the Gemini API; AI Logic enforces it.
  • A test suite runs the real firebase/ai SDK against a fake Chrome Prompt API to prove routing: Nano available means no network call and schema constraint passed to Chrome; Nano unavailable means one cloud call with the JSON schema and system instruction.

Challenges

  • The on-device model is small and bad at arithmetic, so the pipeline checks every plan against the menu and repairs it deterministically (retry once with feedback, fit to budget, top up guests).
  • On-device inference is single-turn text only: a good fit, because the planner is one prompt and one JSON answer.
  • Chrome only starts the Nano download from a user gesture: we added an explicit "Download Gemini Nano" step and status line.
  • Same behavior on two engines: one shared schema/system prompt, and a labeled rule-based fallback if both fail.

Accomplishments

A real business ordering flow where private planning happens on the customer's device, and every other device still gets the same experience through the cloud.

What we learned

Hybrid inference changes the product design: privacy and zero marginal cost on capable devices, availability everywhere, and App Check as the guardrail that makes a client-side model call safe.

What's next

Remote Config to tune the cloud model and mode without redeploying; Firestore for saved plans; an Android client with Gemini Nano for repeat customers.

Pre-existing code disclosure

Pre-existing code (disclosed): Chicky Drip existed before the Submission Period (Nov 11, 2026, 1:30 PM PT). It is a live small-business catering site (Chicky Drip 0.8.0: menu, orders, Drip Meter rewards, admin; built on the Lovable platform with TanStack Start + Supabase) that already has public use by the business's customers. Its PayPal sandbox checkout and an earlier server-side planner using an OpenAI-compatible API were written Nov 8-11, 2026 for a different contest (PayPal AI Hackathon) and are included as pre-existing code. Standard libraries and AI coding assistants were used. The first commit of this repo (7dfdb55916f9fc73933576a4fa1839728562a1ca) is an unmodified snapshot of that code; git diff 7dfdb55916f9fc73933576a4fa1839728562a1ca..HEAD is everything built for #BuildHybridAI.

Core value the existing app provides: a working catering menu, validated order pricing, PayPal checkout, rewards and owner admin, which gives the hybrid-AI planner a real product and real constraints (a real menu, real budgets) to prove itself against.

Built during the Submission Period:

  1. Removed the server-side OpenAI-compatible planner and its API-key path; every AI call now goes through Firebase AI Logic.
  2. Hybrid inference layer (src/lib/firebase/*): PREFER_ON_DEVICE with Gemini Nano and cloud fallback, one shared JSON schema/system prompt, Nano download flow, availability detection.
  3. App Check wiring (reCAPTCHA Enterprise + debug provider) and env-driven Firebase config; the app still builds and runs unconfigured with a labeled fallback.
  4. Model-agnostic planner pipeline (plan-pipeline.ts): retry with feedback, deterministic repair, engine reporting.
  5. UI: on-device/cloud engine badge, Gemini Nano status and download button, client-side planning (no login needed to try it).
  6. Owner insights re-phrased on the client via the same hybrid path, numbers still server-computed.
  7. Tests: 69 to 97, including tests that run the real Firebase AI SDK against a fake Chrome Prompt API for both routes. (about 1,200 lines added, 230 removed across 22 files; see git diff --stat).

Built With

  • chrome-prompt-api
  • cloudflare-workers
  • firebase-ai-logic
  • firebase-app-check
  • gemini
  • gemini-nano
  • react
  • supabase
  • tanstack-start
  • typescript
  • vitest
  • zod
Share this project:

Updates

Submission history