# Delivery Date & Time — Product Strategy & Differentiation Plan

**Project:** Shopify delivery / pickup date-&-time scheduling app
**Owner:** Clicks to Cart (C2C Group), Kitchener, Ontario
**Benchmark:** *DS Pickup Delivery Date & Time* by Devesha Solution (5.0★, 64+ reviews, Built for Shopify, launched Jan 2025)
**Goal for v1:** Full feature parity with DS **plus** a set of differentiators that make us the obvious upgrade, targeting **all Shopify plans** (not Plus-only).
**Document version:** 1.0 · August 2026

---

## 1. Strategic thesis

DS is a well-executed, well-supported, cheap app that wins on *ease of setup* and *hands-on human support*. Its ceiling is that it is a **static rules engine**: every lead time, capacity limit, and blackout date is typed in by hand, it has no awareness of real fulfillment load, and — by its own admission — full checkout-level enforcement only exists on Shopify Plus.

We win by being the **operationally intelligent** scheduler:

1. **Enforce on every plan, not just Plus.** We use Shopify **Cart & Checkout Validation Functions** (server-side, available on all plans) so an order physically cannot complete without a valid, still-available slot — closing the gap DS leaves open for the ~95% of merchants who aren't on Plus.
2. **Schedule against real capacity, not a number in a box.** Capacity is modeled as *resources* (ovens, drivers, pickers, delivery routes), with soft slot-holds during checkout to kill double-booking races, waitlists when full, and predictive prep-times learned from the store's own fulfillment history.
3. **Own the whole fulfillment lifecycle**, not just slot selection: customer self-service reschedule, automated reminders that cut no-shows, deposits for future-dated made-to-order items, recurring delivery subscriptions, and a real dispatch/ops dashboard with printable run sheets.
4. **Match DS on the things reviewers love** — dead-simple setup (vertical templates that pre-configure a bakery/florist/grocer in minutes), fast Built-for-Shopify-grade performance, and responsive support — so we never lose on their home turf.

Positioning line: **"The only delivery scheduler that enforces on every plan and schedules against your real capacity."**

---

## 2. Feature parity baseline (must-have to match DS)

Everything DS does, we do. This is table stakes, not differentiation.

| Area | Parity requirement |
|---|---|
| Fulfillment methods | Shipping, Local Delivery, Store Pickup as independent paths, each with own rules/rates/calendar |
| Date & time picker | Calendar date → available time slots; unavailable dates/slots **hidden**, not just rejected |
| Cut-off times | Per day/method threshold after which that day's slots close |
| Preparation time | Configurable lead-time buffer, settable per product |
| Date ranges | Range selection where the fulfillment model calls for it |
| Blackout dates | Block specific dates per location/method; disappear from the picker |
| Weekday/date enable-disable | Independent per location and per method |
| Order/slot limits | Max orders per slot/day per location to prevent overbooking |
| Multi-location | Each location: own address, hours, calendar, blackout dates |
| Map display | Pickup locations on Google Maps |
| Radius / driving-distance eligibility | Determine if an address qualifies for local delivery |
| Auto location assignment | Route order to nearest eligible location |
| Inventory-based location | Exclude a location that doesn't stock the ordered product |
| Product-scoped rules | Availability & lead time by product / collection / vendor / type |
| Cart-content rules | Block a slot based on what's actually in the cart |
| Product-condition-by-location | Restrict a product to certain locations |
| Zone/distance rates | Rates vary by location, postal/ZIP, distance, method |
| Placements | Cart page, cart drawer, product page, checkout (Plus), thank-you, order-status, POS |
| Accounts & i18n | Recognize returning customers; customizable, multi-language widget text |
| Write-back to order | Chosen date/time/location visible on the order record |

---

## 3. Differentiators (how we beat DS)

Grouped by theme. Each names the **DS gap** it closes and a rough **build tier** (v1 = launch, v1.x = fast-follow, v2 = later).

### 3.1 Enforcement & correctness (the technical moat)

- **All-plan checkout enforcement (v1).** Cart/Checkout Validation Function blocks completion server-side if the slot is missing or has since been taken — works on Basic/Shopify/Advanced, not just Plus. *DS gap: enforcement is Plus-only.*
- **Soft slot-holds with TTL (v1).** When a shopper reaches checkout, we reserve their slot's capacity for N minutes so two shoppers can't grab the last slot. Expired holds auto-release. *DS gap: "hidden unavailable" doesn't handle the race; last-slot double-booking is possible.*
- **Timezone- & DST-safe slots (v1).** All slots computed in the store/location local timezone, DST-correct, with explicit customer-facing timezone labels. *DS gap: a class of bugs DS reviewers hint at with "mixed date messaging."*
- **Unambiguous pickup-vs-delivery copy (v1).** Method-specific labels and confirmation strings, never a stray "estimated delivery date" on a pickup order. *DS gap: a named review complaint.*

