Ilya Shkura
EN UK RU

Cases

Four real apps, 100 findings worth fixing.

I reviewed these apps on my own initiative, from their public code: 1 critical, 26 high and 73 medium findings, plus 121 low. The owners were told privately first, and the pages name no app while its findings are open. Below them are sample apps I checked and fixed, two of which you can open yourself.

App checks

The first four are real apps. The others are sample apps with test data.

App check26findings worth fixing in a live app on Supabase and Stripe: 1 critical, 9 high, 16 medium. 63 in all, with the low ones.October 2026: sent to the owners. Patches proposed, not applied yet.

Access and payment review of a live Supabase and Stripe app

More details

A live web app on Supabase and Stripe. The review found 63 findings: 1 critical, 9 high, 16 medium and 37 low. The owners received a report, 58 patches and 15 questions privately, before this page.

63 findings: 1 critical, 9 high, 16 medium, 37 low. The 58 proposed patches fix 49 in full and 8 in part, and the owners' own tests give the same results before and after, apart from the tests that two patches update to the new rules. Five findings are left to the owners, because their fix needs a decision only they can make; one was left unchanged on purpose, with the reason. 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.

Read the case →
App check7findings worth fixing in an app on Supabase and Stripe: 2 high, 5 medium. 17 in all, with the low ones.October 2026: owners contacted. The full report and patches follow once they reply.

Payment and access review of an app on Supabase and Stripe

More details

A public web app on Supabase and Stripe. The review found 17 findings: 2 high, 5 medium and 10 low. Proposed patches fix 14 in full and 2 in part, and the owners' own tests pass before and after.

17 findings: 2 high, 5 medium, 10 low. The 19 proposed patches fix 14 in full and 2 in part. The owners' own tests pass before and after; one of them is updated to a patched rule. One finding is left to the owners as a question, because its fix depends on a product decision. The owners were contacted privately in October 2026. If the owners agree once the fixes are live, this page will name the project and describe the fixed findings.

Read the case →
App check54findings worth fixing in an app on Supabase with a Stripe subscription: 13 high, 41 medium. 102 in all, with the low ones.October 2026: owners contacted. The full report and patches follow once they reply.

Access and subscription review of an app on Supabase and Stripe

More details

A public web app on Supabase, sold by subscription through Stripe. The review found 102 findings that are still open in the owners' latest code: 13 high, 41 medium and 48 low. Patches for most of them are drafted and will be rebuilt before they go out.

102 findings: 13 high, 41 medium, 48 low. Patches are drafted for most of them: a first set gave the same results on the owners' own tests as their code did, and it will be rebuilt before it goes out. Some findings are left to the owners, because they need a decision only the owners can make. The owners were contacted privately in October 2026. If the owners agree once the fixes are live, this page will name the project and describe the fixed findings.

Read the case →
App check13findings worth fixing in a subscription app on Supabase and Stripe: 2 high, 11 medium. 39 in all, with the low ones.October 2026: sent to the owners. Patches proposed, not applied yet.

Billing and privacy review of a subscription app on Supabase and Stripe

More details

A public web app on Supabase with a paid Stripe subscription. The review found 39 findings: 2 high, 11 medium and 26 low. The owners received a report and 27 proposed patches, covering 26 of the findings, privately, before this page.

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.

Read the case →
App check28problems found in a shop its builder called finished; the worst let any new account read guests' addresses; 24 are fixed

An online shop built with AI, checked and fixed

More details

A knitwear shop built with Claude Code from 17 plain-language messages looked finished. A check found 28 problems: the worst let any new account open guests' orders with their addresses, and three more touched money or customers' details. 24 are fixed, each with its own test.

28 findings: 1 critical, 3 high, 10 medium, 14 low. Any new account could open an order placed without an account by its number and read the name, address, email and phone; order numbers ran in sequence, and about four in ten orders were guest orders. After a dropped connection the next customer on the same device was shown someone else's order; the owner could record a €500 refund on a €29.99 order; a customer could pay €27.99 by card for an order already cancelled and not get the money back; the newsletter form would send the shop's email to any address, any number of times. 42 of 51 tests failed on the shop as received, none after the fixes. 24 findings are fixed; 4 low ones are left to the owner, with the reasons. The reviews of the fixes found more, part of it brought by the fixes themselves; those rounds are outside these numbers. One shop, built once: the numbers describe this shop, not a rate for apps built this way.

Read the case →
App check29problems in a client portal its builder called finished; the worst let a client read the studio's private notes about them; all 5 high are fixed

A client portal built with AI on Firebase, checked and fixed

More details

