Cases · App check
Plan payments and phone apps added to an AI-built portal, checked and fixed
A sample engagement: the portal and its studios are fictional and hold test data, Stripe is in test mode, and the live portal was not touched. The payments and apps were built with Claude Code for this case; every finding comes from a real check of the build, on the website and on an Android emulator.
Goal
Getting paid adds money to everything a portal already does: a trial, moving up and down, cancelling, a failed payment, a refund, a studio handed to a new owner, a suspension, a plan the founder gives free. A studio paying in a phone app has to go through Apple's and Google's own purchases, with their rules on links, sign-in and deleting an account. The question: in what the builder handed over, does the money follow the founder's rules in every one of these cases, and would the stores accept the apps?
Challenge
The builder handed it over as working, and on the normal path it was: a studio could buy a plan on the website, renew, have a payment fail and be retried, and cancel to the end of the month. Its own words: "Cancelling is always allowed, even if the studio is bigger than Free allows." What was wrong sat on the less usual paths, which are the ones that cost money: studios that had paid plans before payments existed, a handover, a plan given free, the app on a phone, and the stores' rules.
Solution
First the founder's money table was written down: for every event, from buying to a refund, a handover, a suspension or a plan given free, what should happen to the plan and to the money, with the founder deciding the unclear cases. Then each cell was tried against Stripe in test mode, with time moved through trials, renewals and retries. The apps ran on an Android emulator and were compared with the App Store and Google Play rules on payments, sign-in, privacy and deleting an account. The fixes went back to the builder in plain words, in three rounds; in the second the builder added the stores' own purchases, and each round was checked again for what it fixed and what it broke.
Outcome
25 problems in what was handed over: 7 high, 7 medium, 11 low. Studios that were on Studio or Agency before payments existed kept their plan for nothing, and the founder's revenue counted them as paying; an owner whose studio was bigger than Free could not cancel at all; after a handover the previous owner's card kept paying; a plan the founder gave free went on charging the card; the apps sent owners to Stripe's card page, which Google Play refuses for a plan and Apple allows only on the US App Store; the store build without payments still asked people to upgrade; and clients could not sign in to the app, because the email link signed them in on the website in the browser. After three rounds 22 are fixed, 2 high in part, and 1 is left to the founder: Stripe's own emails. The fixes brought problems of their own. The in-app purchases added in the second round brought 4 high, all fixed in the third; the check after the third found 2 more high and 5 medium, listed in the report as open, such as moving up with a card the bank asks to confirm, which dropped a paid Studio to Free. A real engagement would go on with a fourth round. The iPhone app was checked from its project files only, with no Mac, and purchases ran in RevenueCat's Test Store, not in Apple's or Google's sandboxes. One build: the numbers describe it, not a rate for such apps.
From the case
The report, 22 pages (PDF)
Service
The same check for your app before the stores
You send the code, not your passwords or keys. Every problem comes with an example of what happens to the money, and every fix is checked again for what it broke.