### 3.2 Capacity intelligence

- **Resource-based capacity (v1).** Capacity modeled as named resources — oven batches, delivery drivers, pickers, prep stations — not just an order count. One slot can consume different resource amounts depending on cart contents. *DS gap: single flat "max orders per slot."*
- **Waitlist & backorder for full slots (v1.x).** Customer can join a waitlist; auto-promoted (and notified) if capacity frees up.
- **Delivery-density / minimum-order routes (v1.x).** Only offer a delivery day to a postal code once a route threshold is met, or steer sparse areas to specific days. Cuts delivery cost. *DS gap: none — radius eligibility only.*
- **Predictive prep-time & demand (v2, AI).** Learn actual prep/fulfillment durations from the store's order history and suggest lead-times and capacity limits, instead of pure manual config. *DS gap: explicitly cannot derive lead times from data.*

### 3.3 Fulfillment lifecycle (beyond the slot pick)

- **Customer self-service reschedule (v1.x).** Magic-link / order-status portal to change slot post-purchase, with live capacity re-check and hold. *DS gap: not offered.*
- **Automated reminders & ETA notifications (v1.x).** Email/SMS "your pickup is tomorrow," "out for delivery, ETA 2–4 PM." Cuts no-shows for the exact verticals DS serves. *DS gap: none.*
- **Deposits / partial payment for future-dated orders (v2).** Take a deposit now, balance on fulfillment — critical for cakes, furniture, made-to-order. *DS gap: none.*
- **Recurring / subscription slots (v2).** Weekly grocery or repeat delivery on a standing slot. *DS gap: one-off only.*
- **Group / multi-drop catering orders (v2).** One order, multiple delivery points or large batch capacity consumption.

### 3.4 Merchant operations

- **Dispatch & ops dashboard (v1).** Bookings by slot/day/location, capacity-utilization heatmap, revenue by method, no-show/reschedule tracking. *DS gap: basic calendar view only.*
- **Printable run sheets & picking lists (v1.x).** Per-driver route manifests and per-slot picking lists, exportable/printable. *DS gap: none.*
- **Vertical setup templates (v1).** One-click "Bakery / Florist / Grocer / Furniture / Caterer" presets that pre-configure methods, slots, prep-times, and copy. Productizes the hand-holding DS does manually — beats them on their *own* strength (ease of setup). 
- **Auto-imported public holidays (v1.x).** Pull region/country holiday calendars so merchants don't hand-enter blackout dates. *DS gap: all blackout dates are manual.*

### 3.5 Platform & integration

