Should You Build or Buy Preorders & Backorders on Shopify?
Preorders and backorders split on business model for mid-market Shopify stores: buy a selling-plan app when preorder patches an occasional sellout, and build on the selling-plan APIs when selling before stock is how you sell, an estimated $15,000–$40,000 one-time (Deploi estimate, illustrative). Either way the prize is deposit cash and paid demand before production. Charge-timing and shipping-delay rules make date honesty non-negotiable on both paths.
Your profile — see how the verdict shifts
- Confidence
- Medium — The buy-build boundary is clear but where a store sits on it is judgment, and pricing in this fragmented category is unverified
- Reference scenario
- $20M–$100M GMV · preorder 5–20% of revenue · agency dev bench
- As of
- August 2026
Decision at a Glance
| Your profile | Verdict | Why |
|---|---|---|
| Occasional sellouts (preorder under 5% of revenue) | BUY | An app patches the gap this week; custom selling-plan work for an edge case isn't where your dev dollars go. |
| Seasonal pushes (preorder 5–20% of revenue) | DEPENDS | A near-tie: buy if this season's sellout is bleeding now, and start scoping the build as preorder volume and tier creep grow. |
| Drops calendar (preorder 20–50% of revenue) | BUILD | When launches run on preorder, deposit mechanics, drop control, and date messaging are your brand; renting them from a widget stops making sense. |
| Made-to-order / preorder-first (50%+ of revenue) | BUILD | Preorder is the operating model, so own the selling-plan logic end to end; every app limitation is now a business limitation. |
What Preorders & backorders Actually Drives
| Outcome | Impact | How it works |
|---|---|---|
| Revenue — direct | High | The preorder button converts demand an out-of-stock page loses outright: sold-out, not-yet-made, and restocking products keep taking orders, and drops monetize the wait itself. |
| Operational efficiency | High | Firm preorder counts and deposit cash arrive before the purchase order, so production depth and working capital plan against paid demand instead of a forecast. |
| Data & insight | Medium | Preorder velocity by variant is demand measured with money attached: the strongest pre-production signal a merchandising team gets, and a cash-flow forecast in the same table. |
| Customer experience | Medium | A clear estimated-ship promise beats a dead PDP, but only while dates hold; a slipped date without a notice turns fans into refund requests. |
| Retention & LTV | Medium | Drop buyers return for the next drop when the last promise was kept; preorder is a trust loop that compounds when honest and breaks loudly when not. |
Spend ceiling: Size the spend to the cash-flow mechanics and the kept promise, not the badge. Illustrative math: a 30% deposit on a $200,000 production run frees $60,000 of working capital before manufacturing (illustrative); the badge itself is a theme section.
What buying enables (top apps)
- + Live in days: preorder badges, buttons, and estimated-ship messaging mapped onto chosen products and variants with no dev time
- + Partial-payment and preorder-discount presets that ride the selling-plan APIs without you touching them
- + Mixed-cart handling and fulfillment-hold conventions the category has already sanded down
- + Back-in-stock pairing on several of these apps, so one PDP slot either notifies the wait or sells it
What building additionally unlocks
- + Deposit ladders, charge schedules, and per-variant allocation caps defined per drop rather than per template setting
- + Drop mechanics as a first-class flow: scheduled reveals, caps, and preorder rolling into backorder automatically
- + Ship-date changes wired to delay notices and refund options, turning the compliance duty into a workflow
- + Preorder demand and deposit cash as queryable store data feeding production planning and cash-flow forecasts
Find Your Verdict in 3 Questions
Can you take money now, against a ship window you're confident publishing?
Yes: Go to question 2.
No: Your verdict: WAIT — hold at back-in-stock alerts, the notify-only cousin, until dates firm up; selling a wait you can't schedule creates refunds, not revenue.
Is preorder a core motion: drops, made-to-order, or a launch calendar that runs on it?
Yes: Your verdict: BUILD — own the selling-plan logic, deposit mechanics, and drop UX; at this centrality every app limitation is a business limitation.
No: Go to question 3.
Is a sellout costing you sales right now?
Yes: Your verdict: BUY — map preorder onto the affected products with an app this week, and diary a re-decision if preorder starts driving the calendar.
No: Your verdict: WAIT — keep alerts on the sold-out PDP and revisit when a launch or restock gap makes the wait worth selling.
The TCC Scorecard — 12 Dimensions
TCC — Total Cost of Capability: what it actually costs to have this capability over three years, whichever way you get it. Each dimension is scored 0–5 for both paths. How we score →
| Dimension | Buy | Build | Why |
|---|---|---|---|
| Cost | |||
| Acquisition & implementation | An app installs and maps onto products in a day or two; the custom selling-plan build runs an estimated 6–10 weeks (Deploi estimate, illustrative). | ||
| Recurring fees | Preorder apps commonly tier by preorder volume or take per-order fees, so the bill scales with every successful drop; the build's recurring line is upkeep. | ||
| Maintenance & upgrades | The vendor absorbs checkout and API churn on the buy path; the build owns selling-plan API version bumps and theme compatibility for preorder states. | ||
| Switching & exit | Open preorders, scheduled charges, and app-created selling plans make mid-flight migration a project; the build's policies already live in your store. | ||
| Risk | |||
| Vendor risk | A fragmented category of small vendors; a sunset or acquisition lands hardest when deposits and open preorders are mid-flight. | ||
| Security & compliance surface | Charge-timing and shipping-delay rules sit with the merchant on either path: published ship windows, delay notices, and refund options need process, not just software. | ||
| Platform-deprecation exposure | Selling plans (deferred purchase options) are the designed-for platform surface and both paths ride them; API versions cycle roughly every 6 months (per July 2026 research). | ||
| Value | |||
| Fit to requirement | Apps do badge-and-button preorder well; deposit ladders, drops calendars, per-variant ship windows, and made-to-order queues outgrow template settings. | ||
| Time to market | Days versus an estimated 6–10 weeks; if a sellout is bleeding demand right now, the app wins the sprint. | ||
| Performance & scale | Injected badge scripts and button swaps are a documented theme-update casualty; a build renders preorder state with the theme and holds up at launch traffic. | ||
| Data ownership & AI-readiness | Preorder velocity and deposit cash are production-planning and cash-flow signals; owned selling plans keep them queryable instead of dashboard-bound. | ||
| Focus & opportunity cost | A checkout-adjacent 6–10-week build is real roadmap weight; it only pays when preorder is a core motion, which is the whole verdict. | ||
The App Landscape
| App | Status | Pricing | Best for |
|---|---|---|---|
| Preorder Wolf | Live — Preorder-focused app with quick per-product setup | $0–40/mo band (illustrative) | Fast preorder buttons on selected products with minimal config |
| Timesact | Live — Preorder-first app with back-in-stock alerts alongside | $0–60/mo band (illustrative) | Deposits and partial payments without custom selling-plan work |
| Notify! | Live — Best-known standalone in the category; email, SMS, and push channels | Free–$40/mo band (illustrative) | One app covering notify-me and preorder on the same PDP slot |
| STOQ | Live — Restock-alerts specialist with waitlist reporting | $10–50/mo band (illustrative) | Stores led by restock alerts that want light preorder |
The Build Path
- Selling plans (deferred purchase options) + theme states: One selling-plan group per preorder policy (deposit percentage, charge date, ship window) applied per variant; PDP, cart, and checkout render preorder state server-side with estimated-ship messaging carried through to order status.
- Deposit and charge-later mechanics: Partial payment up front with the balance captured on schedule, riding Shopify's payment mandates; verify plan gating on deposits before committing the payment design (July 2026 research — re-verify).
- Drops and backorder mode: Scheduled availability, per-variant allocation caps, and preorder rolling into backorder when a restock is inbound; the same theme states cover both kinds of wait.
- Optional: ops and compliance glue: Ship-date changes trigger delay notices and refund options automatically, so the shipping-delay duty runs as a workflow instead of a support scramble.
- Effort band
- $15,000–$40,000 build (Deploi estimate, illustrative); typically the $25–75K contact-form band
- Typical timeline
- 6–10 weeks (Deploi estimate, illustrative)
- Maintenance, honestly
- ~$3,000–$8,000/yr, in line with the ~15–20%-of-build-cost norm (Deploi estimate, illustrative): selling-plan API version bumps, theme-update compatibility for preorder states, and checkout messaging tweaks. No subscription, no per-preorder fees.
- What you own — and what you take on
- You own: the selling-plan logic, deposit schedules, drop and backorder mechanics, preorder demand data, and every word of ship-date messaging. You take on: failed balance captures, delay-notice workflows, and the upkeep above.
3-Year Total Cost of Capability
| Buy (app path) | Build (custom path) | |
|---|---|---|
| Year 0 (setup) | $0–$300 | $15,000–$40,000 |
| Years 1–3 (recurring) | $1,400–$8,600 (subscription plus volume tiers) | $9,000–$24,000 (maintenance) |
| 3-year total | ≈$1,400–$8,900 | ≈$24,000–$64,000 |
- † All figures illustrative samples for the reference scenario — not quotes, not verified pricing.
- † App path: mid-band subscription held flat with no per-preorder fees counted, which is conservative for the build case.
- † Build includes deposit mechanics, drops-and-backorder mode, and delay-notice automation; three-year horizon.
What the Sticker Price Hides
On the buy path
- — Volume tiers and per-preorder fees scale the bill with every successful drop, so cost peaks in the week the feature earns (community-reported pattern)
- — Script-injected badges and button swaps are a known theme-update and breakpoint casualty (community-reported pattern); during a launch that's lost revenue, not a cosmetic bug
- — Charge-timing defaults are the app's, but the shipping-delay duty is yours; ship-date honesty and delay notices still need your process
- — Estimated-ship messaging coverage varies by tier across PDP, cart, checkout, and email, and the gaps surface as where-is-my-order tickets
On the build path
- — Deposit and charge-later mechanics are the hard 30% of the build: failed balance captures, partial refunds, and payment-mandate edge cases need real design
- — Plan gating on deposits and partial payments needs verification before the payment design is committed (July 2026 research)
- — Delay-notice and refund workflows are in scope, not an afterthought; skip them and the shipping-delay duty lands on your support queue
- — ~$3,000–$8,000/yr upkeep (Deploi estimate, illustrative), heavier than widget-class builds because checkout-adjacent surfaces keep moving
What Merchants Say
The launch-day failure shape: preorder badges and buttons vanish after a theme update or on mobile breakpoints, and merchants find out from customers mid-drop.
The pricing-surprise theme: plans that look cheap at install grow volume or per-preorder fees, so the bill peaks in exactly the week the feature earns its keep.
If You Change Your Mind Later
If you bought and outgrow it
Time the exit for a quiet window between drops: open preorders, scheduled balance captures, and pending ship dates have to land before the app goes. Orders and history stay in Shopify, but the app's policy config and messaging rarely export, so re-create policies on the replacement path and run one overlap cycle.
If you built and want out
Selling plans, orders, and deposit records already live in your store, so retreating to an app later means re-creating policies rather than rescuing data. Wind down after open preorders ship and the stranded asset is code, not customer promises; the exit cost stays small for a checkout-adjacent capability.
When This Answer Changes
We're watching for:
- ▸ Shopify shipping first-party preorder UX on top of the selling-plan APIs, such as native badges or PDP states (none as of July 2026 research)
- ▸ Plan gating on deposits and partial payments loosening or tightening
- ▸ Charge-timing and shipping-delay rules shifting; recheck notice and refund workflows with counsel whenever they move, on either path
Verdict change log:
No changes since first publication (August 2026).
Common Questions
Can Shopify take preorders without an app?
Partly. Selling plans, Shopify's deferred purchase options, are the platform surface designed for preorder: deposits, charge-later, and deferred fulfillment are API-supported (July 2026 research). What's missing natively is the merchandising layer: badges, buy-button states, estimated-ship messaging, and mixed-cart handling. That layer is exactly what preorder apps sell and what a theme build re-creates, so the real question is who supplies the UX on top of the platform's plumbing.
Should preorders charge now or charge later?
Deposits collect cash up front and commit the buyer; charge-later reduces refund work when dates slip but banks nothing until fulfillment. Illustrative math: a 30% deposit on a $100,000 drop puts $30,000 in the bank before production starts (illustrative). Charge-timing and shipping-delay rules apply on either path, so publish honest ship windows, send delay notices, and offer refunds when dates move. Pick the flow your operations can keep promises on.
How is preorder different from back-in-stock alerts?
A back-in-stock alert collects intent and notifies shoppers when inventory returns; a preorder takes money now and turns the wait itself into a sale. Alerts are lighter: no charge-timing duties, no ship-window promise, often bundled with your email platform. Preorders bank deposits and firm up demand before production. The fork is one question: can you commit to a ship window and take money against it? If yes, sell the wait; if not, notify it.
Your Next Steps
If you're going with BUY
- Shortlist from the preorder category and verify current pricing, volume tiers, and per-preorder fees
- Test PDP, cart, and checkout messaging on your live theme and on mobile before the first real drop
- Set charge timing deliberately and write the ship-date and delay-notice process down; the duty stays yours
- Cap the blast radius: run the first preorder on one product family and watch fulfillment statuses
- Diary a re-decision when preorder crosses roughly 20% of revenue; the build math will have moved
If you're going with BUILD
- Inventory your preorder policies: deposit percentages, charge dates, ship windows, and allocation caps per variant
- Verify plan gating on deposits and partial payments before committing the payment design (July 2026 research)
- Scope selling-plan groups first, then the theme states: PDP, cart, checkout, and order-status messaging
- Design the failure paths early: failed balance captures, date slips, delay notices, and refund options
- Ship one drop end to end before migrating the whole catalog's preorder motion
Official Docs & Sources
- Purchase options (subscriptions, preorders, try-before-you-buy) — Shopify Help Center
- About subscriptions — shopify.dev
Official documentation linked for verification — our verdicts and estimates are our own.
Related Decisions
Timesact vs. Preorder Wolf: Best Shopify Preorder App?
Timesact wins deposit-led preorder programs; Preorder Wolf wins the simple flip-to-preorder case; native inventory policy covers plain backorders free.
Multi-Location Inventory on Shopify: Build, Buy, or Wait?
Multi-location inventory is a WAIT: native locations and routing rules cover most mid-market networks free; pay for an IMS only when planning outgrows sheets.
Build or Buy Barcode & Warehouse Ops on Shopify?
Buying wins for barcode and warehouse ops on Shopify: scanning tools and WMS platforms are solved software, and the only build lane that pays is integration glue.
Build or Buy Cycle Count Tooling on Shopify?
Cycle counts on Shopify favor customize: native inventory stays the record; a bounded count layer replaces a full IMS subscription.
Build or Buy Inventory Forecasting on Shopify?
Buying wins for inventory forecasting on Shopify: purpose-built apps model seasonality and lead times, and custom models only pay with warehouse-grade data maturity.
Ready to sell the wait?
If preorder is a patch, we'll help you pick and wire an app without the launch-day surprises. If it's your calendar, we'll scope the selling-plan build that owns deposits, drops, and dates. Honest call either way.
Contact us todayVerdict scored for the reference scenario above. Estimates are not quotes; app pricing carries its verification date and gets re-verified quarterly. Full scoring anchors: see the TCC methodology.
Read how we score these decisions (the TCC Framework). No affiliate links, no paid placement — no app vendor pays to appear here.