MeterGap

1. One-liner

Compares what your Shopify app should have billed against what Shopify actually charged, and flags every silent gap.

2. Trend signal — why now?

On 12 May 2026 Shopify made Shopify App Pricing the default billing solution and shipped the App Events API for usage-based billing — the Billing API is now legacy (shopify.dev changelog). Every app that meters anything is being pushed onto a new revenue path.

The new path fails silently. Shopify’s own documentation states it plainly:

“The App Events API always returns a 202 response when it receives your request, even if the event fails billing validation.” “There’s no synchronous billing error response and no webhooks for billing validation failures.” “The Dev Dashboard is the only place to see billing errors — go to Logs and filter by App Billing Event.” — About App Events, shopify.dev

So the only sanctioned way to learn you weren’t paid is for a human to remember to open a dashboard and eyeball a log filter. That is not revenue assurance. That is hope.

Developers have already hit it. On the Shopify Developer Community forum:

• 31 July 2026 — “Events API returns {"success": true} but event count stays at 0 — both in the Dev Dashboard Logs and via the Partner API.” (thread) — no staff resolution posted.
• 15 July 2026, intersell — “I’m seeing a discrepancy between my billing events and the usage/charges shown in the UI.” Sent SUCCESS events for a 5% charge on $99.99, expected ~$5.00, dashboard showed $0.00. (thread)
• 20 Aug 2026, Alan_G — “202 only confirms that Shopify received the request. Billing validation happens asynchronously, and the Dev Dashboard under Logs → App Billing Event is currently the only place to inspect the result.”
• 26 Aug 2026, Kasi_Prasad — “Support confirmed the endpoint always returns 202 at transport and that billing validation failures surface only in the Dev Dashboard, with no webhook and no API… our only production detection of billing failures is reconciling our own ledger against activeSubscription.usage.quantity.” (thread)

Read that last one twice. A developer, unprompted, described the exact product — and then had to go build it himself.

There’s an older, chronic version of the same wound. On the Shopify community forum, developers have been reporting approved-but-unpaid usage charges since 2022 and were still reporting them in June 2026:

• Shipway (28 Dec 2022) — “we have around $20k lying in Usage charge and we have not received it.. pending for many stores for more than 10 months as well.”
• soulchild37 (16 Jan 2023) — “there’s quite a lot of stores (most are from India) where they have subscribed to my app for more than 4 months and they weren’t charged”
• B_8 (11 Dec 2024) — “we are seeing this as well on stores from India only… the payouts are still not even showing up in pending payouts.”
• RolandsK (20 Jun 2026) — “Just today got a store making mulitiple one time purchases for total of 2k+ USD from India.” (thread)

Meanwhile the general SaaS number: MGI Research puts billing-related leakage at 1–5% of revenue annually; metering gaps are cited as the single largest source for usage-based businesses (Orb, Lago).

Provenance:
  - Signal 1 (Demand): Shopify devs report SUCCESS billing events producing $0.00 charges and zero event counts, with no staff resolution — plus a 4-year-old unpaid-usage-charge thread still live in June 2026 — https://community.shopify.dev/t/events-api-returns-success-true-but-event-count-stays-at-0/36506 and https://community.shopify.com/t/not-receiving-usage-charge-applied-inshopify-payouts/178182 — 2026-07-31 / 2026-06-20
  - Signal 2 (Feasibility): Shopify shipped App Events API + Active Subscription API + Historical API in May 2026, giving third parties a read path to billed usage totals for the first time — https://shopify.dev/changelog/shopify-app-pricing-charge-for-usage-recurring-subscriptions-or-both — 2026-05-12
  - Signal 3 (Economic): 17,891 active apps from 11,352 partners; developers have earned $1.5B+ through the store; billing leakage runs 1–5% of revenue industry-wide — https://uptek.com/shopify-statistics/app-store/ and https://www.withorb.com/blog/revenue-leakage — 2026
  Category: Platform shift

3. The opportunity

Shopify just moved its entire app ecosystem onto a metering system that cannot tell you when it didn’t bill you. The failure is asynchronous, invisible at the call site, and surfaced only in a UI log a human has to remember to check.

The gap is structural, and it’s the same shape I keep finding: the platform self-reports the number, and nobody holds the counter-record.

Look at who exists. Cruxify, RevMetrics, Baremetrics, AppstorePulse and Elevate all sell Shopify Partner analytics — MRR, churn, trials, payouts, per-customer timelines. Every one of them reads the Partner API, which reports what Shopify billed. That’s the numerator. None of them hold the developer’s own record of what should have been billed. Without the denominator there is no diff, and without a diff you cannot detect a silent miss — an event that vanished looks identical to a month with less usage.

