How to choose a Shopify inventory app for a small catalogue

Buy the smallest tool that closes a gap you can name in one sentence.

For most Shopify stores between 50 and 2,000 SKUs, the gap is not planning. It is noticing. You already know roughly what sells. What you do not know is that a hero SKU crossed its reorder line last Tuesday, and your supplier needs three weeks.

So the real decision is not which inventory app is best. It is which layer you are buying: alerting, purchasing, planning, or a whole record system. Pick the layer first. Compare only inside it. An alerting app at a few tens of dollars a month and a planning suite priced per seat are not competitors, and a shortlist that mixes them stalls for weeks.

If you are here because a tool you relied on left your stack, do not replace it feature for feature. Replace the job it did. In a small catalogue that job was usually one line: tell me what to order this week, before the shelf is empty.

The rest of this guide runs the decision in order. Name the failure. Size the catalogue. Write down supplier lead times, then decide how much buffer you want on top. Learn the five categories. Ask the questions that separate apps that look identical. Then test one full reorder cycle before you pay anyone.

The app store puts all of these under one word. They solve different problems and cost different money.

Reorder alerting

Watches stock against a reorder point and tells you when a SKU crosses it. Inputs are sales velocity, supplier lead time and whatever buffer you set. Output is a warning and a list. Cheapest layer, fastest to set up, and the one that fixes the noticing problem.

Purchase order management

Builds and sends POs, tracks what is on the water, receives goods against the order and reconciles short shipments. Useful once several people buy from several suppliers. It assumes you already know what to order.

Demand planning and forecasting

Projects future demand from seasonality, trend and promotions, then recommends buy quantities and budgets. Powerful for stores with real seasonal swing and a buyer to interpret it. Expensive, and the output is only as good as the history you feed it.

Multi location and multichannel sync

Keeps one stock pool honest across warehouses, retail locations and other sales channels. If you sell the same unit in three places, this is the problem that bites first, and an alerting tool alone will not solve it.

ERP and full inventory systems

One set of records for purchasing, stock, costing, fulfilment and finance. This is an implementation, not an install, and it usually needs somebody whose job it is.

Most merchants searching for an inventory app want the first category, occasionally the second. Knowing that before you open a comparison tab saves a fortnight.

You have moved past the alerting layer when stock lives in more than one place and allocation between them is a decision, when several buyers lose money to duplicate orders more often than to stockouts, or when landed cost has to be accurate per batch. Those are structural signals, not size signals. The page in this section on running Shopify inventory without an ERP takes that argument further, and the page on a 1,000 to 2,000 SKU catalogue covers what changes at the top of this range. If you want the options set against each other by name, this section compares Restoc with Inventory Planner by Sage, Cogsy, Prediko, Assisty, Merchbees Low Stock Alert, Cin7, Linnworks and Brightpearl by Sage.

Two listings can use the same words and behave nothing alike. Ask these in the trial, or in a support message before it.

How is sales velocity measured, and can you change the window?

A seven day window reacts fast and jumps around after a promotion. A thirty day window is calm and slow to notice a new bestseller. Fourteen sits between them. The right answer depends on your range, so the ability to choose, and to change your mind later, matters more than the default. Ask whether the window is one setting for the whole store or can be overridden on individual SKUs. If overrides are a paid tier, price them at the tier you would be on.

Where does lead time come from, and how many times must you type it?

If the app never asks how long your supplier takes, its reorder point is a guess dressed as maths. Look for lead time as an input you control. Then ask the practical question: can you set it once per supplier and have it apply to that supplier's SKUs, or does someone open hundreds of rows and save them one at a time? Nobody finishes the second version, which means the reorder points stay wrong for most of the catalogue.

Does the reorder point carry a buffer, or only average demand?

A reorder point built from average velocity times lead time holds up on an average week. Items that sell in bursts are the ones that strand you. Ask whether the tool supports safety stock on top, and whether it shows the buffer in units rather than burying it in a formula. If the answer is no, you will be adding days to lead times to fake it.

Is the threshold per SKU or one number for the whole store?

A single store wide low stock number will either spam you about slow movers or stay silent on the fast ones. Per SKU thresholds, derived from that SKU's own velocity and lead time, are the difference between a tool you keep and a tool you mute.

How is the alert delivered, and what stops duplicates?

Email, a chat channel, or both. Check which of those is included on the tier you intend to buy rather than on the top tier in the screenshot. Then ask what happens when the job runs again. Does the same crossing fire twice? Duplicate alerts are the fastest way to train a team to ignore the channel.

Is there a report you can act on, or only a screen you must remember to visit?

A weekly list of what sits below its reorder point, with a suggested quantity, is a buying session. A dashboard alone is a thing you check when you already suspect a problem. Check what each row carries: your own SKU code, because that is what goes on the supplier order, and the supplier, because one weekly list has to split into several orders before anything gets sent.

What is metered, and what happens at the cap?

SKUs, orders, locations or stores. Find the cap, then find out what the app does when you pass it. Ask whether the limit is enforced openly at sync time with an upgrade prompt, or whether the SKUs past the line are quietly dropped.

What happens on install?

