Modelling made-to-order and lead times in Shopify

"Made to order" covers at least three arrangements that need different builds, and the first hour of any of these projects is spent establishing which one you have.

Built on receipt of order, from stocked components. A sofa in your choice of fabric, a bike built to a spec. The constraint is workshop capacity and the lead time is reasonably predictable — four weeks, plus or minus a few days.

Ordered in on demand. You do not hold it, your supplier does, and the lead time is theirs plus your handling. Predictable until it is not, and the failure mode is a supplier who stops answering.

Genuinely bespoke. Measured, quoted, scheduled. There is no meaningful lead time until somebody has looked at the job, and trying to display one is a promise you will break.

The third is not an ecommerce problem, and the most useful thing you can do with it is stop trying to sell it through a buy button. An enquiry form that captures enough to quote, followed by a draft order, is faster to build and more honest than a product page with a number on it that your workshop does not recognise. Several of the projects we are proudest of ended with fewer products on the storefront than they started with.

The most common starting point is a line in the product description: "Please allow 4–6 weeks for delivery." It is invisible to every system you own. The storefront cannot turn it into a date, checkout cannot reason about it, the confirmation email cannot repeat it, and your support team ends up being the integration layer.

The fix is a metafield definition on the product or variant, typed as a number of days rather than a piece of text. Type is the strongest commitment a definition makes: a numeric field can be compared, added to today's date, and sorted on; a text field holding "4–6 weeks" can only be printed. Where a range is genuinely the truth, hold two fields — a minimum and a maximum — and let the storefront decide how to say it, rather than storing the sentence.

Two more fields usually earn their place. A cut-off — the time of day after which today no longer counts — because the difference between ordering at 10am and at 6pm is a real day for the workshop and a real day for the customer. And a capacity or batch marker, where production runs in weekly slots rather than continuously.

With that in place the storefront can render a date rather than a duration, which is the thing that changes behaviour. "Ships by 14 July" is a different sentence from "4–6 weeks", even when they describe the same fact, because the shopper does not have to do arithmetic to find out whether it arrives before the birthday.

Getting the calendar right is where this stops being a template change: the date has to skip non-working days and honour whatever your workshop actually does in August. That logic belongs in one place, computed from the fields, and used by every surface — never re-implemented in the theme, the email template and the ERP separately, because those three will drift and only the customer will notice.

Shopify's inventory model counts units at locations. If what limits you is units, use it. If what limits you is throughput — four units a week, regardless of how many orders arrive — an inventory number is the wrong instrument, and stores that force the fit find out in a peak week.

The two workable positions for a made-to-order line are straightforward. Either stop tracking inventory on it, so the product is always buyable and the lead time is the only constraint communicated; or track it and enable "Continue selling when out of stock", which keeps it buyable while preserving a count you can read. The second is better if anything downstream — a report, an ERP, a 3PL feed — needs the number, and it needs a clear rule about what a negative available quantity means to the people who will see it.

What neither does is protect you from taking more orders than you can build. That is a capacity problem, and it is solved by scheduling rather than by stock: a weekly batch size, a queue depth, and a lead time that grows as the queue does. The version of this that works on Shopify is unglamorous — the lead-time field is maintained by whoever runs production, weekly, because the number is a commitment their team has to keep. Automating that from an ERP is possible and is usually the second project, not the first.

Shopify has first-class support for purchases that are paid for now and fulfilled later. The selling plan categories it documents are SUBSCRIPTION, PRE_ORDER and TRY_BEFORE_YOU_BUY, with OTHER available by request. For made-to-order work the relevant one is PRE_ORDER, and it brings a few decisions with it.

A delivery policy sets when fulfilment is expected: as soon as possible, at an exact time, or unknown where the timeline depends on other conditions. That last option is a more honest model than most stores admit to needing. Delivery and billing policies have to be consistently fixed or recurring, and the documentation is direct that pre-orders use fixed policies.

The setting that matters most operationally is the inventory policy: inventory can be committed when the order is created, or when it is fulfilled. Committing on sale means a pre-order reserves a unit for that buyer. Committing on fulfilment means it does not, and a later customer can take the slot. Neither is wrong; picking without deciding is.

If you are taking a deposit and charging the balance later, the remaining balance is charged through orderCreateMandatePayment, which is idempotent and requires a unique idempotency key. The documentation is explicit that scheduling the charge at the right time and automating the process around payment failures is the app's responsibility, not Shopify's. That is the sentence to read twice before scoping a deposit model — the hard part is not taking the second payment, it is what happens on the ones that fail.

And read the incompatibilities before designing anything around this. Deferred purchase options are documented as incompatible with local payment methods, Shopify POS, draft orders, B2B and "Buy X get Y" discounts, and supported on a short list of gateways. If you sell B2B, or your best market runs on a local payment method, the decision has been made for you.

Checkout is where a lead time gets contradicted. The product page says six weeks; checkout offers "Express — 1 to 2 business days", and the shopper reasonably concludes one of the two is wrong.

The lever is a delivery customisation function, which can rename a delivery option, reorder the list, or hide an option entirely. Renaming "Express" to something that describes dispatch rather than transit removes most of the confusion on its own. Hiding an option is the right move where a courier speed is meaningless for a product that has not been built yet.

Three documented constraints shape what you can do. Carrier names are prepended automatically and cannot be removed. When reordering, the cheapest option has to stay first. And there is a maximum of 25 delivery customisation functions per store — generous, but worth knowing before somebody proposes one per product line. The function also applies to checkout only, so the cart and any draft order route need their own answer.

One stocked item, one six-week item, one order. Every made-to-order build meets this, most meet it after launch, and there are only three defensible answers: ship it all when the slow item is ready, split the shipment, or stop the combination from happening at the cart. Pick one deliberately and say so on the product page and in the cart, because the default — silence, then a customer service conversation — is the expensive option.

Splitting is usually right for the customer and usually the most work: two fulfilments, two tracking numbers, a shipping cost you have decided who pays for, and an order status page that has to explain it. Holding everything is cheap to build and produces the worst emails. Preventing the combination is honest and loses baskets.

The part nobody budgets for is that this model needs maintaining. Lead times move. A supplier slips, a machine goes down, August happens. A store where the number on the product page is corrected every week is telling the truth; a store where it was set at launch is publishing a promise nobody has checked in eight months, and the cost lands on your support inbox before it lands on your reviews. That ongoing correction is most of what [ongoing Shopify support](/services/support) is for on a made-to-order catalogue — less building, more keeping one number true.

• Ongoing Shopify support and store management
• Fulfilment SLAs and what your storefront should promise
• Metafield definitions as an API contract