Dynery · Delivery Integration · Plan of Record · May 2026

Nash Is the Infrastructure.
Dynery Is the Experience the Guest Never Forgets.

The complete plan of record for integrating delivery into Dynery v1 using Nash as the invisible orchestration layer — what we decided, why we decided it, how it works, and what the team builds next.

GO — Integration Approved

Sandbox Access Granted

Decision Owner: Wale Martins

Nash Contacts: Jordan Powell · Hasaan Munim

Section 01 — Strategic Rationale

Why We Are Doing This — and Why Now

Dynery's mission is to rebuild the digital relationship between restaurants and their guests. That means restaurants must own the ordering experience, the customer relationship, and the data — without depending on marketplace platforms that extract margin and own the customer.

Delivery has historically forced a false choice: use a marketplace (DoorDash, Uber Eats) and surrender the relationship, or build your own logistics infrastructure, which is not feasible for a startup. Nash eliminates that false choice.

20–30%

Marketplace fee extraction on every delivery order

$5–7

Blended per-delivery cost via Nash in Seattle — passable to guest

97%

Completion rate across 30,700 Nash deliveries in Seattle, last 90 days

“Dynery is the brain — orders, UX, payments, data. Nash is the muscle — dispatch, courier execution, tracking signals. This division must never blur.”

Derin — Dynery AI Strategic Advisor — April 2026

The strategic principle is absolute: Dynery owns every pixel the guest sees, every state the order passes through, and every byte of data generated. Nash operates behind the scenes and is never visible to the guest.

Section 02 — What Nash Is

Nash: What It Does, What It Doesn’t

Nash is an AI-native delivery orchestration platform, founded 2021 (YC S21), backed by a16z. One API. Multi-carrier dispatch. Live tracking signals. Automatic failover. We evaluated Nash against building direct integrations with Uber Direct and DoorDash Drive. The decision is not close.

Nash Owns

Carrier selection & dispatch optimization
Driver coordination and assignment
Tracking signals via webhooks + polling
Automatic failover between providers
Proof of delivery capture
Provider SLA negotiation

Nash Does Not Own

The guest-facing experience
Authoritative order state
Customer data or history
Dense GPS breadcrumb trail
Per-restaurant branding (native)
SLA breach events — Dynery must build this

The GO Decision

Why Nash Cleared Every Bar

Factor	Nash	Direct Integrations	Why It Matters
Speed to launch	Fast	Slow	One integration vs multiple courier APIs
Engineering complexity	Low	High	Single SDK handles multi-carrier routing
Dispatch control	Full	Full	Override, failover, and race mode all available
Brand control	Org-level	Partial	Org-level branding is fine for v1 — Dynery owns UI anyway
Data access	Full API	Full API	All telemetry via webhooks + REST
Seattle coverage	Strong	Fragmented	97% completion, 46-min median
Economics	Viable	Variable	$500/mo incl. 500 deliveries; ~$5–7/delivery blended

Bottom Line

Nash clears every bar for Dynery v1. There are no blockers. The only future consideration is per-restaurant branding, which is irrelevant because Dynery renders tracking natively and never surfaces Nash to the guest. This is a clear GO.

Section 03 — System Design

End-to-End Architecture

Core principle: Dynery owns the user experience, order lifecycle, and payment. Delivery is an execution layer that operates entirely behind the scenes.

Discovery → Cart → Mode Selection

User selects restaurant, builds cart, chooses Delivery. Address collection triggered. Nash quote requested for ETA and price display before checkout.

Checkout via Stripe Connect Stripe

Payment processed. Restaurant remains Merchant of Record. Dynery takes platform fee. Output: OrderID, PaymentIntent, status = PAID_PENDING_FULFILLMENT.

Order Created in Dynery

Restaurant console receives order. Dynery creates internal FulfillmentJob: type = DELIVERY, state = NOT_DISPATCHED. Restaurant begins prep.

Dispatch to Nash Nash API

Dynery calls Nash Order API with pickup address, dropoff, item summary, prep time, and delivery window. Nash returns NashJobID + ETA. Dynery stores DyneryOrderID ↔ NashJobID mapping.

Nash Orchestrates Courier Nash Internal

