Tools · 11 min read

Why your Shopify app is not an ops system

Shopify was built for DTC e-commerce. Your operation isn't.

Shopify is a very good piece of software. This is not an article about Shopify being bad.

It is an article about a category error that costs indie CPG brands eighteen months and a lot of money: assuming that because Shopify is where your business transacts, it can also be where your business operates.

Those are different jobs. Shopify does the first one extremely well. It was never designed to do the second one, and the app ecosystem that promises to close the gap mostly does not.

What Shopify is actually modelling

Every piece of software has a data model — an opinion, baked into its architecture, about what exists in the world and how those things relate.

Shopify's model is roughly:

Product → Variant → Inventory Level → Order → Fulfilment

That is a beautiful model for selling things online. It answers: what do we sell, in what versions, how many are at each location, who bought what, and did it ship.

Now consider what a food or supplement brand actually needs to answer:

  • Which raw material lots went into finished lot 4471?
  • Which supplier shipped those lots, and do we have current CoAs for each?
  • Which customers received units from lot 4471?
  • If we change the ascorbic acid supplier, which documents become outdated?
  • What is our true landed cost per unit, including freight, duty, and yield loss at the co-packer?
  • Which SKUs share this allergen, and does the label reflect the current formulation?

Look at what those questions have in common. Every single one is about something that happens before an order exists.

Shopify's model starts at the product. Your operational risk starts at the raw material, three or four transformation steps earlier. There is no variant field for "the lot of turmeric extract that went into this." There is no object for "batch record." There is no relationship between a supplier's CoA and a finished unit.

Not because Shopify built it badly. Because that is not what the product is.

The specific things it cannot represent

Five gaps, in roughly the order they cause pain.

1. Lots.

Shopify tracks quantity of a variant at a location. It does not track which units. Forty units of a supplement are forty units. Whether twelve came from a batch made in March and twenty-eight from a batch made in June — with different input lots, different CoAs, different expiry dates — is invisible.

The moment you need traceability, recall capability, or expiry management, this is the wall. It is a structural wall, not a feature gap.

2. Transformation.

Your co-packer takes eleven raw materials and produces one finished good. That is a manufacturing event with inputs, outputs, a yield, a date, an operator, and a set of quality checks.

Shopify has no concept of this at all. The finished units simply appear in inventory when someone adjusts the count. The entire manufacturing step — the part where your product actually becomes your product — happens off-platform, in a spreadsheet or a co-packer's PDF.

3. Documents that belong to things.

A CoA belongs to a raw material lot. A batch record belongs to a production run. A spec sheet belongs to a supplier-material pair. An allergen statement belongs to a formulation version.

Shopify has metafields, and people do heroic things with them. But a metafield is a value attached to a product. It is not a document attached to a lot that also links to the supplier that provided it and the finished goods that contain it. That is a graph, and Shopify is not storing a graph.

4. Anything upstream of purchasing.

Purchase orders, supplier lead times, minimum order quantities, raw material inventory, reorder points based on production plans rather than sales velocity. Shopify's reorder logic, where it exists, reasons from sell-through. Your raw material reorder logic has to reason from a production schedule, supplier lead time, and MOQ constraints — a completely different calculation.

5. Wholesale, properly.

DTC and wholesale are not the same business wearing different hats. Wholesale has price lists per account, payment terms, purchase orders that arrive as PDFs, pallet-level shipping, chargebacks, and — increasingly — traceability data requirements attached to every shipment. Shopify has improved here, and B2B features exist. But a brand doing meaningful volume through distribution consistently finds the model straining.

Why the app store doesn't close the gap

The reasonable response is: there are 8,000 apps, surely one handles this.

Some genuinely help. But three structural problems limit how far the app route goes.

Apps inherit the host's data model.

An app can add its own tables, but it has to attach them to Shopify's objects — products, variants, orders. An app that wants to track lots ends up maintaining its own parallel lot ledger and reconciling it against Shopify inventory counts. That reconciliation is where drift lives. You have not eliminated the sync problem; you have hidden it inside a subscription.

Apps don't talk to each other.

You end up with an inventory app, a wholesale app, a subscriptions app, and a reporting app. Four data models, four opinions about what an "order" is, four monthly fees. The inventory app doesn't know why the subscriptions app decremented stock. Nobody owns the resulting mess.

I would flag that this varies a lot by stack, and some app combinations integrate genuinely well. But the general pattern — that integration quality degrades roughly with the square of the number of apps — matches what most operators report.

Apps optimise for the median customer.

An app serving 20,000 merchants is built for the middle of that distribution. If your operation has a genuine peculiarity — a co-packer who reports yields weekly in a specific format, a private-label line with different documentation requirements, a regulatory regime specific to nutraceuticals — you are in the tail. The app will handle 80% of your case and the remaining 20% goes back into the spreadsheet, which means the spreadsheet still exists, which means you now pay for both.

The honest test

Before evaluating any tool, run this. It takes an afternoon and it is more useful than any vendor demo.

Pick a finished lot you shipped three to six months ago. Then, using only the systems you have — no phoning the ops manager, no memory — answer:

  1. What raw material lots went into it?
  2. Which supplier supplied each, and what is the CoA number for each?
  3. What was the production date, and who ran the batch?
  4. What was the yield versus theoretical?
  5. Which customers and which retail accounts received units from it?
  6. Is the label currently on shelf consistent with the formulation used?

Time it. Note where you had to leave Shopify.

Almost everyone leaves at question 1.

That is not a failing of your setup. It is the boundary of what Shopify models. The useful thing about the exercise is that it tells you precisely where the boundary sits for your business — which is the only thing that should determine what you build or buy next.

So what does Shopify keep doing?

This matters, because the wrong conclusion is "rip it out."

Shopify should remain your commerce layer. It is excellent at storefront, checkout, payments, customer records, DTC fulfilment, and the entire demand side. Replacing it with an ERP's e-commerce module is a downgrade, and brands who do this regret it.

What you need alongside it is an operations layer that owns:

  • Raw material and finished lot records
  • Supplier and material specs
  • Production runs and transformation genealogy
  • The document chain — CoAs, batch records, compliance files, linked to lots
  • Change propagation: when a formulation or supplier changes, what else must update

And a narrow, one-directional integration between them. Typically: the ops layer is the source of truth for what exists and where it came from; Shopify is the source of truth for what was sold and to whom; finished-goods availability flows one way.

The critical design decision is one-directional. Bidirectional sync between two systems that both think they own inventory is the origin of most integration horror stories. Pick which system is authoritative for each fact, and be ruthless about it.

The gap this leaves

Here is the awkward part.

Between "Shopify plus apps" and "real manufacturing ERP" there is a genuine void for brands roughly between $300K and $5M in revenue.

The apps cannot model your operation. The ERPs can, but they price and implement for companies with a dedicated ops team, a six-month implementation window, and a consultant on retainer. Brands in the gap either over-buy and under-deploy, or under-buy and keep the spreadsheet.

The third option — building a thin, custom operations layer that models your specific relationships and integrates with the Shopify you already have — has historically been too expensive to justify. That economics has changed considerably in the last two years. It is now often cheaper than a mid-tier ERP implementation and produces something that actually fits.

But whichever route you take, the first step is the same: stop asking "which app solves this" and start asking "what does my operation actually consist of, and which of those things does my current stack refuse to represent?"

Shopify will tell you what you sold. It was never going to tell you what you made.


Custom Mango builds operational software that sits alongside your existing commerce stack rather than replacing it. Book a FoundationSprint to map what your current tools can't represent.


Custom Mango builds operational software for growing food, supplement and beauty brands. If this article hit close to home, book a free discovery call — the first conversation is about your business, not about software.

← Back to all articles