That is not an oversight on their part. It’s a positioning constraint: an analytics tool that only ingests Shopify’s feed can never contradict Shopify’s feed. To find the gap you have to ingest the developer’s side too, and that’s a different product with a different install.

So the incumbents sell you a beautiful chart of revenue you received. MeterGap tells you about the revenue you didn’t.

4. Target market

• Primary customer: Solo founders and 2–5 person teams operating one or more public Shopify apps with usage-based, credit-based, or percentage-based pricing — AI apps (content generation, image editing, chat, review summarisation), SMS/email senders, shipping-label and print-on-demand apps, anything charging per action. Typically $2K–$50K MRR. Global, skewed US/EU/India/Eastern Europe.
• Why they buy: In their own words — “our only production detection of billing failures is reconciling our own ledger against activeSubscription.usage.quantity” (Kasi_Prasad, 26 Aug 2026). They are already doing this by hand, badly, or not at all.
• Rough TAM reasoning: 17,891 active apps from 11,352 partners (Uptek). The median app earns under $1K/mo, so the addressable slice is the middle-and-up tier — the “$2K–$20K MRR” band where most successful small teams live (Week One Labs), plus the top 10% above $100K ARR. Call it 1,500–3,000 apps with meaningful metered revenue today, growing as App Pricing makes usage billing the default rather than a custom build. I’d rather under-claim here: this is a low-thousands market, not a hundred-thousand market. That’s fine for a $1–3M ARR business and terrible for a VC.
• Why now for them: Everyone metering is migrating in 2026. Migration is exactly when ledgers drift — the docs tell you to “keep sending Billing API usage records until no Billing API subscriptions remain,” meaning you run two billing systems at once and Shopify offers no reconciliation guidance for the overlap.

5. Product sketch (MVP)

• Shadow meter. A tiny SDK/webhook endpoint the developer calls at the same moment they fire a billing event — MeterGap records what should be billed, independently.
• Nightly diff. Pulls billed usage from Shopify’s Active Subscription and Historical APIs, compares against the shadow record per shop per meter, and surfaces every mismatch with a dollar value attached.
• Silent-failure alarm. Because a 202 means nothing, MeterGap watches for events that were accepted at transport but never appeared as billed usage, and alerts in Slack/email within 24 hours instead of whenever someone next opens the Dev Dashboard.
• Stuck-payout watch. Flags charges that were approved but haven’t converted to a payout past your app’s normal lag — the $20K-pending-for-10-months failure mode, caught in week one instead of month ten.
• Migration parity check. During Billing API → App Pricing cutover, runs both totals side by side and reports drift per shop, so you find out before the invoice does.
• Recovery packet. For each confirmed gap, generates a dated evidence file — event IDs, timestamps, expected vs. billed amounts — formatted to paste into a Shopify Partner support ticket.
• Leakage number. One headline figure: dollars identified as un-billed this month. That’s the renewal argument, restated every month.

6. AI angle — what’s load-bearing

Honest answer: the diff engine is deterministic, not AI. Comparing two ledgers is arithmetic, and I’d be lying if I dressed it up.

Where AI genuinely earns its place is classification and triage, and it’s not decoration:

• A raw diff on a busy app produces hundreds of daily mismatches, most of them benign — timing lag, proration, trial boundaries, refunds and negative-reporting corrections, plan changes mid-cycle. A rules engine drowns here because Shopify’s edge-case behaviour is, per the forum threads, undocumented. An LLM classifier over the event context separates “this is proration, ignore” from “this is $340 that vanished,” and that judgment is the difference between a useful alert and an ignored one.
• Support-packet drafting. Turning a cluster of event IDs into a coherent, specific Partner-support ticket that actually gets actioned is language work, and it’s the step developers most want to skip.
• Pattern naming. “Your gaps cluster on shops in one region with invoice-payment delays” is a conclusion drawn from messy operational data, not a SQL query someone specified in advance.

Strip the AI out and you still have a product — a noisier one with a worse alert-to-noise ratio and no drafted tickets. So the AI is load-bearing for usability, not for existence. I’m scoring the idea accordingly rather than pretending otherwise.

7. Localization angle

N/A — this is a global play. The customer is a Shopify app developer, who works in English against English-language APIs regardless of where they sit. There’s a mild India angle worth noting — multiple developers specifically identified Indian merchant stores as the locus of unpaid charges — but that’s a pattern in the data, not a localization wedge. No language, payment-rail, or pricing localization is needed.

8. Business model — path to $1M–$5M ARR