Nash selects best carrier (Uber, Grubhub, Roadie) via configured strategy. Driver assigned. Parallel dispatch and automatic failover are active.

Webhooks → Dynery State Machine

Nash fires status events throughout the lifecycle. Dynery maps these to canonical states. Dynery is always source of truth — Nash is a signal provider, never an authority.

Native Tracking UI — Dynery Only

Dynery renders live map tracking using Nash location webhooks + Mapbox route snapping. Client-side interpolation between 1-minute pings. No Nash-hosted UI. No redirects. Zero Nash brand exposure.

Delivery Complete or Exception Handled

On DELIVERED: order closes, receipt finalised, ratings triggered, all telemetry logged. On exception: Dynery exception engine decides between refund, redispatch, or support escalation.

Section 04 — Non-Negotiables

The Ownership Boundary — This Must Never Blur

This is the strategic line that defines Dynery’s position. Every architectural decision must reinforce it.

Dynery Owns

Guest-facing UX — ordering, tracking, comms
Checkout & payment via Stripe Connect
Order state machine — source of truth
Customer data & delivery telemetry
Brand, notification copy, and tone
Exception decisions: refund / redispatch
ETA display logic
Analytics and intelligence layer

↔

Nash Owns

Carrier selection & optimization
Driver dispatch & coordination
Location signals via webhook / polling
Automatic failover between providers
Proof of delivery capture
Provider SLA negotiation

Section 05 — Order Lifecycle

Order State Machine — Dynery Is the Truth

Nash webhooks provide signals. They never dictate final Dynery state. All state transitions must be idempotent and processed through Dynery’s internal engine.

Canonical Dynery States

CREATED CONFIRMED PREPARING READY_FOR_PICKUP OUT_FOR_DELIVERY DELIVERED FAILED

Nash Event → Dynery State Mapping

Nash Webhook Event	Dynery Transition	User-Visible?
delivery.assigned_driver	→ OUT_FOR_DELIVERY	Yes — show driver info
delivery.pickup_enroute	→ OUT_FOR_DELIVERY (update)	Yes — courier on the way
delivery.pickup_complete	→ PICKED_UP (sub-state)	Yes — order collected
delivery.dropoff_enroute	→ OUT_FOR_DELIVERY (en route)	Yes — tracking active
delivery.completed	→ DELIVERED	Yes — order delivered
delivery.failed	→ FAILED	Yes — exception flow
courier_location	No state change — feeds tracking UI	Yes — live map update
delivery.eta_updated	No state change — update ETA display	Yes — ETA refreshed

Engineering Requirement

All webhook handlers must be idempotent. Nash may retry events on failure. Store the raw event and timestamp before processing any state change. Never let a Nash event directly mutate Dynery state — all transitions pass through Dynery’s state machine logic.

Section 06 — Live Tracking

Tracking Implementation — Fully Native, Zero Nash Surface

Confirmed by Nash directly: there is no dependency on their hosted UI. Everything their tracking page renders is available via webhooks and REST. Dynery can own the entire tracking surface end-to-end.

Primary — Webhooks

courier_location fires every ~1 minute
All status lifecycle transitions
ETA updates on every change
Incident and exception events

Secondary — REST Polling

GET /jobs/{jobId} as resilience fallback
Courier name + phone (REST only, not in webhook)
Full cost breakdown
Proof of delivery on completion

Implementation Pattern — Recommended by Nash

// Tracking engine

courier_location webhook fires (~1 min cadence)
  -- store event to DB with timestamp
  -- push lat/lng to client via WebSocket

Client interpolation (Mapbox):
  -- snap-to-road on each new ping
  -- interpolate smoothly between fixes
  -- reset interpolation on next ping arrival

Polling fallback:
  -- GET /jobs/{jobId} on webhook timeout (>90 sec)
  -- ensures resilience against missed events
  

Note on Precision

The 1–2 minute cadence is a ceiling driven by upstream providers (Uber, DoorDash) — not a Nash throttle. This is industry-standard for food delivery and fully sufficient for v1. Client-side interpolation closes the perception gap entirely.

Section 07 — Courier Routing

Dispatch Strategy — A Full Engine Without Building One

Nash confirmed this is a core capability. Dynery gets multi-carrier dispatch optimization, per-order overrides, automatic failover, and race mode — without building any of it.

