Why Inventory Apps Charge by Order Volume (And Why That Makes No Sense)

The pricing model nobody questions

Open any Shopify inventory app's pricing page and you will see some version of the same structure: a free or cheap tier with a low order cap, then progressively more expensive tiers as your monthly order count goes up. Some apps charge by "orders per month." Others use "sales volume" or "transactions." A few get creative and limit POs per month instead.

The implicit message is that more orders means more work for the system, which justifies a higher price. It sounds reasonable until you think about what inventory planning actually does.

What inventory planning actually computes

At its core, inventory planning answers two questions for every SKU you carry:

When should I reorder? (the reorder point)
How much should I order? (the order quantity)

To answer those questions, the system needs to:

Calculate average daily demand per SKU
Measure demand variability per SKU
Factor in lead time and lead time variability per supplier
Apply a service level target to derive safety stock
Compare current inventory to the reorder point

Every one of those calculations scales with SKU count. If you have 200 SKUs, the system runs the math 200 times. If you have 2,000 SKUs, it runs 2,000 times. The computational work, the data storage, and the complexity of the output all scale with how many products you are planning.

Notice what is absent from that list: how many orders your customers placed last month.

Why order volume does not affect planning complexity

Consider two stores:

Store A sells 200 SKUs and processes 500 orders per month. Average daily demand per SKU is low, variability is moderate.

Store B sells the same 200 SKUs but processes 5,000 orders per month. Average daily demand per SKU is higher, but the planning math is identical. Same number of reorder points to calculate. Same number of safety stock figures. Same number of supplier lead times to track.

The only difference is that Store B's average daily demand numbers are bigger. But a spreadsheet cell that says "=AVERAGE(B2:B91)" does not care whether the average comes out to 2 or 20. The formula is the same. The computation is the same. The output is the same format.

Store B is not harder to plan for. It is not more complex. It does not require more server resources. It just has bigger numbers in the same cells.

So why is Store B paying 3x more for the same planning tool?

The real reason apps charge by order volume

Order volume is a proxy for revenue. A store processing 5,000 orders per month is almost certainly generating more revenue than one processing 500. By tying pricing to order volume, the app captures a share of the merchant's growth without delivering proportionally more value.

This is sometimes called "value-based pricing," and in some contexts it makes sense. A payment processor that handles more transactions does more work with each additional transaction. A shipping app that processes more labels has higher marginal costs.

But an inventory planning tool does not do more work when your sales go up. It does more work when your SKU count goes up, when your supplier count goes up, or when you add warehouse locations. Those are the dimensions that actually increase planning complexity.

The same problem with per-user pricing

Some apps charge more as you add users. This makes sense for collaboration tools where each user consumes server resources, storage, and support bandwidth. It makes less sense for inventory planning.

The planning math does not change based on how many people look at the output. Whether one person reviews the reorder report or five people do, the system calculated the same number of reorder points. The data is the same. The PO suggestions are the same.

Per-user pricing for planning tools is another proxy for company size and willingness to pay. A store with five people involved in purchasing decisions is probably bigger than one where the owner does everything. But the planning complexity is driven by the inventory, not the org chart.

The PO-per-month trap

One pricing model that deserves special attention: charging by the number of purchase orders you generate per month.

This one is particularly problematic because it creates a perverse incentive. Good inventory planning sometimes means placing more frequent, smaller orders to reduce holding costs and improve cash flow. If your app charges you more for generating more POs, it is penalizing you for following sound inventory management practice.

Seasonality makes this worse. Some months you place more orders because demand is ramping up for a peak season. The planning tool is doing the same math either way, but you are paying more during the months when you are already spending more on inventory.

What pricing should actually reflect

If an inventory planning app priced based on actual complexity, the tiers would look something like this:

Tier	Based On	Why It Makes Sense
Starter	Up to 500 SKUs	Small catalog, simple planning
Growth	501 to 1,500 SKUs	More products to track and calculate
Pro	1,501 to 5,000 SKUs	Significant catalog complexity
Enterprise	5,000+ SKUs	Large catalog, multi-location complexity

Add-ons could include things that genuinely increase system complexity: multi-location planning, multiple sales channels (B2C, wholesale, retail), supplier portal integrations, or API access for custom workflows. Just like additional warehouse locations legitimately increase planning complexity, so do additional sales channels, because each channel can have different demand patterns, fulfillment rules, and inventory allocation logic. Those features require real engineering and infrastructure.

But the base tier should be driven by what the system actually has to compute, not by how successful your store happens to be.

What this means for you

If you are shopping for a Stocky replacement right now (and you should understand what Stocky actually did before you commit to anything), look at the pricing page through this lens:

Ask: What am I actually paying more for at the next tier?

If the answer is "more orders" or "more users" but the planning features are identical, you are paying a growth tax. The app will get more expensive as your store succeeds, without giving you proportionally more capability.

Ask: What is my cost per SKU?

Take the monthly price and divide by the number of SKUs you need to plan. If you are paying $99/month to plan 200 SKUs, that is $0.50 per SKU per month, or $6 per SKU per year. Is the planning output for each SKU worth $6/year to you? Maybe. But it is worth doing the math rather than just accepting the sticker price.

Ask: What happens when I have a great month?

If a strong sales month pushes you into the next pricing tier, you are being charged more during the exact period when your cash flow is already stretched by inventory purchases. That is the opposite of aligned incentives.

The spreadsheet advantage

One reason a well-built spreadsheet remains competitive for stores under 500 SKUs: the cost does not scale with anything. Your order volume can double, your team can grow, you can place POs every day, and the spreadsheet does not care. The math is the same. The cost is the same.

The tradeoff is that you are doing the data export and PO execution manually. For a store with a handful of suppliers and a weekly ordering cycle, that is a few minutes of work. For a store with 30 suppliers and daily ordering, it is not practical.

But for the majority of Shopify merchants who are being pushed from a free tool to a $100+ monthly subscription, the honest answer is that a spreadsheet handles the planning math just as well, and the pricing model is the simplest one possible: you already own it.