AisleAsk → DoorDash: shopper-assist as a service (not the IP)

Status: GTM pathway plan (2026-07-23). AisleAsk is the hands-free glasses store-walk assistant (/api/aisleask/* — store catalog, in-store route, next-item, section scan). This is the plan to sell it to DoorDash as an operated service for their grocery shoppers — retaining the IP. Public demand-side surface: /for-shoppers.

The bet, in one line

DoorDash's grocery shoppers waste time hunting for items in stores they don't know. AisleAsk turns any phone (and, as an upgrade, glasses) into a hands-free picking copilot — optimal route, item location, scan-to-confirm, substitution help — so a shopper picks faster and more accurately. We sell DoorDash the outcome (throughput + accuracy + faster shopper ramp) as a subscription + managed service. We keep the engine and the store-map data; they rent the capability.

Why service, not IP (the deliberate posture)

Same principle as Workout Window / SecondSet: rev-share / SaaS + managed ops, not a code hand-off or acquisition. A one-time IP sale caps the upside and hands over the moat. A service keeps the recurring revenue AND the two assets that compound — the store-map data and the shopper-performance data. If DoorDash pushes to acquire, that's an upside conversation, never the plan; structure every agreement to retain the IP + data.

The only metric that matters

Everything is measured against what DoorDash's grocery P&L actually feels:

1. Pick time per order (minutes in store) — the headline.
2. Substitution / accuracy rate — fewer wrong/again-out-of-stock picks.
3. Shopper ramp time — how fast a new shopper is productive in an unfamiliar store.

If a paid pilot can't move #1 and #3 with real numbers, nothing else matters. Build the proof around these three from day one.

Device strategy — phone-first, glasses as the upgrade

Lead with the phone. The IP (routing, item-find, planogram matching) is device-agnostic; a shopper already carries a phone and works one-handed. An audio-first phone copilot needs no hardware rollout, no retailer camera fight, and no adoption friction — so it's what you sell DoorDash first. Glasses are the premium, hands-free tier (both hands on the cart) and the flagship demo, not the dependency. Selling a hardware program to a gig-labor force is a much harder first sale; don't gate the deal on it.

The pathway

Phase 0 — Sharpen the wedge + build undeniable proof

• Lock the pitch on the three metrics. Instrument AisleAsk to log pick-time per order in a real grocery store.
  • ✅ Pick-time instrumentation BUILT (2026-07-23) — the timed pick-session layer that produces the proof number. migration 564 (aisleask_pick_sessions + aisleask_pick_events, RLS service-role-only, human-provisioned); pure golden-tested metrics core aisleask-metrics.ts → computePickMetrics (duration / items-picked / accuracy % / substitution rate / items-per-hour, divide-by-zero guarded); service aisleask-sessions.ts (start → record event → complete → list → stats). Endpoints under /api/aisleask: POST /:storeId/pick-sessions, POST /pick-sessions/:id/events, POST /pick-sessions/:id/complete, GET /pick-sessions, GET /pick-sessions/stats. The pilot's headline delta comes from /pick-sessions/stats (avg pick time / items-per-hour / accuracy, filterable by source=self|doordash|pilot). See INDEX.md → AisleAsk. Still needed for a full Phase 0 proof: the single-store demo capture + on-screen time delta.
• Build a credible single-store demo: a real order picked with AisleAsk vs. a cold baseline, audio-first on a phone, with the time delta on screen.
• Stand up /for-shoppers — the demand-side surface (below). Shoppers wanting this is the pressure that makes DoorDash take the meeting.

Phase 1 — The store-data moat (this is the real work)

The hard part of grocery picking is per-store aisle/planogram data. Whoever has current, accurate, per-store item locations wins. Strategy: the shoppers build the maps as they work.

• Build the neutral glasses/phone capture rail (photo of a shelf/aisle sign + optional spoken note + location + wearer) → a durable capture record → planogram enrichment. Recon (2026-07-23) confirmed no capture-persistence rail exists today — AisleAsk's scan is transient (base64 → OpenAI → discarded). Compose the rail from existing pieces: createAttachment's upload + thumbnail + signed-URL pattern (journal-entry-attachments.ts), the 3-mode glasses bearer auth, and the AisleAsk validCoord/haversineKm helpers. This is the SAME rail the SecondSet steer wants — one primitive, many GTMs (see [feedback: generalize backend APIs]).
  • Status (2026-07-23): the HJ half of the rail is BUILT — POST/GET/ack /api/captures, the captures table (migration 561, human-provision the private bucket), consent enforcement, owner-scoped read. aisleask_planogram is one of the four purpose tags. Wiring AisleAsk's scan to EMIT an aisleask_planogram capture is the remaining follow-up. See docs/ai/INDEX.md → Captures rail + crosstalk/contracts/glasses-capture.md.
• Self-improving map = the moat + the reason it's a service (ongoing data ops, not shrink-wrapped software). Start with a few high-volume banners in one metro.

Phase 2 — Prove value WITHOUT DoorDash (de-risk the sell)

• Run AisleAsk with independent/gig shoppers, your own test shoppers, or a single grocery chain's e-commerce fulfillment team, and measure the pick-time delta for real. You walk into DoorDash with numbers, not a hypothesis.
• A grocery chain is a viable first customer in its own right (faster in-store picking for their own delivery/BOPIS) — and a reference that de-risks DoorDash.

Phase 3 — The DoorDash approach

• Enter through the outcome + a paid pilot, never an IP pitch: "We cut pick time X% and shopper ramp Y% in these stores. Run a paid pilot on N shoppers in one market — we operate it, you measure." Target the grocery / new-verticals + shopper-experience/logistics teams.
• Service terms: per-active-shopper/mo or per-order fee; DoorDash pays for throughput. Phone-first (no hardware line item to approve). Data + store maps stay ours (the moat); spell out IP retention explicitly.
• Land-and-expand: one metro → more banners → national.

Phase 4 — Moat + lock-in

Store-map data + shopper-performance data + integration into the shopper app = switching cost. Recurring, growing service revenue; the data asset appreciates.

Hard gates (name them, don't wish them away)

1. Retailer permission / camera-in-store. Grocers dislike being recorded. Mitigation: audio-first, on-demand single photos, no continuous recording; ideally a retailer partnership. The phone-first path sidesteps most of this.
2. Privacy + gig-labor UX. Capturing in stores + a wearer's spoken notes departs from the glasses' current "never log what the wearer said" contract — consent + retention must be first-class. And the tool must make the shopper more money (more orders/hour), or churn-heavy gig workers won't adopt it. Pitch value to BOTH sides: DoorDash (throughput), shopper (earnings/hour).
3. Build-vs-buy / competition. Instacart has in-house shopper tech; DoorDash may build. The service wins on time-to-value + the store-map moat + operated ops they'd otherwise staff themselves.
4. IP structure. Services/SaaS agreement with explicit IP + data retention; be ready to say no to an acqui-pitch, or price it as the upside it is.

Reuse map (what already exists)

• AisleAsk engine — /api/aisleask/* (store catalog, route, next-item, section scan) + services/aisleask.ts (validCoord/haversineKm, store lat/lng in migrations 506/510). The core IP.
• Glasses layer — the Mentra @mentra/sdk app (apps/glasses/): session.camera.requestPhoto, onTranscription, session.location, playAudio/speak, the 3-mode bearer auth + glasses_device_links wearer-resolve.
• The capture rail (to build) — the neutral primitive shared with SecondSet.
• QuickSites as the ops/portal back-end candidate (shopper management, store data dashboards) — the mesh "shared backend, branded front-ends" pattern.
• Geographic routing — QS route-optimize (PorchHearth's engine) — LIVE mesh contract (crosstalk/contracts/route-optimize.md): POST <qs-host>/api/tools/route-optimize takes a day's stops (addresses or lat/lng) → nearest-first order + a Google Maps turn-by-turn link (nearest-neighbor + Haversine, free OSM geocoding). Built on PorchHearth/DeliveredMenu's batch-delivery routing; the contract explicitly names "AisleAsk store-walk taskers first" + "AisleAsk catalogs that carry lat/lng (migration 506)." Consume this — do not reinvent driver routing.

The two routing layers (build one, reuse the other)

Two distinct problems — don't conflate them:

1. In-store route — which aisle/section order to walk inside ONE store. That's AisleAsk's own orderItemsByRoute (section walk order). Already solved.
2. Geographic multi-stop route — get to N stores (multi-store batch) and the delivery leg to N customers (a batch = several customers). That's QS route-optimize / PH's engine. Reuse it, don't build it.

The delivery-leg fit with multi-customer batch (migration 565): a batch already groups several customers' orders. After picking, the driver's drop route = a route-optimize call — pass each order's customer lat/lng → nearest-first + a maps link for the driver. Prereqs: (a) customer location on aisleask_orders (address/lat/lng — a small additive column; orders only carry customer_label + external_ref today), (b) a HJ consumer of QS's endpoint (a service call, or the zero-server deep-link <qs-host>/tools/route-planner?start=…&stops=…), and (c) confirm QS has deployed route-optimize to prod (contract says "prod pending QS deploy"). Then surface the driver route in the batch flow's bagging/done step.

BD path (who + how)

• Warm proof first (/for-shoppers demand + a pilot number), then the grocery / new-verticals + logistics org at DoorDash. No warm channel today (Crosstie is insurtech); the credibility line is the demo + the pilot delta + the "creator of HabitForge, 250k+ users" heritage.
• Sequence: chain pilot (Phase 2) → DoorDash paid pilot (Phase 3) → expand.

Decisions

• ✅ Standalone AisleAsk Shopper app (2026-07-23) — its own app, not a mode in the HiveJournal mobile app. Clean brand separation for a work-tool aimed at gig shoppers (nothing to do with journaling), and it can ship/iterate on its own cadence. Backend stays shared (the mesh "shared backend, branded front-ends" pattern): the AisleAsk engine + the neutral capture rail live in HJ's backend; the Shopper app is a thin consumer.
  • Shipped v0 (2026-07-23): the shopper picking surface exists as a focused, phone-first web route — /shop (ShopClient.tsx). Drives a timed pick session end-to-end (store-select → confirm list → walk the route deciding each item Got it / Sub / Out against a live timer → summary card with pick time / items-per-hour / accuracy / subs). PWA-style, standalone-feeling; can spin into the standalone Shopper app later. It's the demand-side twin of the marketing page /for-shoppers — the tool the shopper actually picks with.

Open questions

• First metro + first grocery banners to map?
• Do we pursue a grocery chain as customer #1 in parallel (revenue + reference), or stay laser-focused on the DoorDash path?