Stocky shuts down in August. What are you actually moving to for reorder/POs?

Shopify Discussion
31

Putting on my “store owner hat” because in owning a store I can answer this.

Any app that gives me more value than it would take for me to do the same thing is worth my dollars. This is where FyreTrail came from. The amount of work we did in our store justified building the app functionality to replace those labor hours. Now, that time is no longer spent doing the things FyreTrail does.

In fact, the pricing tiers are intended to be cheaper than what it takes as a store operator to do the same things day after day, week after week, etc. The reason is, what it’s worth to us is exactly what it would be to somebody else and that should cost a store less than what it would cost for them to dedicate time, labor, etc. and still mean they’re “saving money.”

I have calculated several times what FyreTrail saves our store… $480/month is what we spend without FyreTrail in equivalent “lost” labor. Now WITH FyreTrail that labor is spent doing other things and you get the same $480/month equivalent by only spending $159/month (or less!).

32

That labor-replacement framing is the clearest answer I’ve gotten anywhere on this topic: price against the hours it replaces, and make sure the merchant still comes out ahead. The gap between that math and the “Stocky was free” anchor you described earlier explains a lot about this market.

Genuinely appreciate you taking the time to answer from both the builder and store-owner side. Good luck with FyreTrail through the August transition.

33

I build one of these, so weigh that accordingly.

Taking your last question first, because it is the interesting one. Would a small tool doing reorder suggestions plus an exportable PO sell? Probably, but that is the crowded lane. Prediko at around $49 and Stockful at around $20 already sit in it, and Shopify confirming forecasting is not coming in 2026 has pulled several more builders in. It is the loudest gap, so it is the one everybody is aiming at. The quieter gaps have less competition.

On what people actually used Stocky for, it splits three ways and the right answer differs by split.

Reorder suggestions from sales velocity: Prediko. I say that as someone with a competing app, because I do not do forecasting at all and will not pretend otherwise.

Purchase orders and receiving: Shopify is moving basic POs and linked transfers into the admin natively. Test that before you pay for anything. A fair number of people need less than they think.

Invoice due dates and knowing what you owe each supplier: that is the one nobody replaces. It is where I built mine, Purser, $37.99, free under 5 POs a month. Accounts payable and weighted-average cost, no forecasting.

Whatever you pick, export your purchase order file out of Stocky before August. Supplier records do not export at all, and rebuilding them from the PO file is the only way back.

35

Disclosure up front: I developed a stocky alternative (stockwik) so take that into consideration.

I ran eCommerce sites for 14+ years and had a few Shopify sites in that time. Honestly never heard of Stocky because we were never on POS Pro - I only discovered it after creating my app. It started as something I used internally and I thought why not and decided to publish it.

My app does reorder levels, purchase orders, receiving, cycle and full inventory counts (stocktakes), location transfers, and seasonality tracking. The only thing we haven’t added in is the barcode scanning and that’s mostly based on my experience as the majority of my industry never had standardized barcodes on anything so I never needed that functionality when receiving/counting.

At this point in the discussion I’m piling on but let me know if you have any questions.

36

To your actual question — yes, I’d pay for a focused reorder + PO tool at a reasonable price. The market has moved toward doing just that: OrderPoint, Restocked, Replenio, even a few of the newer ones are built around exactly the “tell me what to order and let me send the PO” flow without the full WMS overhead. That niche is being served.

The thing I’d add, because it came up in my own migration: the replacement app question and the data preservation question are separate, and the order matters.

Here’s what leaves Stocky with you intact via CSV:

  • PO history (headers and lines)
  • Stocktake results
  • Current SKU cost at time of export

Here’s what doesn’t make it into any CSV:

  • Supplier notes — Shopify’s own docs say “Suppliers can’t be exported from Stocky.” I verified in the API: the /suppliers endpoint has contact and address fields, no free-text notes field.
  • Par levels / reorder point settings — not in the CSV, not in the documented API resources.

Here’s what IS recoverable from the API but gets flattened in CSV exports:

  • Per-supplier cost history over time (supplier_cost_price per purchase item)
  • Actual received dates (received_at), not just ordered dates — which is what you need for real lead time data

I built a Chrome extension (InvoRescue) specifically for this pre-migration step. It pulls the fuller API data (cost trail, received dates, complete PO records), then steps through a structured capture flow for supplier notes and par levels per vendor — since those can’t be automated, it at least makes the manual work systematic. One-time purchase, not a subscription, because after August there’s nothing left to extract. Runs entirely in the browser.

The replacement app choice is reversible — you can switch apps later if it doesn’t fit. The cost history and vendor notes aren’t coming back after the shutdown. Worth doing the data rescue first, then picking your long-term tool. Link’s on my profile.

37

