Inventory app for a large Shopify catalogue, 1,000 to 2,000 SKUs

This page is for a Shopify store running a long catalogue, roughly 1,000 to 2,000 SKUs. Restoc is built to hold a reorder point against every tracked SKU and surface the ones that need ordering this week, instead of leaving it to how far down the spreadsheet you got.

The Monday export, and where it gives out

Say 1,600 variants are live. Fifty of them earn most of the revenue. A few hundred tick over. The rest is a long tail of sizes, colours and last season's drops that you would still rather not be out of when someone finally wants one.

So on Monday you export inventory, paste last month's sales beside it, sort by units sold and work down the list. You get through the fast movers. You mean to get through the rest. By Wednesday the export is stale, a supplier has pushed a date, and a bundle you forgot about has quietly drained a component SKU.

Then a best seller sells out and nobody notices until a customer asks for it. Running out of stock on a line that was selling is a real financial hit, and on a long catalogue it lands harder, because nobody is watching the specific SKU that went, only the store total.

What you are actually asking for

Something narrower than most tools pitched at this catalogue size. Not an ERP. Not demand planning, not purchase order approvals, not a replenishment consultant. The job is one sentence: tell me which SKUs will run out before a new order can land, given how fast each one is selling and how long that supplier takes.

That is the job Restoc is built for, and nothing wider. If your catalogue is much smaller, the argument changes, and there is a separate page in this section written for the one-person store.

Why 1,600 SKUs is a different job from 200

Three things change when the catalogue gets long.

Attention stops scaling. At 200 SKUs you can read every row. At 1,600 you read the top of the list and trust the rest. Any system that depends on you looking will miss the SKU you were not looking at, which is usually the one that costs you.

"Low" stops meaning anything on its own. Eight units is comfortable for a slow line and already late for a hero SKU on a six-week lead time. One store-wide low-stock number cannot tell those two apart. The threshold has to sit per SKU, built from that SKU's own sales rate and its own supplier wait.

Lead times spread out. A long catalogue usually means several suppliers: a domestic printer at three days, a container at sixty. A single reorder rule across all of them is wrong in both directions, early on the fast ones and late on the slow ones.

Restoc's answer is a reorder point calculated per SKU from a sales velocity window you choose and a lead time you enter, then alerts that fire on a crossing rather than on a calendar. The calculation is a tested pure function, so a hero line and a size you forgot you carried go through exactly the same arithmetic.

How Restoc is built to run on a catalogue this size

Install on your store
Restoc installs through Shopify's OAuth flow and reads your products, inventory levels and orders. Stock levels are refreshed by the scheduled sync job. The inventory webhook handler currently reads a field Shopify's payload does not send, so until that is fixed treat stock as sync-fresh rather than second-by-second. It is a web app: no mobile app, no browser extension, and we will say so here when that changes.
Enter lead time per SKU
Lead time is your input, not our guess. Set the supplier wait against each SKU so container lines and domestic reprints end up with different reorder points instead of one average that fits neither. Lead time is validated as a whole number of days.
Pick a sales velocity window
Choose 7, 14 or 30 days across the store. Short windows follow a SKU that is accelerating, longer windows even out the lumpy ones. On Pro you can also override the window on a single SKU, which is what a long catalogue usually needs for its seasonal lines.
Let the reorder point calculate itself
For every tracked SKU, Restoc derives a reorder point from that SKU's velocity in the chosen window and its lead time. The same function runs for all 1,600 rows, including the edge cases: zero-sales SKUs, short history, stock already at nothing.
See stock, days remaining and reorder status in one place
One screen shows current stock, days of inventory remaining and reorder status for each active tracked SKU, so the numbers live in the app instead of in an export you rebuild each week. Plainly: the dashboard does not yet sort or filter that list by urgency. Making the days-remaining column sortable, soonest to stock out first, is on the build list and not shipped, so today you read the reorder status per SKU rather than a ranked queue.
Take the alerts as a SKU crosses
When a tracked SKU crosses its reorder point, Restoc sends an email and, on Growth or Pro, posts to your Slack incoming webhook. Delivery is idempotent, so one crossing is one alert rather than the same SKU pinging the channel every run. Honestly: the scheduler that would run this unattended in production is not wired yet, so alert delivery only happens when the job is triggered. Wiring the schedule is the work before we open the app to stores.
Work the weekly report, export it to your supplier
The weekly reorder report lists every tracked SKU below its reorder point with a suggested order quantity, viewable in the app and exportable as CSV. That is the artefact you send out in place of the Monday spreadsheet. Same disclosure as above: report generation depends on the same scheduled job, which is not running unattended yet.
Watch your SKU count against your plan
Active SKU counts drift upward as variants get added. The plan cap is enforced server-side at sync time, so you are told rather than silently truncated, and an in-app banner showing current usage against the limit with an upgrade link is being added alongside it.