Strategy	Logic	Recommendation
Preferred Order	Explicit priority list: Uber → Grubhub → Roadie	v1 Start Here
Dynamic Dispatch	Balances cost, reliability, speed, and SLA automatically	v2 — after baseline data
Lowest Price	Cost-optimized carrier selection	High-volume or margin-sensitive tiers
Reliability Score	Historical provider performance routing	Premium restaurant partners

v1 Recommendation

Start with Preferred Order: Uber first, Grubhub fallback. Uber has a 24-minute median ETA in Seattle and consistently under-promises. Grubhub has +24 min late deliveries at p90 — fallback only, never primary. Evolve to Dynamic Dispatch once baseline performance data exists. DoorDash requires a separate agreement before activation.

Dispatch Trigger — Open Decision

Option A — On Payment (Recommended)

Dispatch fires immediately after payment confirmation. Fastest driver assignment. Requires passing accurate pickup_start_time to Nash to prevent driver arriving before food is ready.

Option B — On Restaurant Accept

Dispatch fires when restaurant confirms the order. Better coordination with prep time. Slight delay in driver assignment. Consider if pilot restaurants have variable prep windows.

Override & Failover Capabilities

Per-order dispatch_strategy_id override via API
Workflow automations — route by order value, SLA, product type, destination
Manual override: POST /select-quote per individual order
Automatic failover: if provider cancels or risks SLA breach, Nash re-dispatches automatically
Manual cancel + redispatch: POST /jobs/{id}/cancel then POST /autodispatch
Race mode: parallel dispatch to multiple providers — first confirmed driver wins

Section 08 — Exception Handling

Failure Handling Playbook — Every Scenario Mapped

This is the most operationally critical section. Each scenario was explicitly walked through with Nash during the working session. All of these must be implemented before launch.

Scenario

Nash Behavior

Dynery Action

No driver assignedNash continues searching; no webhook fires immediately

No event — Nash handles internally

Monitor internally. Alert ops at 5–7 min. v1: observe only. v2: auto parallel dispatch.

Driver cancels before pickup

Provider cancel webhook fires. Nash auto-reassigns to next provider.

Silent rebook if reassignment completes before user-visible delay. Otherwise notify guest.

Driver cancels after pickup

delivery.failed fires

Trigger refund flow. Optionally offer redispatch (rare — impractical post-pickup).

SLA breach risk

No native SLA event — Dynery must build this

Track ETA vs actual delta. Alert internally at +10 min. Notify guest at +15 min. Full Dynery responsibility.

Delivered but disputed

Proof of delivery: photo, GPS, timestamp available

Automated refund request via API using POD evidence. Define refund matrix: courier vs restaurant vs guest fault.

Critical Note on SLA

Nash does not fire an SLA breach event. Dynery must build its own ETA tracking layer that compares expected vs actual delivery time. Recommended thresholds: alert ops at +10 min, notify guest at +15 min, initiate compensation review at +20 min.

Section 09 — Time Expectations

ETA Strategy — Provider Philosophy Shapes Guest Trust

Different providers use fundamentally different ETA philosophies. Without a Dynery ETA layer, guest perception is at the mercy of provider variance. Dynery must implement provider-aware ETA logic.

Provider	Philosophy	Median Accuracy	Tail Risk (p90)	Dynery Strategy
Uber	Conservative — under-promises (P95)	Avg 24 min early	Low	Show as-is
Grubhub	Optimistic — mean (P50)	Avg 1–2 min early	+24 min late	Add 5–10 min buffer
Roadie	TBD — monitor in sandbox	—	—	Default 5-min buffer

// Dynery ETA display layer -- v1

function displayETA(nashETA, provider) {
  if (provider === 'uber')    return nashETA;        // under-promises, safe
  if (provider === 'grubhub') return nashETA + 7;     // buffer for tail risk
  return nashETA + 5;                                  // default for unknowns
}
  

Section 10 — Data Strategy

Data & Telemetry — The Intelligence Layer Starts Now

Critical Architecture Requirement

Nash does not persist a dense GPS breadcrumb trail. Only the current location is available on each webhook and poll. If Dynery wants a full location history per delivery — required for disputes, analytics, and future ML — it must store every courier_location event as it arrives. This is a Day 1 requirement, not a future enhancement.