Short answer to your actual question: yes, there’s real demand for exactly that — “just reorder suggestions + an exportable PO, nothing else.” Everyone landing in these Stocky threads is stuck between two bad options: a spreadsheet that breaks once you’re past ~100 SKUs and a few suppliers, or a full ERP that costs more and does 20 things you don’t need.

On what the native replacement actually keeps vs. drops after Aug 31: you keep manual purchase orders, supplier records, and transfers under Products → Purchase Orders. What’s gone is the intelligence layer — demand forecasting and reorder suggestions. Shopify has said those aren’t coming in 2026.

If you want a zero-cost stopgap, the reorder math Stocky did isn’t complicated and you can rebuild the core in a sheet:

  • reorder point = (avg daily units sold × supplier lead time in days) + safety stock
  • pull ~30-90 days of sales per variant from Analytics, export, compute avg daily
  • flag any SKU where current stock ≤ reorder point
  • group the flagged rows by supplier → that’s your draft PO
    It’s manual and won’t model seasonality, but it covers most of what people actually miss about Stocky.

Full disclosure: I’m one of the devs behind EasyRestock (apps.shopify.com/easyrestock). We built it deliberately narrow — low-stock/reorder alerts, purchase orders, and receiving, nothing else — because we kept hearing the exact “I don’t want an ERP for this” you’re describing. Not claiming it’s the answer for you, just confirming the simple-tool niche you asked about does exist now.

39

Bias declared, EasyScan is ours.

On the reorder side, the thing worth pressing any tool on is whether it can order off your Supplier/vendor terms rather than off sales velocity.

A lot of these tools assume you reorder because something is selling. Bricks-and-mortar buying tends to be driven by negotiated tiers, MOQs and freight thresholds, and a forecast that ignores those produces orders your Supplier will not accept.

We hold Supplier records with terms, lead times, costs and MOQs, and receiving, counting and labelling sit in the same app.

We also allow you to create PO’s based on forecasting, MOQs, Minimums, Max, and more

Two questions worth asking whatever you shortlist:

  • does cost edited during receiving write back to the product record
  • can it receive one PO across three shipments
    Those two solve a lot.

Happy to answer anything here.

Thanks,
Charlie

40

The reorder logic is the part Shopify never replaced and it is not complicated to rebuild by hand if you want something working this week.

Reorder point is average daily units over your lookback window, times supplier lead time in days, plus safety stock. Safety stock is where most tools go vague. A version that holds up in practice: (peak daily units minus average daily units) times lead time. That covers the spike that actually burns you, rather than the average that never does.

Average daily units per variant comes out of Shopify’s own sales reports. Lead time you already know per supplier. That combination gets you a spreadsheet doing most of what Stocky’s suggestions did.

What a spreadsheet will not do is the receiving side. Marking a PO partially received and having stock update itself is the bit that quietly eats an afternoon a week.

Disclosure so it is on the table: I built an app for this after the shutdown was announced, called Proviand. Being accurate about the money, because this thread is about POs: the free tier is 50 SKUs and one location and it does not include purchase orders. POs start at 29 dollars a month, flat, no contract. At 100 to 1000 SKUs you would be on a paid tier, so I would rather say that now than after you install.

I am deliberately not dropping a link in a help thread. The maths above stands on its own, and I am happy to answer questions on it here whether or not you ever look at what I built.

41

I’ve been working directly against the Stocky API for a few months — I’m building an alternative, disclosure at the end — so I can answer part of this from the payload side rather than from the docs.

On what the API actually returns: suppliers, purchase orders with their line items, stock adjustments and tax types. What it does not return is the planning layer. Reorder points, lead time settings and MOQ aren’t exposed through the API at all — they only exist in the CSV export. So the numbers you spent months calibrating are exactly the export-or-lose ones, and there’s no scripting them back out later.

@lumine on received dates — partially better news than you’d expect, though in an odd place. The PO header carries created and ordered timestamps but no received date. The received date lives on each line item instead: every purchase item carries its own received_at, date only. So the receiving trail exists in the data, and per-supplier lead time is reconstructible from ordered-to-received per line, partial deliveries included — provided whatever you move to actually reads it. Whether the CSV export surfaces that column I can’t confirm yet; that’s the exact thing I’d check the moment the export lands.

Cost history is similar. Each PO line carries what you actually paid at the time — a cost price and a separate supplier cost — so the paid trail survives as long as your PO history comes across. What collapses is the per-supplier cost as a current setting.

Vendor notes: I don’t see a notes field anywhere in the supplier or PO payloads. Your read matches mine — if it isn’t in the CSV either, it’s gone for good.

One practical landmine for anyone writing their own importer: Stocky returns display-formatted dates that follow the store’s locale, not a fixed format. I’ve had a live store return 07/26/2026 where the documented example is DD/MM/YYYY — and the same store can mix formats between fields. Parse assuming one format and every date past the 12th of the month comes out silently wrong.