What that buys a long-catalogue store

The long tail gets the same watch as the hero SKU

Every SKU Restoc tracks carries its own reorder point and its own alert, so a slow mover is not ignored for being slow. How much of a large catalogue can be tracked today has a real limit, and it is set out below rather than buried.

One number per SKU you can act on

Days of inventory remaining, per tracked SKU, next to current stock and reorder status. One place to see every tracked SKU's days remaining, rather than a sheet you rebuild from two exports. Ordering that view by soonest to stock out is still work to do, not a shipped feature.

Different suppliers, different thresholds

Lead time is per SKU, so a sixty-day container line triggers early and a three-day reprint triggers late, out of the same set of rules.

Alerts where the team already is

Email for whoever owns purchasing, and on Growth or Pro a Slack incoming webhook for the channel where stock gets discussed. Same trigger, no duplicate firing for the same crossing.

A CSV instead of a rebuilt spreadsheet

The weekly reorder report carries the SKUs below their reorder point with suggested order quantities. Export it, adjust the quantities you know better, send it.

Flat pricing inside the cap

Growth covers up to 1,000 tracked SKUs at $59 a month, Pro up to 2,000 at $99 a month. The price does not climb per SKU inside the cap, and the plans are declared to be billed on your Shopify invoice rather than a separate card payment.

Sixty days to test it on real orders

Every plan declares a 60-day free trial. A catalogue this size needs more than a fortnight of real orders before you can judge whether a threshold is set right. We are claiming the trial length and nothing more about charge timing, for the reason given below.

Growth or Pro: the decision here is SKU count

What you are comparing	Growth	Pro
Tracked SKUs	1,000	2,000
Monthly price	$59 / month	$99 / month
Billed yearly	$590 / year, ten months' price for twelve	$990 / year, ten months' price for twelve
Locations	1	1
Free trial	60 days	60 days
Sales velocity window	Store-wide: 7, 14 or 30 days	Store-wide, plus a per-SKU override
Alerts	Email, plus Slack through an incoming webhook	Email, plus Slack through an incoming webhook
Weekly reorder report	In-app, exportable as CSV	In-app, exportable as CSV

Where we are with a catalogue this size, plainly

Restoc is not open to stores yet, and a few of these limits bear directly on a long catalogue. Read them before you join the waitlist.

