Your Daily Limit Is Counting the Wrong Day

If you make things to order, you have a number in your head. Twelve cakes a day. Forty catering portions on a Saturday. Sixty bouquets on Valentine's Day. It is not a preference — it is the number of hands, ovens and hours you actually have.

So you find an app that limits orders per day, you set it to twelve, and within a month you are back to taking orders by phone.

Here is why.

Two different days

When a customer orders a cake on Monday for collection on Friday, that order has two dates attached to it. Monday, when it was placed. Friday, when it has to exist.

Nearly every order-limiting tool counts Monday. That is the right day to count if your constraint is how many orders you want to handle today — a shop catching up on a backlog, or a solo maker who does not want fifty notifications in a morning.

But if your constraint is your kitchen, Monday tells you nothing at all. Friday is the day with the ceiling. And by the time Friday arrives, the orders were taken days ago, in ones and twos, on days that all looked quiet.

You end up with the worst of both. Monday looks fine, so nothing stops the orders. Friday is oversold, and you find out on Thursday night.

What that week actually looks like

Take a bakery with a ceiling of twelve decorated cakes a day, and a limit set to twelve by order date.

Not one day broke the limit of twelve. Every day looked comfortable. Friday is three cakes over, and nothing in the storefront noticed, because nothing in the storefront was counting Friday.

This is the shape of the problem and it is why "set a daily limit" advice does not help. The limit was on. It was just pointed at the wrong day.

The spreadsheet stage

Most merchants we talk to have solved this the same way, and it is always some version of a spreadsheet.

A tab per week. A row per production day. A number you update by hand every time an order comes in, usually in the evening, usually from memory. It works, in the sense that a thing which requires you personally to be correct every single day works.

The failure mode is not that the spreadsheet is wrong. It is that the storefront does not know about it. The spreadsheet says Friday is full; the website carries on selling Friday. So you add a note to the product page — "Friday orders may be limited, we'll be in touch" — and now you are refunding people and apologising for something you already knew.

Or you take the other route, which is to stop selling those items online. Which is to say, the constraint has now cost you the channel.

Count the day the work happens

The fix is not a better spreadsheet. It is counting the other date.

If "twelve a day" means twelve for the day it is collected, everything lines up. An order placed on Monday for Friday counts against Friday. An order placed Thursday night for Friday counts against the same Friday — and if it is the thirteenth, it does not go through.

The number in your head and the number the storefront enforces become the same number. Nobody has to remember to update anything.

This is what OrderRules now does. On the Advanced plan, with delivery dates enabled, any product's daily limit can count against the delivery date the customer picks instead of the date they ordered. It is one setting on the product: Count daily limits by — order date or delivery date.

Four details that matter more than they sound

Variants count separately. A medium cake and a large cake are not the same work, and a single number across both is no better than no number. Set ten medium and fourteen large on the same product, and each is capped on its own. Variants without their own limit fall back to the product's.

Pickup and delivery share the capacity. Ten is ten. It does not matter whether the customer is collecting or having it sent — the oven does not care, so the cap does not either. If you run in-store pickup alongside delivery, this is usually what you want; a shared ceiling is the one that matches the kitchen.

Shoppers are stopped at the calendar, not at checkout. When someone picks a date, they see how many are left for it. A date that cannot hold what is in their basket simply is not selectable. Turning someone away at checkout, after they have chosen and committed, is a worse experience than not offering the date at all — and it is a lost sale where a nudge toward Saturday might not have been.

Cancellations give the slot back. If a Friday order is cancelled, Friday can take another one. Obvious, and worth stating, because capacity that only ever decreases is a slow leak that ends with a full day that is not.

What to set the number to

The temptation is to set it to your theoretical maximum. Resist that, for two reasons.

The first is that your maximum assumes a day where nothing goes wrong — no sick staff, no oven fault, no wedding cake that takes twice as long as quoted. A cap at the maximum is a cap that is correct only on good days.

The second is the concurrency window described at the end of this post. On a date capped at six, a place of headroom costs you one sale and removes the only scenario where the cap can be passed. On a date capped at sixty, it is noise. The smaller the number, the more the headroom is worth.

