The inventory app stack audit: finding the overlaps, gaps, and the app that lies

Each app you add is supposed to make your numbers better. What it actually adds is a second opinion — and nothing in the install flow assigns ownership of which opinion is true. Two apps and an admin later, a merchant can hold three different quantities for the same SKU and no process for finding out which one customers will experience. The inventory app stack audit fixes that in about 30 minutes: map which app owns which truth, run one divergence test on five SKUs, and demote everything that writes without owning. The stack does not always shrink, but it always gets honest.

What each app is actually allowed to do

Start with capability, because ownership is capped by it. Shopify apps declare technical scopes — read inventory, write inventory, read products, write products, read orders — and any write scope automatically includes read (shopify.dev, accessed November 2026). You approved those scopes at install, store by store. Two practical consequences:

• A reorder app with write_inventory can change the number your storefront shows customers. A read-only one cannot, no matter how wrong its suggestion is.
• The App Store listing discloses this before you install: each listing carries a "Data access" section. Stocky's, for example, lists view order history, edit "inventory, products, collections," and edit inventory transfers and locations (Shopify App Store, accessed November 2026).

Audit each app's scopes against what you thought it did. The full mechanics of scopes and permission tiers are covered in the app permissions explainer — here you only need the question it answers: who can write?

The truth-ownership table

Draw one table with your data domains as rows and one designated owner per row. A domain can have many readers but exactly one writer:

The rule this table enforces: staleness is survivable, unauthorized writes are not. An app showing a three-day-old quantity is annoying; an app that pushes its three-day-old quantity into Shopify is corrupting the one number that reaches your customers.

The 10-minute divergence test

Pick five SKUs — two fast movers, two seasonal, one problem child — and at the same moment, pull the available quantity for each from every surface in your stack: Shopify, each app, your spreadsheet. Log the numbers with timestamps.

Worked example from a phone-accessories catalog, one SKU (PHN-STD-BLK, matte stand), three surfaces:

• Shopify: 61. Received and adjusted natively, current.
• Count app: 64. Last synced three days ago. Since then, 3 sold: 64 − 3 = 61. Consistent — stale, not wrong.
• Reorder app: 57. Last synced before a 4-unit receipt was entered natively: 57 + 4 = 61. Also stale.

All three numbers were true at different moments. Divergence here is a sync-time problem, and the fix is a re-sync, not a confrontation. But now the dangerous version: suppose the count app had written its 64 back into Shopify on that last sync. Shopify — the number your storefront displays — would now be wrong by 3, and every downstream tool would inherit the error while looking confident. That is how the app that lies gets created: not by dishonesty, but by write access granted to a tool that does not own the domain.

If the divergence is bigger than a few units, or the timestamps do not explain it, stop auditing the stack and audit the stock itself — that is the territory of the inventory audit, which works the physical layers this software audit does not.

Overlaps, gaps, and the real cost of a fat stack

With ownership mapped, sort your findings into three buckets:

• Overlaps — two apps claiming the same domain. Two reorder engines is the classic: they will disagree weekly, and you will silently pick a favorite, which means the other one is now a $49–$199/month decoration. Pick one owner per domain and demote the loser to read-only or remove it. (When the overlap is really a sign you have outgrown the spreadsheet-plus-app patchwork, the consolidation decision — one tool to own the reorder decision — is covered separately.)
• Gaps — domains with no owner. Most small stacks have the same two: lead times (nobody stores them, so nobody recalibrates them) and count history (nowhere to see last quarter's variance). A gap is cheaper than an overlap; close it in the spreadsheet before buying anything.
• Dead weight — apps neither read nor relied on. Uninstall them; they cost money, add login surface, and sometimes still hold scopes you forgot you approved.

There is also a subtler cost: cognitive load. One long-time user of a reporting app described the accumulated layers this way: the app "has become excessively complex… too much information… too slow for professional use" (Assisty 1★ App Store review, August 2026, translated). Every tool you keep is a tool someone on a two-person team must understand; a stack nobody fully understands is functionally unowned, whatever the table says.

When divergence is a symptom, not the stack

Three boundary cases worth separating, because they get misdiagnosed as "too many apps":

• Numbers disagree inside Shopify alone — no apps involved, quantities updating oddly. That is the inventory-not-updating diagnostic, not a stack problem.
• Multiple apps legitimately share write access to the same locations — by design, not accident. The architecture question of who writes stock when apps coexist is covered in the multi-managed inventory piece.
• The stock itself is wrong — counted quantities never match anything. Software cannot fix that; the audit of physical stock can.

Where read-only tools sit in all this

A note on where we land, since it is the design position this audit justifies: InventoryX is intended to read your Shopify quantities and writes nothing — its outputs are reports, a weekly Buying List, and draft POs you approve, so it cannot become a second version of the truth no matter how stale or confused it gets. What it does not do is replace your count app or your native PO workflow; V1 does not try. Whatever your stack, the honest test for any candidate is the one this audit uses: can it change the truth, and does it own the domain it wants to change?

Common questions

How many inventory apps is too many? There is no magic number — a count app and a reorder app and a barcode tool can coexist cleanly. The overlap test is the real limit: if two apps both claim the same domain (two reorder engines, two count tools), you have one too many in that domain, because you will silently favor one and pay for the other.

Which Shopify app is changing my inventory quantities? Check two places as of November 2026: each app's "Data access" disclosure on its App Store listing (edit inventory, write scopes), and the admin's inventory adjustment history, which records the source of changes. Any adjustment you did not make and did not sanction came from an app with write access — start with the ones installed most recently.

Why do two apps show different stock numbers for the same SKU? Almost always sync timing: each app holds a snapshot from whenever it last read Shopify, and sales, receipts, and adjustments since then create divergence. Do the timestamp math — subtract sales since sync, add receipts since sync. If the numbers reconcile, it is staleness. If they do not, one app wrote something it should not have.

Should the reorder app or Shopify own purchase orders? One owner per domain. If your team lives in native POs, receiving and incoming quantities live there too, and the reorder app should read from them — not maintain a parallel PO world. Running POs in two places is how "incoming" stops meaning anything, and every suggestion downstream inherits the confusion.

What is the first step of a stack audit? The truth-ownership table: list your data domains — quantities, incoming, suggestions, counts, velocity — and name one writer per domain. It takes ten minutes and immediately exposes overlaps and gaps. Then run the five-SKU divergence test to see which apps are stale, which are consistent, and which are writing where they should not.

Next step

Run the divergence test on five SKUs today and build the ownership table tonight — 30 minutes total, and most stacks find at least one write access worth revoking. If the audit turns up two apps fighting over the reorder decision, that is the consolidation question, and the four-tool decision walkthrough owns it; if it turns up numbers disagreeing inside Shopify itself, follow the not-updating diagnostic before blaming any app.