Two more things worth knowing: the API is read-only, so there’s no path to push anything back in after Aug 31. And Shopify’s own migration guide states past purchase orders can’t be imported into Shopify — which matches everything I see.

Disclosure since it’s relevant to the thread: the app I’m building is UreyukiBox. It imports the API data plus the CSV-only fields, is in review now, and launches mid-August with an English UI — free tier, paid plans above that. The export findings above hold regardless of which app you pick.

42

Thanks for going at the payload instead of the docs, that settles the received date part.

On whether the CSV surfaces it, worth knowing that question already has two opposite answers sitting in the other Stocky thread. irish.chen said flatly that the standard PO export has no received date column, then a few hours later walked it back to not having actually run the export, and pointed at a migration guide claiming the export does include cost prices and received quantities. So nobody has confirmed it either way yet.

You are probably the one person across both threads who can close it. You said you have a live store handing back 07/26/2026, so run the PO export and paste the header row. Five minutes and the rest of us stop guessing.

It matters more than it looks, because the two clocks are not the same. The APIs stop on August 31 and export access runs for at least 90 days after that. If received_at only lives in the API, it dies on the 31st. If it comes across in the CSV, it survives into November, and the order of work everyone here has settled on flips.

On the locale dates, one cheap oracle if you are writing the importer. received_at can never be earlier than the ordered date on the same line. Parse the file both ways and count the violations. The wrong parse leaves you a pile of impossible lines, the right one leaves none. Run that count per field rather than per file, since you already found a store mixing formats between fields.

44

Following this thread closely, we’ve been knee deep in the same rebuild.

Re: the API vs CSV thing a few posts back, yeah, same on our end. Stocky’s API gives you suppliers, POs, stock adjustments that’s about it. Reorder points, lead time, MOQ, none of that’s in there, only shows up in the CSV export.

If the main thing you’re missing is reorder suggestions, POs, and receiving rather than a whole ERP, that’s basically the hole we built BR Inventory Planner to fill. Not going to pretend it does everything though. Right now it’ll calculate reorder point and quantity per product/variant/vendor using your actual sales history plus lead time and min order qty, and there’s a one click Stocky supplier import if you’ve still got your API key handy (saves re-typing every supplier, though same limitation as above, it can’t grab reorder points/lead time from Stocky either since the API just doesn’t have them).

We create Shopify POs via a URL and a list of up to 50 products. We have a Chrome/Edge plugin that autofils your quantity into the Shopify Purchase Order. You can also export the reorder list to Excel or email your supplier straight from the list. Receiving works with barcode/camera scanning already but only for transfers right now. Scan to receive against a PO is next on our list, so if that’s what you need today it isn’t there yet.

It also does multi-location and Stocky style ABC/best-seller/low-stock reports.

I’m one of the people building it so obviously take that with a grain of salt.

It’s $10/mo after a 15-day trial:
BR Inventory Planner - Forecast inventory, create POs, and scan transfers with ease

45

Tsumugi’s breakdown above is accurate from what I’ve found independently — it fills in a few gaps from my earlier post in this thread.

The received_at location detail matters practically: because it sits on each purchase item rather than the PO header, you can reconstruct per-supplier lead time at the delivery level, not just the average across the whole PO. Partial shipments with different received dates are recoverable. That’s more granular than I initially flagged, so good to know.

One thing not yet covered above — par levels and reorder point settings (the “when Stocky tells you to reorder” thresholds). Those aren’t in the API or the CSV export. They live only inside Stocky’s internal app logic. The only way to preserve them is manual: screenshot or copy each supplier’s settings while you still have Stocky access. If you have a lot of suppliers, that’s worth doing this week rather than the week before August 31.

Adding to the date-format warning: worth checking whatever tool you use parses the received_at date as a date type, not a string. I’ve seen stores where the locale setting causes Stocky to emit mixed date formats across different fields, and a silent parse failure there means your lead time calculations come out wrong without any obvious error.

46

Disclosure up front: I build one of the apps in this space, so weigh this accordingly.

To your actual question — yes, that bet is the right one. What most people used Stocky for day to day wasn’t inventory management, it was two things: “what should I buy this week” and “send that to the supplier as a PO”. Native transfers covers the second one awkwardly and doesn’t touch the first at all.

To @akandelism’s point about the moving pieces, here’s what a lightweight version has to get right, from having built one:

Lead time per supplier, not one global setting. A 3-day domestic supplier and a 45-day import need completely different reorder points for the same sales rate. A single lead-time field silently averages you into being wrong on both — you over-order the fast one and stock out on the slow one, and it looks like the forecast is broken when the input was.

