Logistics App Starter · Industry version
Ecommerce Fulfillment Template
The pick-pack-ship backbone for an online store — batched fulfillment, branded tracking, returns — in code you own.
An online store's reputation is decided after checkout. This starter generates the fulfillment layer that decides it: orders flow into pick-and-pack batches, ship with the right carrier for the promise made, and track on a page carrying your brand — with the returns flow that ecommerce makes inevitable built in.
- 6 core entities
- Exception queue built in
- Code you own
- Vibe + Governed modes
01 · The problem
Why a generic Logistics falls short
Ecommerce fulfillment is promise-driven in a way generic shipping tools don't model. Checkout sold a delivery window — free five-day or paid two-day — and every downstream choice, from batch priority to carrier service, exists to keep that promise. Without the promise on the order record, the warehouse optimizes for cost while marketing answers angry emails.
The volume pattern is spiky and consumer-shaped: single-item parcels by the hundred, a flash-sale morning that triples the queue, address typos from mobile checkouts, and a steady stream of where-is-my-order tickets that scale with every scan gap. A fulfillment system earns its keep in the spikes, not the averages.
And returns aren't an exception in retail — they're a planned flow. Apparel runs double-digit return rates, and each return needs a label, an inbound tracking leg, an inspection outcome, and a refund trigger. Shipping tools that treat returns as a reversed label leave the actual workflow — and the customer's refund — in limbo.
02 · Data model
The data model, adapted
Everything in the base Logistics starter —
ordersshipment_itemsshipmentscarrierstracking_eventswarehouses— plus the entities this industry actually runs on:
| table | what it holds |
|---|---|
delivery_promises | The window sold at checkout per order — the deadline that drives batch priority, carrier choice, and at-risk alerts. |
pick_batches | Warehouse picking runs grouping orders for efficient floor walks, with per-picker assignment and completion tracking. |
return_shipments | The inbound leg — return label, carrier scans, received condition, and the refund or restock decision it triggers. |
03 · Screens
Modules through the industry lens
Promise-driven batching
01Batches build by promise deadline first: two-day orders wave out before today's cutoff, standard orders fill remaining capacity. When a flash sale floods the queue, the system spends your capacity on the promises closest to breaking.
Branded tracking with proactive alerts
02Customers track on your domain, in your brand, with the promise date front and center. When a shipment stalls, the at-risk alert reaches your support team before the customer notices — flipping where-is-my-order from inbound ticket to outbound reassurance.
Returns processing flow
03A return starts with a customer-generated label, tracks inbound like any shipment, and lands in an inspection step whose outcome — restock, write off, refund — is recorded against the original order. The loop closes in data, not in a shared inbox.
04 · In practice
Workflows it models
Morning wave to carrier cutoff
01Overnight orders sort by promise deadline into pick batches; pickers clear them by early afternoon, labels print at packing, and the van collects before cutoff. The dashboard shows promises at risk while there's still time to expedite.
Flash-sale surge day
02Triple volume hits and batching triages: expedited promises first, oversells flagged against inventory, and the exception queue watched hourly. The operation bends without breaking because priority is a rule, not a debate at the packing bench.
Return to refund in one thread
03A customer requests a return, gets a label, and drops the parcel off. Inbound scans show it coming; inspection marks it restockable; the refund triggers and inventory increments. Support answers with the timeline instead of an investigation.
Ecommerce Fulfillment template — frequently asked questions
Does it connect to my storefront?
Orders flow in from wherever checkout happens — a webhook or import writes them into the orders table with items, address, and the delivery promise. From there batching, shipping, and tracking run in your own system regardless of storefront.
How does it decide which carrier and service each order gets?
Carrier choice reads the promise date, destination, and parcel profile against each carrier's services and cutoffs. The selection logic is code you own — start simple, and add rate-shopping when your volume justifies it.
Can customers track orders on my own site?
Yes — the branded tracking page runs on your domain, shows the merged event timeline against the promised window, and never sends customers to a carrier's site. It's the single highest-leverage support deflection in ecommerce.
How are returns and refunds handled?
Returns are a first-class inbound flow: label issued, transit tracked, condition recorded at inspection, and the refund-or-restock outcome tied to the original order. Your refund trigger — on receipt or on inspection — is a rule you set in your own code.
Related
Dual7 App Starters
Build your Ecommerce Fulfillment on your terms
The pick-pack-ship backbone for an online store — batched fulfillment, branded tracking, returns — in code you own. Describe your version to start — the output is a project you own.