Cases · App check
Billing and privacy review of a subscription app on Supabase and Stripe
A real, publicly available product, not a sample. Everything went to the owners privately first, and this page names neither the app nor any single finding while the findings are open.
October 2026: sent to the owners. Patches proposed, not applied yet.
The case
What was reviewed
A public web app on Supabase with a paid Stripe subscription. The review covered the subscription from checkout to renewal and cancellation; account data and privacy; plans and limits; who may read and change what in the database and server functions; and what the privacy texts promise.
What makes it hard
The subscription has to agree in two places, Stripe and the app. Part of the behaviour also depends on the owners' hosted settings, which a review from the public code cannot see, so the review had to separate what is certain from what depends on their answer.
How it was checked
Most findings were reproduced on the owners' code, and the report marks the ones that rest on the code alone, in whole or in part. Each patched finding was checked again with the patch, apart from four small changes. Eight findings, both high ones among them, were confirmed in Stripe test mode. Where a finding depends on the owners' settings, the report says so and asks.
Result
39 findings: 2 high, 11 medium, 26 low. The 27 proposed patches cover 26 of them, one in part, and the owners' own tests still pass with the patches applied. The other 13 have no patch yet, because most need a choice from the owners; the report gives the approach for each. Four findings depend on the hosted setup and may be withdrawn after the owners answer. Reported privately to the owners in October 2026. If the owners agree once the fixes are live, this page will name the project and describe the fixed findings.
Findings by area
| Area | High | Medium | Low | Total |
|---|---|---|---|---|
| Subscription and payments | 2 | 2 | 4 | 8 |
| Plans and limits | — | 6 | 7 | 13 |
| Privacy and account data | — | 2 | 9 | 11 |
| Who may read and change what | — | 1 | 6 | 7 |
| Total | 2 | 11 | 26 | 39 |
Severity follows the consequence and how likely it is. Worth fixing here means critical, high or medium: in a polished app with real users, a medium finding can still reach them.
What kinds of defects
Most findings fall into a few patterns that are common in apps of this kind:
- Subscription state that drifts from Stripe
- Plan limits not enforced everywhere
- Privacy promises the app does not keep
- Unreliable clean-up
- Gaps in who may change what
What the owners received
- A report with every finding: what happened, how it was confirmed, what the patch does and what is still open.
- 27 patches in small commits on their current code, grouped into blocks so they can stop after any block.
- 9 questions on the points only the owners can decide or see: their settings, their hosted setup, their product choices.
- An approach for the 13 findings with no patch: what would fix each one and what is needed from the owners.
- What the review could not see: their live service, their dashboard settings and any change made outside the repository.
Not a client job: the app was reviewed on my own initiative from its public code, without testing against the live site.
What a finding looks like
The findings of this app stay private while they are open. This is the same format, from the report on a sample shop.
Open the sample report (PDF)Any signed-in account can open any guest's order by its number
- AS RECEIVED
- The order page opens: name, street, city, email, phone, what was bought.
- AFTER THE FIX
- "We couldn't open this order."FIXED
- TEST
- A stranger's account asks for a guest's order. Failed before the fix, passes after.
Service
The same review for your app
You send the code or invite me read-only, not your passwords. Every finding comes with what happened, what should have happened and where it is in the code.