Velocity from live orders, not a pasted snapshot. The failure mode with spreadsheets isn’t the maths, it’s that the week nobody refreshes it is the week it’s quietly wrong.

Days of cover, not just a reorder quantity. “14 days left” is something anyone in the business can act on. “Reorder at 47 units” means nothing without knowing how fast 47 goes.

Partial receiving. 100 ordered, 60 arrive. It needs to write 60 into inventory, leave 40 outstanding on the PO, and still show 40 as incoming. This is where most tools fall over and you won’t find it on a pricing page — test it with a real order before you commit.

Mine is Replenora, which is deliberately the narrow version you described: purchase orders with supplier lead times, emailed as PDFs or downloaded, receiving straight into Shopify inventory with a full audit trail, and a replenishment report that turns the last 60 days of orders into days of cover and reorder points, then drafts a PO per supplier from the suggestions. Free for up to 5 open purchase orders, $29/month flat above that. It does not do barcode labels or multi-warehouse planning, so if those were part of your Stocky workflow you’ll want something broader.

One thing worth doing this month regardless of what you choose: export your suppliers and purchase order history to CSV. Stocky goes on the 31st. The tooling decision can wait until September; the data can’t.

App Store: Replenora - Purchase orders, receiving, and reorder points in one place | Shopify App Store

More detail: https://replenora.hjbcodeforge.com

47

@irish.chen the point about par levels and reorder points living only
inside Stocky’s app logic is right on the facts, but I’d push back on
whether it’s worth a week of screenshotting.

A reorder point in Stocky is a number somebody typed in at some point,
usually a while ago. It doesn’t move when the product’s sales move. So
when you migrate it, you’re carrying over a decision made against last
year’s demand and treating it as data.

The settings actually worth capturing are the ones that aren’t derived
from sales at all:

  • supplier MOQs and case/pack sizes
  • shelf or storage capacity ceilings
  • anything contractual

Those can’t be recomputed from anything, and they’re gone on the 31st.
Reorder points, par levels and safety stock are a different matter — you
can rebuild those in an afternoon from sales history plus lead time, and
you’ll end up with better numbers than the ones you rescued.

Two additions to @HJBCodeforge’s list, which I think is the most useful
summary in this thread:

On reconstructing lead time from received_at — use the median, not the
mean. One container stuck in customs drags a mean out by weeks and
quietly inflates every reorder point you compute from it. Since partial
deliveries give you several received dates per PO, you usually have
enough points for a median to be meaningful.

On velocity — a single window hides the thing that actually causes the
stockouts. A product selling at its 30-day average is predictable. A
product whose last 7 days are running 40% above its 30-day average has
moved its own stockout date forward by about a week, without a single
unit leaving your stock plan, and a static reorder point won’t notice
until it’s already been crossed. Comparing the two windows costs nothing
— both are inside the same 30 days of order data you’re already pulling
— and that comparison is where the surprises live.

Disclosure: I’m building in this space (StockPulse). For the question in
the title, I’m not the answer — no purchase orders, no receiving, no
suggested quantities. @HJBCodeforge’s Replenora and brata’s BR
Inventory Planner both cover the PO half properly and mine doesn’t.

Mine only does the days-of-cover and order-by-date part. I put that
calculation up as a free page — no signup, runs in your browser — if you
want to sanity-check one product against whatever you end up picking:

48

@DEV_WEB1 Good pushback, and the median/velocity points are genuinely useful — hadn’t thought about comparing the 7-day and 30-day windows off the same pull, that’s a smart way to get an early warning for free.

You’re right that I was overselling the reorder points, though. A number someone typed in a year ago isn’t data, it’s a stale decision, and rebuilding it the way you described gets you something better. I’ll stop pitching that as worth rescuing.

Where I’d still draw a line: MOQs, case/pack sizes, capacity ceilings, contract terms — the stuff you listed as not derivable from sales. That’s the actual case for grabbing anything before the 31st, and it doesn’t compete with what you three are building. Whichever of Replenora, BR Inventory Planner, or StockPulse someone ends up on, none of those tools existed when the supplier relationship was set up, so none of them have that context either. InvoRescue just pulls it — plus cost history and received dates via the API, also gone on the 31st — so it’s sitting there ready to hand to whichever tool you pick.

Disclosure: same as you, building in this space. One-time purchase, not a subscription, price is on the page. Not trying to compete with the three tools above — this is more the “before you even decide” step.

49

(post deleted by author)

50

(post deleted by author)

51

Whatever you import into, check the cost column first. European exports write 12,50 and plenty of importers turn that into 1250. Mine did until last week, took me a while to spot.

(Building Stockward, so treat that as disclosure.)

52

we actually trying all apps, but best so far is supplywatch :waving_hand: