My app told its first merchant that $144 million was blocked. The whole catalog came to $383,000.

Feedwatch finds the products in a Shopify catalog that Google Shopping and Meta will not list, such as those with no image or no brand, and the ones Google may show less. A list of product names is useful. A list of product names with a figure on top is what gets read. So from the first version, the home screen led with money: what the invisible part of the catalog is worth.

The question was which money.

Version one: price times stock

The first definition felt like the careful one. For every affected variant, take its price and multiply it by how many units are in stock. That is the value sitting in the warehouse that shoppers cannot find. The site said so, too: “Every issue is priced in your own stock.” The script for my demo video went further: “That number is not an estimate.”

Then the first real merchant installed it.

Their catalog was dropshipped. Every variant price in it added up to about $380,000. Feedwatch told them that more than $140 million was blocked.

No arithmetic was wrong. An importer had written hundreds of units of invented stock onto every variant, the way some import tools do, and I had multiplied by it. The one number on that screen I had called “not an estimate” was built on the only input in it that was one.

The merchant sets the price. I can read it, and so can they, on the product’s own page. Nobody sets the stock count on a dropshipped store; it is whatever the importer wrote. A figure a merchant can disprove by walking into their own stockroom, or here by knowing they do not have one, costs more credibility than it ever earns.

So stock came out, of the formula and of the query. Feedwatch no longer asks Shopify for inventory quantities at all, and a test fails if any part of the scan ever asks again.

Version two: add up the variant prices

Without stock, the next obvious move was to add up the price of every affected variant.

On the same catalog that came to about $278,000, and one product was just over half of it. It had eighteen variants, sizes and colors, each carrying the full price. Three products were almost three quarters of the total. The same item sold in a single color would have counted for a twentieth as much.

That measures how the catalog happens to be shaped, and little else. And again, nobody can check it: no merchant adds up more than four hundred variant prices to see whether I got it right.

Version three: one of each, at its lowest price

What the screen shows now is one unit of each affected product, at its lowest listed price above zero.

The number is smaller. I kept it for three reasons. The merchant can check it, because the lowest price is on the product’s own page. It never overstates, because it is never more than any variant sells for. And it does not move for the wrong reason: a product that gains a new size does not suddenly count for more.

Under the figure, in smaller type, the screen says what it is: one of each at its lowest listed price, no stock estimate. The count of products sits right under the money, on every screen, because on a small shop the money is small and the count is the part that still means something.

What I took from it

The mistake was not the multiplication. It was calling the result a fact. I had one input the merchant controls and one I was guessing at, and I presented the product of the two as if both were solid.

Every figure Feedwatch shows now has to pass one test before it ships: could the merchant open their own admin and check it? If the answer is no, the figure is either wrong or unfinished, and either way it does not go on the screen.