Two answers decide how long you wait for anything useful. First, does the app bring your sales history with it, or does it start counting from the day you connect? A velocity window needs sales inside it, so an app that only counts forward shows every SKU as having no velocity, and fires no alerts, until enough orders accumulate. Second, how much of your catalogue does the first sync actually read, and does it tell you? Shopify hands the product list back a page at a time, so ask how many SKUs each candidate reported after its first sync and check that against your variant count. Ask both before you install, not in week three.

Pricing in this category spreads wider than the feature sets do, because vendors aim at different sized businesses with similar words.

Alerting and reorder tools are usually priced per month against a SKU ceiling, in the range a small store can approve without a meeting. Planning and forecasting suites are priced against revenue, order volume or seats, and they generally assume someone is paid to use them daily. ERPs are priced as contracts. If a quote needs a call to obtain, you have left the layer this guide is about.

Four things to check before you compare numbers.

• What the cap counts. Products and variants are not the same thing. A 400 product catalogue with three sizes each is 1,200 variants, and most apps meter variants.
• Which tier holds the feature you came for. Chat delivery, per SKU overrides and extra locations are common tier dividers. Price the tier that contains your must have, not the entry tier.
• What annual billing actually saves. A year up front for the price of ten months is a common shape. It is only a saving if you are still using the tool in month eleven, which is an argument for proving the thing on a monthly plan first.
• How the charge reaches you. An app on Shopify's native billing puts the charge on your Shopify invoice, approved once in your Shopify admin, and your card details stay with Shopify. An app billed on a separate card creates another line in the bank feed and another renewal nobody is watching.

One caution on the value case. It is easy to talk yourself into an expensive tool by multiplying a hypothetical lost sale by a hypothetical number of days. Running out of a hero SKU is a genuine financial hit and worth taking seriously, but nobody can promise you a figure. Judge the tool on whether it would have told you in time, not on a savings calculation.

Most trials fail because the merchant installs the app, looks at a dashboard, feels vaguely reassured, then forgets about it until the card is charged. Run yours as a test with a pass condition.

Pick your test SKUs first

Choose three: one fast mover, one slow mover, and one with a long or unreliable supplier. These three will expose whether the velocity window suits your range and whether the lead time input is doing real work.

Check what the first week is built on

A velocity figure needs sales inside the window to mean anything, so ask each candidate how much history it starts with. Restoc's install is built to bring historical sales data across with your catalogue rather than counting forward from connect time. Whichever app you trial, check an early velocity figure against a SKU you know by heart, and confirm the SKU count the app reports matches your variant count in Shopify.

Enter the awkward lead times honestly

Not the number the supplier's website claims. The number your last three orders actually took. If the tool takes one figure per supplier, do the suppliers first and override the handful of SKUs that behave differently. If it only takes a figure per SKU, as Restoc does today, start with the lines that would hurt to lose and work down.

Set the buffer before you judge the quantities

Decide your safety stock up front, then read the suggested quantities with that assumption visible. Where the tool has no buffer setting, note how much of each suggested order is cover rather than demand and do that arithmetic on paper once, so you know what you are missing.

Wait for a real crossing

The pass condition is an alert that arrives before you would have spotted the problem yourself, reaching the person who can act on it. If you learn about a low SKU from a customer email during the trial, the tool failed the test regardless of how good the interface looks.

Read one weekly report as if you were placing the order

Go down the list and ask, for each line, would I sign this purchase order. Where a suggested quantity is wrong, work out why: too short a velocity window, a lead time you understated, too little cover, or a seasonal spike the tool cannot see. The first three you can fix in settings. The fourth tells you honestly whether you need the planning layer after all.

Check what it does at the edges

A SKU with no sales at all, a SKU already at zero, and a product you added last week with almost no history. Those are the cases a reorder formula gets wrong quietly, so they are the ones worth testing deliberately.

Know when the first charge lands

A trial long enough to contain a full weekly cycle is the minimum. Anything shorter tests the onboarding, not the product. Restoc's trial runs 60 days and is built so at least one full weekly reorder cycle completes before the first charge, with annual billing offered as an option at signup. The charge goes through Shopify's native billing, so you approve it in your Shopify admin and it appears on your Shopify invoice. There is a separate page in this section on the trial and when the first charge falls, and another on what a small store pays.

Take this to the app store tab you already have open.

• The failure I am fixing, in one sentence, is written down.
• I know my variant count, not my product count.
• I have realistic lead times for my top suppliers on paper.
• I know which layer I am buying, and my shortlist contains only that layer.
• Each candidate lets me set the sales velocity window, or tells me plainly what it uses.
• Each candidate takes lead time as an input I control, and I know how many times I have to type it.
• I know whether the reorder point can carry a buffer on top of average lead time demand, and whether that buffer is visible in units.
• Thresholds are per SKU, not one number for the store.
• Alerts land where the responsible person already looks, and repeat crossings do not spam.
• The tier I priced includes the delivery channel I need, not just the one above it.
• There is a weekly list I can act on, with quantities and an export.
• I know the SKU cap, the price at my twelve month SKU count, and what happens when I cross it.
• I know whether the charge appears on my Shopify invoice through Shopify's billing or on a separate card.
• I have asked how much sales history each candidate starts with, and how many SKUs it reported after its first sync.
• The trial is long enough for one full reorder cycle, and I have named the three SKUs I will judge it on.

If a candidate clears that list, the remaining differences are matters of taste. Pick the cheaper one and put the difference into stock.