A practical starting point: set it slightly below the number you would say out loud, run it for two weeks, and look at which dates actually filled. Raising a cap that turned out to be conservative is a pleasant problem. Lowering one after a bad Saturday is not.

Other shapes of the same constraint

Cakes are the clearest example but not the only one.

• Caterers have a Saturday that holds a fixed number of events regardless of when they were booked — see Shopify for catering and event businesses.
• Florists have Valentine's Day and Mother's Day, where the ceiling is set by hands and stems weeks before the orders arrive.
• Made-to-order and small-batch makers sell capacity rather than stock, which is its own operational discipline — covered in made-to-order lead times and production caps.
• Restaurants taking pre-orders have a lunch service with a number, and pickup and delivery both eat into it.
• Furniture and large goods have crews rather than ovens, and the cap is really about how many drops a van can complete — see Shopify for furniture brands.

If your constraint is per slot rather than per day — a 10:00–12:00 window that holds four deliveries — that is a different setting: delivery capacity limits cap each date and each time slot on the availability rule rather than on the product. The two work together, and plenty of stores need both.

How this sits alongside lead time and cutoffs

Delivery-date limits answer how many. Two neighbouring settings answer which days are offerable at all, and they run before the cap does.

Lead time removes dates that are too soon. If a decorated cake needs three days, Friday stops being selectable on Wednesday regardless of how much Friday capacity is left. Set this from your real build time, not your best case.

Order cutoff decides where today ends. If your production list is drawn up at 2pm, an order at 2:15 for tomorrow is really an order for the day after — an order cutoff time makes that explicit instead of leaving it to whoever reads the list.

The order of operations is worth knowing: lead time and cutoffs decide which dates a shopper is shown, and the delivery-date cap decides how many of them each date can still take. A date can disappear from the calendar for either reason, and the message the shopper sees differs accordingly.

If you also show an estimated delivery date on product pages, that estimate is a display of the same lead-time arithmetic — it tells shoppers when a date would land, while these caps decide whether that date is still open.

When you actually want the order date

Worth saying plainly: delivery-date counting is not the better option, it is the other option.

If your limit describes how many orders you want to take — throttling while you are short-staffed, capping a launch, keeping a new product's volume manageable — order date is the correct basis and always was. That is a rate limit on incoming work, and incoming work arrives on the day it arrives. Daily order limits counted by order date are the right tool there.

The question to ask is what the number protects. If it protects your time today, count the order date. If it protects a day's output, count the delivery date.

Weekly and monthly limits keep counting by order date either way. Only the daily limit switches, because "this week" is a period, while "Friday" is a specific day with a specific kitchen in it.

Setting it up

If you already have delivery dates turned on, this is about a minute of work:

1. Open a product in Products
2. Under Count daily limits by, choose Delivery date
3. Set the daily quantity — on the product, or per variant
4. Save

Select several products first and it applies to all of them. It travels in CSV export and import too, so a whole catalogue can be set in one pass.

The Products table then shows your most constrained upcoming date for each capped item — Fri 14 Nov · 9/10 — rather than a usage percentage, because a percentage would be meaningless. Usage here is a series, not a number: one figure per upcoming date. A product can sit at zero percent today while next Saturday has nothing left.

The honest limit

One thing this does not do, and we would rather say so than have you find out.

Two customers checking out within the same second, for the same date, with one slot left, can both get through. Checkout validation reads a snapshot of what is booked, and cannot hold a lock the way stock does. In practice it needs near-simultaneous checkouts on a date that is down to its last slot, so it is rare — but it is not impossible, and an app that claims otherwise is claiming something the platform does not offer.

That is also why the headroom advice above is worth following on small caps. It is a cheap way to remove the only case where the number can be passed.

What it does do is make the storefront and your production schedule the same thing, without you maintaining both. For most days, on most weeks, that is the difference between selling online and not.

Where to go next

• Limits by delivery date — the setup docs, including variants, CSV and cancellations
• Getting started with delivery dates — required before this setting appears
• Per-product limits — the daily limit whose basis this changes
• Delivery capacity limits — per-date and per-slot caps on the availability rule

Delivery-date limits are on the Advanced plan and require delivery dates to be enabled. See the docs →