The product pull reads one page of up to 250 products. It does not yet follow Shopify's pagination cursor, so on a store above that the products past the first page are not tracked at all. Growth and Pro sell 1,000 and 2,000 tracked SKUs, and pagination has to land before either cap is real. It is the top of the build list.
Nothing is backfilled at install. Sales history builds forward from the first order after you connect, so velocity, days of inventory remaining and reorder points fill in as orders arrive rather than appearing on day one. On a fast-moving catalogue that is days. On the slow tail it is longer.
No scheduler is wired in production. The alert evaluation, the alert delivery, the weekly report and the sync job are all written and tested, and they are idempotent, but today they only run when the job endpoint is called. Until the schedule is wired, Restoc does not watch stock unattended, and we are not going to pretend otherwise on a page about reorder alerts.
Real-time inventory is not real-time yet. The inventory webhook handler reads a field Shopify's payload does not carry, so manual stock edits in your admin show up on the next sync rather than immediately.
The dashboard is not yet sorted by urgency. It shows stock, days remaining and reorder status per tracked SKU. A sortable days-remaining column, defaulting to soonest to stock out, is still to be built.
Trial charge timing. Every plan declares a 60-day trial. We also want the first charge to land only after a full weekly reorder cycle has completed; that rule is written and tested but not yet enforced in the payment flow, so take the 60 days as the promise and nothing beyond it for now.
Annual billing. The yearly prices above are the declared plans, at ten months' price for twelve. They are not yet selectable during signup in the app, and prices are not yet shown in the plan picker.
One location per plan. Every tier declares a single location. If you reorder separately per warehouse, Restoc is not the tool for that today.

Sign-in is email and password. The app runs on Amazon Web Services, and what it stores is your name, email address and a hash of your password, your store domain and access token, tracked SKU details, sales quantities and dates with the order reference, your alert destinations and your plan state. No customer names, addresses or payment details are stored.

Questions

Can Restoc handle 2,000 SKUs?

Pro is sold on a 2,000 tracked SKU cap and Growth on 1,000, and the caps are enforced server-side at sync time. The honest qualifier today is the sync itself: the product pull reads one page of up to 250 products without following Shopify's pagination cursor, so a larger catalogue is not fully tracked until that is fixed. It is the first thing on the list before launch.

How do alerts reach me on a catalogue this size?

By email, and on Growth or Pro through a Slack incoming webhook you configure. One crossing produces one alert per channel, because delivery is idempotent and retry-safe rather than re-firing on every run. What is not true yet: no scheduler runs that job in production, so alerts are only delivered when the job is triggered. Unattended watching is the work in progress, not a shipped feature.

Can I set a different rule for a slow mover and a hero SKU?

Lead time is entered per SKU on every plan, which is usually the bigger lever: the same velocity produces a much earlier reorder point on a sixty-day supplier than on a three-day one. Pro adds a per-SKU override of the sales velocity window, so a seasonal line can run on 7 days while the rest of the store runs on 30.

Does the dashboard show me the most urgent SKUs first?

Not yet. It shows current stock, days of inventory remaining and reorder status for each active tracked SKU in one place, and you read the status column to find what has crossed. Making the days-remaining column sortable, defaulting to soonest to stock out, is on the build list, and the weekly reorder report already lists only the SKUs below their reorder point.

Does it forecast demand or raise purchase orders?

No. Restoc calculates a reorder point per SKU and tells you which SKUs have crossed it, with a suggested order quantity in the weekly reorder report that you can export as CSV. There is no forecasting model, no supplier catalogue and no PO approval flow, and we are not planning to become that. Note also that report generation depends on the same scheduled job that is not yet wired in production.

What does it cost for a store this size, and how long is the trial?

Growth is $59 a month for up to 1,000 tracked SKUs, Pro is $99 a month for up to 2,000. Paid yearly those are $590 and $990, ten months' price for twelve. Every plan declares a 60-day free trial, and the plans are declared to be billed on your Shopify invoice rather than a separate card payment. The annual option is not yet selectable during signup in the app. The pricing page in this section carries all three tiers side by side.

Does it work across multiple warehouses or locations?

Not today. Every plan declares a single location, so reorder points are computed on one stock figure per SKU. If you buy separately for two warehouses, that is a real gap and we would rather you knew now than after installing.

What happens to my data if I leave?

Deleting your account in Settings removes everything stored about your store at once: the Shopify connection and its access token, every SKU, sales record, alert and report, with any active Shopify charge cancelled first. Uninstalling from your Shopify admin also ends billing, and Shopify's data-erasure request about 48 hours later deletes the store's data here automatically.