Via Webhooks — Store Everything

All status events with precise timestamps
All courier_location events: lat/lng + timestamp
ETA changes over time — full history
Incident events and cancellation reasons

Via REST — Enrich on Completion

Courier name and phone number
Full cost breakdown: base, tolls, tips, wait time, cancellation fees
Proof of delivery: photo, signature, barcode
Complete job lifecycle history

Disputes

GPS trail + POD + timestamps enable automated refund decisions and fraud protection

Analytics

Delivery benchmarks by provider, restaurant, neighborhood, and time of day

Future ML

Predict actual delivery time, flag at-risk orders, build ETA models that outperform Nash defaults

“Nash gives Dynery execution. Dynery must build intelligence. The data collected in v1 is the foundation for outperforming marketplace delivery in every future version.”

Derin — Dynery AI Strategic Advisor — Post-Meeting Analysis, April 2026

Section 11 — Unit Economics

Economics — Viable for Independent Restaurants

Nash’s pricing model works for independent restaurants. Contrast with marketplace delivery at 20–30% of order value — Nash allows Dynery to offer delivery while preserving restaurant margins entirely.

Cost Component	Amount	Notes
Nash platform fee	$500/month minimum	Includes 500 deliveries — ~$1/delivery platform baseline
Uber — Seattle (90 days)	$5.10 median · $7.15 avg	Primary provider — on-demand, short distance
Grubhub — Seattle	$8.99 median · $8.00 avg	Fallback provider only
Roadie — Seattle	$6.03 median · $8.55 avg	Flexible same-day option
Blended effective cost	~$5–7 per delivery	Dynamic Dispatch trends toward lower end of range

The Model

Pass delivery fee (~$5–8) to guest. Dynery and restaurant margins remain intact. This is fundamentally different from marketplace economics. Restaurants keep their margin. Guests pay a fair, transparent delivery fee. Dynery owns the relationship.

Section 12 — Market Validation

Seattle Performance — Nash Confirmed as a Deep Market

30,700

Nash deliveries in Seattle in the last 90 days

97%

Completion rate — inclusive of all outliers

46 min

Median delivery time pickup to dropoff (aggregate)

24–26 min

Median delivery time for Uber and Grubhub specifically

Interpretation

The 46-minute aggregate median includes longer-distance and batched deliveries. Provider-level performance for Uber (24 min) and Grubhub (26 min) is competitive with marketplace delivery for standard food orders. Nash confirmed Seattle as a deep market. Specific weak zones were not surfaced — flag for ongoing monitoring during v1 pilot operations.

Section 13 — Risk Register

Risks & Mitigations — Known, Owned, Manageable

Dispatch Timing

If the dispatch trigger is wrong — too early and drivers arrive before food is ready; too late and delivery slows. The optimal trigger has not been locked for the pilot restaurants.

Lock dispatch trigger before build. On payment + accurate prep_time is recommended.

SLA Breach Is Dynery’s Responsibility

Nash has no native SLA breach event. Without building a tracking layer, late deliveries go unnoticed and uncompensated. This cannot be deferred to a later phase.

Build ETA delta tracking. Alert internally at +10 min, notify guest at +15 min.

DoorDash Requires Separate Agreement

DoorDash Drive is available via Nash but requires a separate DoorDash agreement. The full multi-provider advantage is partially gated at launch. Uber + Grubhub cover v1 adequately.

Launch on Uber + Grubhub. Initiate DoorDash agreement in parallel.

Grubhub Tail Risk

Grubhub has +24 min late deliveries at p90. Using it as a primary provider risks destroying guest trust on bad days. ETA buffering alone does not fully neutralize this.

Grubhub as fallback only. Add 7-min buffer when active. Demote if p90 degrades further.

No Dense GPS Trail in Nash

Nash only exposes current location per webhook. If Dynery does not store every courier_location event, location history is permanently lost. No disputes, no analytics, no ML.

Store every courier_location event on arrival. Non-negotiable Day 1 requirement.

Upstream Provider Dependency

Nash SLA covers Nash uptime only, not upstream provider latency or outages. If Uber or Grubhub degrade, the guest experience degrades — and Dynery owns the blame surface.

