Somewhere in the install flow of every inventory app there is a permissions screen, and it says the quiet part in plain type: this app can view and edit your inventory. Edit. The numbers your storefront and your marketplaces sell against are about to accept writes from software you have known for four minutes.
If that gives you pause, good. This page argues that the pause is correct, that the software industry solved this exact problem decades ago with a pattern called the dry run, and that the same pattern is the right way to evaluate anything that wants to manage your stock. Ventorify is an inventory app and this is its blog, so the shape of the page is the usual one: the argument comes first, one section near the end says how we apply it, and the standard it proposes is one you should hold every vendor to, us included.
Key Takeaways
- An inventory app is software you grant write access to your live stock levels. Hesitating before you install one, especially mid-migration, is not timidity. It is accurate risk assessment.
- Software engineering ships the answer as standard practice: the dry run, which executes all of the logic, writes nothing, and reports what it would have done.
- The same test applies to inventory. Run the app read-only against your real sales, then compare its would-be adjustments to what actually happened before it writes a single unit.
- The common alternative, running the new app alongside the old one during a trial, puts two writers on one stock ledger, which is the exact failure merchants are trying to avoid.
- Go-live should be a checklist you walk through after the log has convinced you, not a leap taken on a vendor's word.
The fear of a new inventory app is rational
Stock levels are the one dataset in your business where a bad write costs money within hours. A wrong price on a page is embarrassing until someone notices. A wrong stock number sells things you do not have, or silently stops selling things you do, and it does both at the speed of your busiest channel.
Write access is also broader than the word "sync" suggests. An app managing your inventory can set absolute quantities, and it applies its logic across the catalogue: a mapping mistake on one SKU is a mapping mistake on every SKU that shares the pattern. Merchants know this failure mode from experience rather than theory. Shopify's community forum has threads like this years-old one asking why store inventory quantities change with no visible cause, where the answer that eventually surfaces is a third-party integration writing numbers nobody was watching.
The stakes are scored, not just felt. An oversold marketplace order becomes a cancellation, and cancellations land on published metrics: on eBay, an out-of-stock cancellation is a transaction defect counted against thresholds as tight as 0.5% for Top Rated sellers (eBay seller standards policy), and on Amazon, pre-shipment cancellations count into a rate with published guidance to stay below 2.5% over a rolling 7 days (Amazon seller policies). We walked the full arithmetic in what an oversold order really costs; the short version is that a burst of bad writes on a busy weekend fits entirely inside one Amazon measurement window.
Faced with all that, the standard advice is a free trial, sometimes sharpened into "run the new app alongside the old one and compare". Look at what that actually creates: two systems with write access to one ledger, each treating the other's writes as drift to correct. Dueling writers are a reliable way to produce the random-looking changes above, not a way to detect them. A trial where the app can write is not a test. It is production with a refund policy.
Engineers solved this decades ago
When software operators need to trust a tool with something live, they do not extend that trust on the vendor's word. They ask the tool to prove itself in a mode where it cannot do damage: execute all of the logic, suppress every write, and report what would have happened. The pattern is old enough to have a plain name, the dry run, and modern infrastructure treats it as table stakes rather than a luxury.
Two mainstream examples make the point. Kubernetes accepts any change request in a dry-run mode where, in its own documentation's words, requests are processed "without actually persisting the changes", so operators can see the full outcome of a change before it exists (Kubernetes API concepts). Google Cloud lets administrators create security policies in a dry-run mode where violations are logged in full but "the violating actions aren't denied", so a policy can be watched against live traffic before it is allowed to block anything (Google Cloud organization policy).
Notice what the pattern is really for. It is not a demo, and it is not a sandbox filled with toy data. A dry run works on the real system, with real events, running the real logic; the only thing missing is the consequence. That is what makes its output evidence rather than marketing: the log of what would have happened can be checked, line by line, against what you know actually happened. Trust built this way costs the vendor something to provide, which is precisely why it is worth more than trust requested on a landing page.
A dry run for your inventory
Applied to stock, the pattern reads like this: the app connects with everything switched to read-only, watches your real sales as they happen, and records every adjustment it would have made, without writing anything anywhere. Not to your marketplaces, and not to Shopify either. The record has to be exportable, because a log you can only view inside the vendor's own dashboard is a log you cannot independently check. And when observation ends, going live should be a deliberate, guided step, not a timer running out.
This is exactly what Ventorify's Observation Mode is: shop-wide read-only operation, every would-be stock adjustment logged and exportable, nothing written to any channel including Shopify, and a guided, checklist-gated go-live afterwards. That is the whole description, and the reason this section is short is that there is nothing else to claim. The mode's value is not a feature to be described. It is the evidence it produces, which brings us to what you should do with it.
How to judge the log
An observation window is only as useful as the questions you ask of it. The app is showing you its arithmetic; your job is to mark it. Three checks cover most of what can go wrong, and all three run against records you already have.
First, causality: after a sale on one of your marketplaces, find the matching would-be adjustment. When the Ceramic Mug sells on Amazon, the log should show your other channels being told about exactly one fewer mug, promptly. The reconciliation source on the Shopify side is built in, since every inventory change is recorded in your adjustment history with the actor and reason attached; sale by sale, the app's would-have-done column and Shopify's actually-happened column should tell the same story.
Second, policy: check that the would-be numbers respect the rules you configured, not just the arithmetic. If you hold back a buffer against overselling, the quantities pushed to external channels should consistently sit below your true stock by that buffer. If a buffer is set in days of demand, watch it move when a SKU's velocity moves, the behaviour we covered in the safety stock guide.
Third, identity: scan the log for SKUs you expected to see and do not, and for SKUs you did not expect and do. Mapping errors hide at the edges of a catalogue, in bundles, multi-location stock and lookalike variants, and an observation log is the cheapest place you will ever find them. A wrong mapping discovered in a read-only log is a row to fix. The same mapping discovered live is an oversell with your account metrics attached.
Give the window enough sales to mean something. A quiet week proves little for a fast seller and nothing for a slow one; what you want is for each check above to have fired several times across your important SKUs before you conclude anything.
Go-live is a checklist, not a leap
The end of a good observation period should feel administrative, even slightly boring. The decision was already made by the log; the go-live is just the paperwork. That is what a checklist-gated go-live protects, and it is a standard to hold any tool to: before write access exists at all, the gate should make you confirm what the log let you verify. The mappings. The buffers. The channels you actually intend to let it write to.
Contrast that with how this decision is usually made. Merchants leaving Stocky are making it right now under a deadline, since Stocky retires on August 31, 2026, and a forced migration is the worst context for extending trust: the pressure to be done is exactly the pressure to skip diligence. It is also when skipping costs the most, because a merchant mid-migration is juggling a data export with its own deadline and a new native workflow to learn, and has the least attention to spare for babysitting an app's first writes. Under deadline, an observation period is not a delay. It is the fastest safe path, because it runs while you do the rest of the migration.
Where this leaves you
The permissions screen was telling the truth: an inventory app is a request for write access to the numbers your business runs on. The industry's default answer, trust the trial, asks you to grant that access first and evaluate afterwards. Engineering practice has long had the safer order, and there is no reason inventory software should be exempt from it. Demand a dry run: read-only operation against your real sales, every would-be adjustment logged where you can export and check it, and a go-live you walk through deliberately. Any tool confident in its own arithmetic can afford to show it to you before it acts, and how that works during a Stocky migration specifically is laid out on our migration page.