metatrondelivery/PRODUCT_STRATEGY.md

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.