Ilya Shkura
EN UK RU

Services

Apps built with AI, checked and fixed: who sees what, and where the money goes.

I check and fix apps people build with Lovable, Bolt, Cursor or Claude Code, on Supabase or Firebase with Stripe, before they take money or once they already do. I look at who can see and change whose data, role by role; at payments, refunds and subscriptions that have to agree with Stripe; and at totals on screens that have to match what was paid. Every problem comes with an example, and every fix is checked again for what it broke.

What I do

01

Apps built with AI

An app built in Lovable, Bolt, Replit or Claude Code, on Supabase or Firebase, checked and fixed before it takes money, or once it already does.

  • Who can see and change whose data, payments and refunds, every problem with an example
  • You send the code or invite me to the project, never your passwords
  • Already live: read-only access first, fixes on a separate branch, nothing changed on the live app without your yes
Examples →

02

Reconciliation

Sales against payouts, or any two files that should agree.

  • Every mismatch, with both values
  • A table from one total to the other
Example →

03

Report checks

A report you already have, checked against the export it came from.

  • Every agreed figure beside its recount
  • What can't be checked, and why
Example →

04

Sales reports

Your orders export turned into a report for the period.

  • Drafted with Anthropic's Claude, every figure recounted by separate code
  • The questions only you can answer
Example →

05

Claude skills

Month-end numbers from Claude, counted your way: your definitions written down once, every figure from a script.

  • Shopify, Stripe, Amazon or another export
  • Or a check of your bookkeeper's report, or of your Claude skills
More →

Cases

Case studies I did on my own initiative: real apps from their public code, sample apps, and numbers on synthetic data in real export formats, so the right answers are known. One checks a fund's public documents.

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 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 →
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 →
Reconciliation€285,084between March sales and card payouts, explained line by line

Shopify sales vs Shopify Payments payouts

More details

EUR 529,976 of March sales against EUR 244,892 net for March card transactions. The gap explained to the cent; 1,439 of 1,444 card orders match their charge, eight records need a person.

The gap explained to the cent. 1,439 of 1,444 card orders match their charge. Eight records need a person, among them two customers who paid twice, by card and through PayPal (EUR 792.95), and a double charge whose fee was kept; separately, a chargeback on an order still marked paid. Of the EUR 244,892 net, EUR 15,943 was paid out in early April. 78 refunds the two files cannot place are listed, not guessed.

Read the case →
Report check8 of 35recounted figures were wrong, all from one line of code

AI sales report: 35 figures recounted, 8 wrong

More details

All 113 figures reviewed, 35 recounted from the export: 27 matched to the cent, 8 were wrong, all from one line of code. Net sales came out EUR 505.35 too high, and the same line moves nine more figures.

27 of the 35 matched to the cent and 8 were wrong, all from one line of code that took a shipping share out of partial refunds. Net sales came out EUR 505.35 too high, and the same line moves 9 more figures the check could not cover. The other 78 figures could not be recounted, each listed with its reason: not among the agreed definitions, per month where the definitions give the quarter, defined differently, or describing the data clean-up. The owner gets the report with a note beside every figure (7 pages) and the verification document (15 pages).

Read the case →

All cases →

How I work

  1. Code or files

    The code, or an invite to the project with the least access; for numbers, the exports as they are. Never your passwords.

  2. Rules in writing

    Who may see and change what in the app, or how each figure is counted. Unclear cases are yours to decide.

  3. Check, then recheck

    Every problem with an example and the steps to repeat it; every fix checked again; every figure recounted by separate code.

  4. You get the report

    What was found, what was fixed, what is left to you. Nothing changes in your live app without your OK.

Where an order ends

  • What is covered is agreed first: the cases to check (a case is one situation, such as “can a customer open someone else’s order?”), the kinds of users, and how many findings get fixed, worst first.
  • Every fix is checked again, with every test, for what it broke, and you see what that check found.
  • The order ends when the agreed cases pass, or with a list of what is left and why. Rare cases that need deliberate odd steps, or the payment provider to fail, are listed for you rather than chased round after round, unless you choose otherwise.
  • Anything new, such as another kind of user, a new feature or a problem outside the agreed cases, is quoted before I start on it.