• Pricing: Tiered on metered revenue under watch, not seats.
  • Solo — $49/mo (1 app, up to ~$5K/mo metered revenue)
  • Studio — $149/mo (up to 3 apps, ~$50K/mo metered)
  • Portfolio — $399/mo (unlimited apps, priority migration-parity support)
• ACV: ~$1,800 blended.
• Rough math to $1M ARR: 550 customers × ~$150/mo × 12 ≈ $1M. Against 1,500–3,000 apps with meaningful metered revenue, that’s deep penetration of the addressable base — achievable but not casual. This needs to become the default install for metered Shopify apps.
• Rough math to $5M ARR: Does not happen on Shopify alone, and I won’t pretend it does. $5M requires the same shadow-ledger product pointed at other self-reporting platforms — Stripe usage-based billing, AWS Marketplace metering, Salesforce AppExchange, Atlassian Marketplace. The Shopify wedge proves the pattern; the platform count is what scales it. Anyone underwriting a $5M plan should treat Shopify as customer discovery, not as the market.
• Expansion path: More apps per account, then more platforms per account. Natural upsell: a “recovered revenue” success fee on gaps you actually claw back, which is where the pricing wants to go once you can prove recovery rates.

9. Go-to-market wedge — first 100 customers

1. Answer the threads that already exist. There is a live, unresolved forum conversation — the 202-silent-failure thread, the $0.00-usage-meter thread, the four-year unpaid-payout thread. Post a genuinely useful technical breakdown of how to reconcile your own ledger against activeSubscription.usage.quantity, with a free open-source script. The tool is the follow-up, not the pitch. These threads are indexed and pull developers in continuously.
2. Scrape the App Store for metered apps. The listing pages publish pricing. Filter the 17,891 apps for anything with per-use, per-credit, or percentage pricing — that’s a mechanically derivable target list of likely low thousands. Partner contact details are frequently on their listing or their own site. Send each one a one-screen artifact: “here’s how a 202 from App Events can still bill you $0.00, and here’s the check we’d run on your app.”
3. Free migration-parity audit. Every metered app is migrating off the Billing API this year. Offer a free one-off drift report across their cutover. It’s the highest-anxiety moment in their calendar, it requires their credentials (so it’s an install), and it produces a number. Free audits that surface real dollars convert; free audits that surface nothing cost you a support hour and buy goodwill.
4. Shopify partner communities. The Partners Slack/Discord groups, the r/shopifyDev and r/ShopifyAppDev subreddits, and the handful of newsletters read by app founders. This is a small, concentrated, highly-networked audience — under 15,000 people who matter. Word of mouth is unusually strong here, which cuts both ways.
5. Publish the leakage benchmark. After 50 customers, publish aggregate anonymised data: “across N metered Shopify apps, X% of billing events failed silently; median monthly leakage was $Y.” Nobody else can publish that number. It’s the content engine and the proof, in one asset.

10. Build complexity — justification

Low. The shadow meter is an ingest endpoint plus a thin SDK. The diff is scheduled jobs against three documented, read-only Shopify APIs (Active Subscription, Historical, Partner). The classifier is an off-the-shelf LLM call over structured event context. No custom models, no infrastructure novelty, no data you don’t get handed. A competent solo builder ships a credible v1 in 6–8 weeks; the real work is edge-case discovery in Shopify’s undocumented billing behaviour, which is exactly the knowledge that later becomes the moat.

11. Gating checklist

Gate	Pass?	Note
Legal in target market	✅	Read-only use of documented partner APIs with the developer’s own credentials.
Ethical — no harm / dark patterns	✅	Helps developers collect revenue they already earned. No merchant-facing surface.
Market exists (evidence above)	✅	Dated verbatim complaints 2022→2026, plus Shopify’s own docs confirming the gap.
1–5 person team can build this	✅	Solo, 6–8 weeks.
Launchable with <$50K / ₹40L	✅	Well under $10K.

12. Feasibility score