Enable automatic failover. Monitor provider health. Communicate proactively during incidents.

Section 14 — Build Plan

10-Day Integration Execution Plan — Eugene Leads

Sandbox access and API keys have been granted by Nash. The goal of this phase is to validate the full delivery flow end-to-end in sandbox with no surprises in production. Launch with 1–2 pilot restaurants only.

Days 1–2

Phase 1 — Core Plumbing

Create Nash order via API in sandbox
Store NashJobID ↔ DyneryOrderID mapping
Subscribe to all webhook event types
Log raw events to DB with timestamps
Validate webhook signature verification and retry handling

Days 3–4

Phase 2 — State Machine

Map all Nash events to canonical Dynery states
Build idempotent webhook handler with event ID dedup
Implement retry + dead-letter queue for failed events
Unit test all state transitions including edge cases

Days 5–6

Phase 3 — Tracking UI

Integrate Mapbox with snap-to-road route rendering
Build client-side location interpolation between pings
ETA display logic with provider-aware buffering
Courier info panel (name and phone via REST enrichment)

Days 7–8

Phase 4 — Dispatch Logic

Implement Preferred Order strategy: Uber then Grubhub
Add per-order override via dispatch_strategy_id
Configure automatic failover and race mode
Lock and implement dispatch trigger decision

Days 9–10

Phase 5 — Failures & Telemetry

Implement all five failure scenarios from Section 08
Build SLA tracking layer: ETA vs actual delta with alerting
Refund automation API integration
Audit full telemetry persistence checklist
End-to-end smoke test with Nash sandbox from order to delivery

Definition of Done for Integration Spike

A full delivery order is placed in sandbox, dispatch fires, all webhooks are received and mapped to correct Dynery states, live tracking renders natively in Dynery UI, and a simulated failure triggers the correct exception flow — all without touching the Nash-hosted UI or exposing any Nash branding.

Section 15 — Non-Negotiables

Locked Decisions — Not for Re-Discussion in v1

These decisions are final. Changes require explicit sign-off from Wale Martins.

Decision	Value	Rationale
Delivery layer	Nash	Passes all technical, operational, and economic gates
Guest tracking UI	Fully native — Dynery	No Nash-hosted UI. No redirects. Full brand control.
Branding	Dynery-branded	Per-restaurant branding deferred to v2
Order state authority	Dynery is source of truth	Nash provides signals only — never authoritative state
Payment	Stripe Connect	Restaurant = Merchant of Record. Locked architecture.
Data ownership	Dynery retains all telemetry	Stored locally. Exported via Nash API. No data lock-in.
v1 providers	Uber + Grubhub	DoorDash pending separate agreement
Launch scope	1–2 pilot restaurants	Validate experience before broad rollout

Section 16 — Blocking Decisions

Open Decisions — Must Be Resolved Before Build

These Are Not Open Questions

These are blocking decisions. The integration spike cannot be fully specified until they are locked. They require a decision from Wale Martins before Eugene begins phases 4 and 5.

Dispatch Trigger

When does Dynery fire the dispatch call to Nash? On payment confirmation, or when the restaurant accepts the order? This determines driver arrival timing relative to food readiness and directly impacts cancellation rates.

ETA Display Philosophy

Show raw provider ETA or add a buffer for tail-risk protection? What does Dynery tell the guest if ETA changes significantly mid-delivery? This sets guest expectation standards for v1.

Delivery Fee Model

Does the guest pay a delivery fee? Is it a flat pass-through (~$5–8), distance-based, or subsidised for pilot restaurants? Must be decided before UX build begins.

SLA Alert Threshold

At what delay past ETA does Dynery proactively notify the guest? What is the compensation or appeasement policy? Required before Phase 5 of the build.

Refund Matrix

How does Dynery arbitrate delivery disputes between courier fault, restaurant fault, and guest fault? Defines both the automated refund logic and the operations playbook.

Pilot Restaurant Selection

Which 1–2 restaurants go first? They need predictable prep times, a delivery-friendly menu, and a location with strong Uber coverage in the 24-minute median zone.

Nash Is the Infrastructure.Dynery Is the Experience the Guest Never Forgets.