Backorder & Preorder on Shopify Plus: How I approach it

When a client comes to me with this requirement, the first thing I do is understand the context before thinking about any solution.

A few questions I always go through:

How big is the catalog? Are we talking 50 products or thousands of variants across hundreds of SKUs? That number alone rules out entire categories of solutions.
Is there an ERP or WMS in the picture? If delivery times come from an external system, anything that stores static text is already off the table.
What's the deadline? A client who needs to launch in a week and a client who's planning a proper implementation in a month are two completely different conversations.
What's their budget? An app costs between $20 and $100 a month. A custom solution costs development time, and then maintenance. For a store that's just starting out or running lean, the app is almost always the right economic decision. Custom development makes sense when the requirements genuinely can't be solved any other way, not because it sounds more professional.
And finally: where does this fit in their roadmap? Is this a one-off feature that will never change, or is it the first piece of a bigger custom checkout experience? That changes how much I invest in the architecture.

What the answers tell me

Small catalog, no ERP, tight deadline, early-stage store

An app like Globo Pre-Order or Timesact will get them live in a day. Built-in emails, waitlists, partial payments. No reason to build anything custom.

Large catalog, data coming from external systems, high revenue, team that will keep building

This is where the native Shopify architecture makes sense. Here's how I structured it for a client in that situation:

A dedicated Shopify location for backorder inventory: The ERP integration writes stock there via the Admin API using inventoryAdjustQuantities. Nothing special about this location from Shopify's perspective, it's just another warehouse. But it gives you a clean separation: if a product has inventory here, it's a backorder item. That flag drives everything downstream.
inventoryPolicy continuation: Optionally, set inventoryPolicy: CONTINUE on the relevant variants so they stay purchasable when stock hits zero. Whether you do this depends on the business rules. Some merchants want a hard cap, others want open-ended backorders.
Metafields per variant for the real delivery time: The WMS writes the actual ETA here on each sync. Not a static "ships in 21-30 days" string, the real date. This is what makes the whole thing honest to the customer.
Theme customization: Check at render time whether the product has stock in the backorder location, and if it does, show the right UI: a different button label, the delivery time from the metafield, whatever the merchant needs. This logic lives in the theme and is entirely in your control.
Checkout Extension: Surface backorder information before the customer pays. If their cart has a mix of regular and backorder items, they see it clearly at checkout. No surprises after the order is placed.
Cart line item properties: Mark which specific items in an order are backorder. This makes life easier for whoever processes fulfillment downstream, whether that's a warehouse team or another integration consuming the order data.
Shopify Flow: A flow triggered on order creation. It checks which items came from the backorder location and tags the order accordingly, something like backorder, so it gets routed differently. What happens after the tag depends entirely on the client's fulfillment process. Could be a manual review queue, could be an integration that pauses those items, could be a notification to the warehouse. The tag is the handoff point.
Location priority: In Settings → Shipping and delivery, Shopify lets you define the order in which locations are used to fulfill orders. Your backorder location must be last. If it has higher priority than your real warehouses, Shopify will pull stock from it even when inventory is available elsewhere, which defeats the entire purpose of the separation. Set it once and leave it there.

I recently went through this with a client at the larger end of that spectrum. Over a thousand variants per product family, delivery times owned by their WMS, serious monthly revenue. The app conversation lasted about five minutes before we moved on to scoping the real solution.

The thing about apps

They're not a lesser solution. For most stores they're the right call. The mistake I see is when someone skips the diagnosis and jumps straight to custom development because it feels more serious. It's not more serious, it's just more expensive and slower.

The diagnosis is the work. The solution usually follows naturally.