Miko Restock: Inventory & PO
An inventory brain a shop owner can check by hand
Miko Restock: Inventory & PO is the seventh app in our own Shopify suite, designed and written here in Auckland. This is the build note: where the brief came from, which parts were genuinely difficult, and what solving them says about the work we can do inside your store.
Plans, screens and settings live on the Miko product page. There is a free plan, and Pro is $15 a month with a 7-day free trial.
It started as a spreadsheet problem, twice over
Two things kept turning up in the stores we work on. The first is that reorder decisions were being made in a spreadsheet next to the Shopify tab, rebuilt by hand every week, and quietly wrong the moment a supplier changed how long they take. The second is that Shopify's own Stocky is being switched off on 31 August 2026, and the merchants relying on it were about to lose years of purchase order history with no bulk way to take it with them.
We could have written a one-off script for each store. Instead we built the thing once, properly, as an app we operate ourselves, so the same problem never has to be re-solved per client. That is the argument this page is really making: what we ship for ourselves is what we are prepared to ship for you.
Four problems that decided the architecture
None of these are visible in a feature list. All four are the reason the app behaves under a real catalogue rather than a demo one.
A forecast nobody has to take on faith
We deliberately did not build a black box. The daily rate blends three windows, preferring 90 days for stability, dropping to 30 days for a product too young to have 90, and to 365 for slow or seasonal lines. The recommendation is then plain arithmetic: cover target plus supplier lead time, multiplied by the rate, minus what is on hand and what is already on the water, lifted to the minimum order quantity. A merchant can redo it on paper, which is exactly what they asked for.
Getting history out of a product being retired
Stocky offers no bulk purchase order export and no supplier export at all, so a clean migration path did not exist to copy. Our importer takes many files in one go, tolerates the column headings drifting between report versions through a case-insensitive alias table, and rebuilds supplier cards from the names it finds, flagged for a human to confirm. It writes historical records only and never touches live stock, which is what makes it safe to run on day one.
One guarded door for every stock write
An inventory app earns trust by what it refuses to do quietly. Receiving a delivery and applying a stocktake are the only two paths that change Shopify quantities, both go through a single write function, and both put the variance in front of a person before it runs. Receiving also recalculates a weighted average cost rather than overwriting the old one, so margin history survives a price change from a supplier.
A sync that survives a deploy
Every admin screen renders from a local cache of variants and per-location levels rather than calling Shopify on page load, so a large catalogue stays quick. Filling that cache is paginated GraphQL, and each background batch stores its cursor with the job, so a release shipped halfway through a sync resumes where it stopped instead of starting the whole catalogue again.
The same four problems turn up in client work
If your operations run on a spreadsheet, a legacy tool that is being retired, or an ERP that disagrees with Shopify about stock, the work is the shape above. Modelling a merchant's data so a screen answers instantly, making a calculation defensible enough that a business will act on it, guarding every write with a preview, and moving history off a platform that is closing. We have those four in production, under load, with our own name on the support inbox.
What the app does, in short
- Forecasts demand from up to 365 days of a store's own orders and turns it into a ranked buy list
- Builds, sends and receives purchase orders per supplier, in full or in part, with lead times and costs tracked
- Runs stocktakes by scanner, on screen, or by exported sheet, with a variance review before anything is applied
- Reports on cash frozen in slow stock, upcoming stockout dates, and supplier costs that have crept up
- Reads inventory across every active location, needs no theme changes, and reads no customer or order personal data
Full detail, every screen and the plans are on the Miko Restock product page, and the merchant guide is at miko.co.nz/restock-docs.
Two screens that show the principle
Interface work on an operations tool is mostly about ranking and consequence. What needs attention first, and what is about to change.
The buy list ranks by urgency rather than alphabetically, and shows the working out alongside the number, so the recommendation can be argued with.
The confirmation step before a delivery is received. Every quantity and cost movement is stated first, because this is one of only two places the app may change Shopify stock.
Questions we get about this build
Tripster Developers, a Shopify agency in Auckland, New Zealand. We wrote the forecasting maths, the purchase order and stocktake flows, the migration importer and the Shopify GraphQL sync layer, and we run the app in production ourselves.
On the product page at miko.co.nz/restock, which carries every screen, setting and report, plus the plans. This page is the build note that sits behind it.
Not yet. It is in review with Shopify. The merchant guide is already published, so the whole app can be read through before the listing goes live.
Yes. The parts that made this app work are the parts most operational builds need: a resumable catalogue sync, forecasting a merchant can check by hand, a single guarded path for every write back to Shopify, and an importer that gets historic data out of a system being switched off. Start at Shopify app development.
Yes. Custom themes, Shopify Plus builds, ERP and middleware integrations, and private apps for merchants who need something the App Store does not sell. Our own suite is where the patterns are proven first.
Built by Tripster Developers
Miko Restock: Inventory & PO is built and maintained by Tripster Developers, a certified Shopify Plus Partner working on Shopify since 2016, from Auckland, New Zealand. Restock is the seventh app in the Miko suite, built for merchants whose stock decisions were being made in a spreadsheet.
We build the same way for clients: custom Shopify themes, Shopify Plus builds, ERP and middleware integrations, and private apps for merchants who need something the App Store does not sell.
Have an operations problem this shape?
Tell us where the spreadsheet is, and we will tell you what it would take to remove it.
Start a conversation