Axis	Weight	Score	Notes
Problem intensity	20	15/20	Real money, silently lost — but it’s invisible pain. Nobody feels a charge that never arrived. That’s the core tension: high stakes, low felt urgency until you show them the number. Not hair-on-fire until first diagnosis.
Demand evidence	15	11/15	Strong and dated: Shopify’s own docs admit the gap, multiple 2026 forum threads, one developer describing the exact product he had to hand-build, plus a four-year unpaid-payout thread. Docked for a small sample of loud voices rather than broad measured demand.
Build feasibility	15	13/15	Documented read-only APIs, deterministic core, off-the-shelf classifier. 6–8 weeks solo.
Distribution clarity	15	11/15	Named threads, a mechanically scrapeable target list, a concentrated community, and a free-audit hook. Docked because the total audience is small — you can reach nearly all of them, which caps upside as surely as it guarantees reach.
Revenue mechanics	15	10/15	Pricing is sane and the ROI argument is arithmetic. But $1M needs deep penetration of a low-thousands base, and $5M needs platforms beyond Shopify. Honest ceiling risk.
Time to first revenue	10	8/10	Free audit → paid conversion inside 4–8 weeks. The audit itself is the sales call.
Defensibility	10	6/10	Copyable in principle; the moat is accumulated knowledge of Shopify’s undocumented billing edge cases and the cross-customer leakage benchmark, which compound. Also: Shopify could ship webhooks for billing failures and take a bite out of this. Soft moat, not a hard one.
Total	100	74/100

13. Qualitative modifiers

Founder-fit tags

technical-heavy — the buyer is a developer, the sale is a technical argument, and the product lives inside their billing path. Credibility here is earned by being visibly right about Shopify’s edge cases, which is not a marketing skill.

Key assumptions to validate (3–5)

1. Assumption: Silent billing failures are common enough to find real money in a typical metered app — not a rare pathology affecting a handful of loud forum posters. How to test: Run free parity audits on 10 metered apps. Measure what fraction show >0.5% leakage. This is the whole idea; test it first.
2. Assumption: Developers will install a shadow meter into their billing code path. How to test: Offer the free audit and count how many complete the install vs. drop off. Integration friction into a revenue-critical path is the likeliest silent killer.
3. Assumption: They’ll pay $49–$399/mo rather than hand-rolling the reconciliation script themselves — this audience can build it, which is the awkward part. How to test: After the audit shows a number, quote the price and see who converts. Watch specifically whether they say “great, I’ll build that.”
4. Assumption: Shopify won’t close the gap by shipping billing-failure webhooks within 12 months. How to test: Track the developer changelog and the open forum threads; ask Partner support directly whether it’s on the roadmap.

Risk flags

1. Platform dependency (severe): This product exists because of a specific defect in one platform’s API. A single Shopify changelog entry adding billing-failure webhooks removes the headline feature. Mitigation is to broaden to Stripe/AWS/Atlassian metering early — the shadow-ledger pattern is platform-agnostic even though this instance isn’t.
2. Invisible-pain risk: Customers don’t wake up wanting this. Every sale requires first demonstrating leakage, which makes the free audit not a marketing tactic but the actual product-market fit mechanism. If audits routinely find nothing, there is no business.
3. Buyer-can-build-it risk: The customer is a competent developer who already knows how to compare two numbers. You’re selling the maintenance of edge-case knowledge, not the arithmetic. That’s a real sale, but a harder one than selling to a non-technical buyer.
4. Market ceiling: Low-thousands addressable base on Shopify. Attractive as a $1–2M bootstrapped business; structurally not more than that without multi-platform expansion.

14. Structured verdict

Score:                  74/100
Verdict:                GO
Confidence:             Medium
Best-fit builder:       Technical solo founder who has shipped a Shopify app and felt billing pain firsthand
Time to revenue:        6–10 weeks
Capital to launch:      $5–8K (₹4–7 lakh)
Top 3 assumptions to validate first:
  1. Typical metered app has >0.5% silent leakage — run 10 free parity audits, measure the hit rate
  2. Developers complete the shadow-meter install — measure audit-start to install-complete drop-off
  3. They pay rather than self-build — quote after showing the number, track "I'll build it myself" responses
Kill criteria:
  - Abandon if fewer than 4 of 10 free audits surface material leakage (>0.5% of metered revenue)
  - Abandon if Shopify ships webhooks for billing validation failures before v1 launches, and no
    second platform has been validated
  - Abandon if fewer than 15 of the first 100 audited developers convert to paid within 60 days

15. Next step — 1-week validation sprint

• Day 1–2: Build the reconciliation script only — pull activeSubscription.usage.quantity and the Historical API for a single app, diff against a developer-supplied event log. No UI, no product. Post it publicly in the three live forum threads as a free tool.
• Day 3–4: DM 25 metered-app developers identified from App Store pricing pages. Offer to run the diff on their app for free, this week. Target: 10 accept.
• Day 5: Run every audit that came back. Falsifiable outcome: of the completed audits, does at least 40% surface leakage above 0.5% of metered revenue — and when shown that number, do at least 3 developers agree to pay $49/mo before a product exists? If leakage is rare, the premise is wrong and no amount of product polish fixes it. Kill it and keep the script as a free artifact.