A portal where design studios share work with their clients, built with Claude Code on Firebase from 12 plain-language messages, looked finished. Checked role by role, it had 29 problems: a client could read the studio's private notes, the studio could approve work in the client's name, and file links kept opening after access was gone. All 5 high are fixed, and the fixed portal is live.

29 problems in the portal as delivered: 5 high, 12 medium, 12 low. A client's people could read the notes the studio kept about them; anyone on the studio's side could record a client's approval in the client's name and rewrite past decisions; a file's address kept opening after the person lost access or the studio was suspended; an uploaded HTML or SVG file opened as a page on the portal's own address. After three rounds 26 are fixed and 3 partly; no high is left. The fixes brought 2 high and 6 medium of their own, such as names in Cyrillic or with accents, like Émile, that could no longer sign up; both high and half of the medium are fixed. Left for the owner: 3 medium that take deliberate odd steps, such as a look-alike letter from another alphabet in a name, and some low. 12 more places where the owner later decided differently from what the builder had reasonably done were changed too and are not counted as the builder's mistakes. One portal, built once: the numbers describe this portal, not a rate for such apps.

Read the case →
App check27problems in plan payments and phone apps an AI added to a client portal; 25 fixed after ten rounds

Plan payments and phone apps added to an AI-built portal, checked and fixed

More details

The Folioport client portal got two more things, asked for in plain words: paying for the Studio and Agency plans through Stripe, and apps for the App Store and Google Play where a studio can pay too. Claude Code built both, and on the normal path they worked. Checked against the founder's money table and the stores' rules, they had 27 problems: studios already on paid plans kept them for nothing, a studio bigger than Free could not cancel, a plan given free kept charging the card, a suspended studio was charged and could not cancel, the apps sold plans in a way the stores refuse, and clients could not sign in to the app at all. 25 are fixed.

27 problems in what was handed over: 3 critical, 9 high, 5 medium, 10 low. The worst cost money: after a handover the previous owner's card kept paying, a plan the founder gave free went on charging, and a suspended studio was charged and could not cancel. Studios already on paid plans kept them for nothing, an owner whose studio was bigger than Free could not cancel, the apps sold plans in a way the stores refuse, clients could not sign in to the app, and on iPhone and Android the menu could not be tapped. Nine problems would have stopped the apps at Apple's or Google's review, five in the version handed over and four brought by the fixes; eight are fixed. Two of the nine were judged from the code and settings, not a run: taking a photo on iPhone, and a plan change in the US build, the one still open. Why ten rounds: in the second the founder asked for the stores' own purchases, which brought problems of their own; then the founder settled rules the money table had not covered, such as how long to wait when the bank asks to confirm a payment; the last rounds dealt with rarer mixes of a cancel, a handover and a payment, until every new one needed Stripe to fail. The iPhone app ran only in the simulator, and purchases in RevenueCat's Test Store. One build: the numbers describe it, not a rate for such apps.

Read the case →
Automation check6problems in books an AI built in n8n for a web shop, from VAT on invoices to a refund that failed after it succeeded; all six are fixed

A shop's books in n8n built with AI, checked and fixed

More details

A linen shop's books in n8n, built with Claude Code from plain-language messages: every Stripe payment and web-shop order booked, a PDF invoice or credit note with a number that never skips, SEPA, refunds, disputes, three currencies, a morning summary and the accountant's monthly export. Everyday card sales were right. Six things were not: VAT for two kinds of business customer, a refund Stripe fails hours after saying it succeeded, a summary that read "net €0.00", booking that stopped without a word while the shop's database was silent, and the shop showing different VAT from the invoice. All six are fixed.

6 problems: 4 medium, 2 low. An Austrian company with a German VAT number was charged Austrian VAT, €33.00 of a €198.00 total, instead of reverse charge; a Latvian business with goods going to Berlin was charged German VAT instead of Latvian; a refund Stripe failed two hours later stayed in the books as paid back, and the customer kept a credit note for money they never got; while the shop's database was silent for 12 minutes nothing was booked, not even payments that had nothing to do with the shop, and no alert went out; on days with bank transfers the morning summary opened with "net €0.00"; the shop showed 21% VAT while the invoice charged the delivery country's; the builder had pointed this one out, and the owner first asked to leave the shop as it was. All six are fixed: the wrong invoices cancelled by credit notes and reissued, the owner alerted within a minute, the shop and the invoices on the same VAT. Of 133 checks, 9 failed as handed over and none on the final version. Payouts couldn't be seen in test mode; the report lists that and the other limits. Left to the owner: the fee Stripe takes on bank transfers, and a database login that can only read. One automation, built once: the numbers describe these books, not a rate.

Read the case →

Other work: numbers and Claude skills

Claude skills

Reconciliation

Report checks

Sales reports & analysis