- **Headless / Storefront API support (v1.x).** Works on Hydrogen / custom storefronts, not just theme widgets.
- **Merchant-facing REST/GraphQL API + webhooks (v2).** Push booking data to a WMS/ERP (e.g. Odoo — relevant to C2C's stack) so slots flow into back-office systems.
- **POS UI extension (v1).** Staff run the identical scheduling flow against the same capacity pool for phone/in-person orders. (Parity item, but we make the POS UX first-class.)

---

## 4. Additional pain points we solve (that neither app markets)

1. **The last-slot race condition** — solved by slot-holds (§3.1). A genuinely hard technical problem most apps ignore.
2. **No-shows and missed pickups** — solved by reminders + reschedule (§3.3). This is the #1 operational loss for bakeries/florists.
3. **Delivery cost bleed on sparse routes** — solved by delivery-density thresholds (§3.2).
4. **Setup fatigue** — solved by vertical templates + holiday auto-import (§3.4). Time-to-value in minutes.
5. **Made-to-order cash flow** — solved by deposits (§3.3). Merchants front material cost weeks before fulfillment.
6. **Back-office double entry** — solved by the merchant API/webhooks (§3.5). Bookings land in the ERP automatically.
7. **Festival/cultural demand spikes** (C2C's own use case) — solved by capacity intelligence + waitlists + pre-set surge blackout templates, so a Diwali/wedding-season spike doesn't overpromise.

---

## 5. Data model (generic + Shopify mapping)

Restated platform-agnostically, then mapped to how it lives on Shopify. **App-owned relational data lives in our Postgres via Prisma; a thin, read-optimized slice is mirrored to Shopify metafields/metaobjects so it's visible on the order and reusable by Functions and POS.**

| Entity | Purpose | Shopify home |
|---|---|---|
| **Shop** | Installed store, plan, settings, billing tier | App DB |
| **FulfillmentMethod** | Shipping / Local Delivery / Pickup; top-level configurable type | App DB |
| **Location** | Dispatch/pickup point: address, coords, hours, blackout calendar | App DB (+ maps to Shopify Location where relevant) |
| **Zone** | Where a location's delivery reaches — ZIP list / radius / driving distance | App DB |
| **SlotTemplate** | Recurring weekly slot: weekday, start/end, capacity, per location per method | App DB |
| **SlotOverride** | Date-specific exception: extra hours, reduced capacity, closed | App DB |
| **BlackoutDate** | Blocked date scoped to one/several/all locations/methods | App DB |
| **CapacityResource** *(new)* | Named resource (oven, driver, picker) with per-slot limits a booking consumes | App DB |
| **ProductRule** | Product/collection/vendor/tag override of lead time, methods, locations | App DB (product refs via metafield) |
| **Rate** | Price table for a method keyed by zone/distance/weight/value | App DB → Delivery Customization Function |
| **SlotHold** *(new)* | Temporary capacity reservation during checkout, with TTL | App DB (Redis-backed) |
| **Booking** | Confirmed reservation: order ref, slot, location, method, date/time, resources consumed | App DB + **written back to order via metafield/attributes** |
| **Waitlist** *(new)* | Customer waiting on a full slot; promotion state | App DB |
| **Reschedule** *(new)* | Change history of a booking's slot | App DB |
| **Notification** *(new)* | Reminder/ETA message queue and delivery log | App DB |
| **Deposit** *(new, v2)* | Partial-payment record linked to a future-dated booking | App DB + Shopify draft/order |
| **RecurringBooking** *(new, v2)* | Standing slot subscription generating child Bookings | App DB |

**Why app-DB-primary, not metaobject-primary (unlike DS):** capacity math, holds, waitlists, and analytics need transactional integrity and fast aggregate queries that metaobjects can't give. We treat Shopify as the *system of record for the order* and our DB as the *system of record for scheduling*, syncing the confirmed slot back onto the order so staff and POS see it natively.

---

## 6. Pricing strategy

DS prices oddly — the **same features cost more on a higher Shopify plan** ($6.99 → $12.99), which punishes growth and leaves value on the table. We price on **value delivered**, not the merchant's Shopify tier.

| Tier | Price (target) | Who | Includes |
|---|---|---|---|
| **Free** | $0 | Solo / single-location | 1 location, 3 methods, date/time picker, blackout dates, product rules, widget customization, i18n, **all-plan checkout enforcement**, 1 vertical template |
| **Starter** | ~$9.99/mo | Growing single/dual location | Everything Free + cut-off/prep-time, order limits, resource capacity (basic), dispatch dashboard, holiday auto-import, up to 3 locations |
| **Growth** | ~$19.99/mo | Multi-location operators | Unlimited locations, zones/rates, distance auto-assignment, waitlists, reschedule portal, reminders (email), run sheets, delivery-density routes |
| **Pro** | ~$39.99/mo | High-volume / ops-heavy | SMS reminders, predictive prep-time (AI), deposits, recurring slots, merchant API/webhooks, headless support, priority support |

Notes: undercut DS at the entry point (a genuinely capable Free tier wins installs and reviews), then monetize the operational intelligence they can't match. Keep a 7–14 day trial on paid tiers. Consider usage-based SMS as a metered add-on.

---

## 7. Go-to-market & "Built for Shopify" posture

- **Win DS's strengths first.** Reviewers pick DS for *setup ease* and *support*. Vertical templates + in-app guided onboarding + fast, human support are non-negotiable for parity.
- **Built for Shopify certification** is the credibility bar in this category (DS has it). Design to the BfS checklist from day one: App Bridge, Polaris, performance budgets, no layout shift on the storefront widget, accessibility, embedded-app best practices, mandatory GDPR webhooks.
- **Lead the listing with the two moats DS can't copy quickly:** "enforced on every plan" and "schedules against real capacity." Everything else is parity.
- **Target verticals in order:** bakeries → florists → grocers/fresh food → caterers → made-to-order furniture. These are DS's own review base; we out-feature them where each vertical hurts most (capacity for bakers, routes for grocers, deposits for furniture, multi-drop for caterers).

---

## 8. Phased roadmap (summary)

| Phase | Theme | Ships |
|---|---|---|
| **v1 (launch)** | Parity + core moats | All §2 parity, all-plan enforcement, slot-holds, resource capacity, timezone-safe picker, dispatch dashboard, vertical templates, POS |
| **v1.x (fast-follow)** | Lifecycle | Waitlists, reschedule portal, reminders (email→SMS), run sheets, holiday auto-import, delivery-density routes, headless |
| **v2 (expansion)** | Intelligence & monetization | Predictive prep-time (AI), deposits, recurring slots, merchant API/webhooks, group/catering orders |

The engineering breakdown of v1 into concrete, buildable tasks for Claude Code is in **`IMPLEMENTATION_PLAN.md`**.