Repair guides / AI-built apps
Find the symptom. Run the check.
Start with what you can see going wrong.
Each guide gives you a short procedure you can run yourself, the evidence to read and a fix matched to each cause. Open the one that describes your broken journey. You do not need to know which library caused it before starting.
The two-minute check is a first pass, not a promise that every repair takes two minutes. Use a test account and disposable data when trying saves, deletes or private records. For an existing payment problem, inspect the payment already recorded before attempting another charge.
Keep the live address, the failed action and its time together. Those three details let you connect what happened in the browser with the right deployment or provider record. Share only redacted results; leave passwords, session tokens and secret keys out of messages.
01 / Symptoms
Publishing and display
A blank screen after you publish
The published address opens, but the screen stays empty even though the editor preview had content.
Separate a missing page, a failed script and a browser crash with a two-minute check of the published app.
Works in preview. Breaks live.
The editor demo works, but the same action on the public address fails or returns different data.
Compare one failing action across preview and production, then inspect the build and destination that actually served it.
Setup instructions that do not match the app
The README tells you to run commands or open files that are absent from the project you received.
Compare the README with actual package scripts and files before running setup on a fresh copy of your app.
Environment variables missing in production
The local app connects successfully, while the deployed app behaves as though a required setting is absent.
Check variable names, deployment scope and build timing without exposing secret values in the browser or logs.
An old version still showing after a deploy
The host reports a new deployment, but visitors still see the previous text, layout or behavior.
Compare the deployment URL, public domain and a fresh browser request before deciding which cache or publish target is stale.
02 / Symptoms
Accounts and private data
Login that stops working
Login rejects a known test account, loops back to the form, or returns you to the wrong address.
Trace one failed login from the submitted form to the return address without resetting users or weakening access rules.
Other users seeing your data
A signed-in account can open records that should belong only to another account.
Run an owner-versus-stranger check with two accounts you control and find which access boundary needs repair.
03 / Symptoms
Saving and deleting
Saved data that disappears
A success message appears after saving, but your new item is missing when you reload or use another browser.
Check whether one disposable record reaches storage, can be read back and belongs to the production project.
A delete that does not delete
An item vanishes after you click Delete, then returns when you refresh the page.
Follow one disposable item through deletion and a fresh read to separate a fake success from a policy or filter failure.
The same save creates duplicate records
Repeating Save or retrying a slow submission creates another copy of what should be the same operation.
Use a disposable record to distinguish two browser submissions from one request that creates two stored items.
04 / Symptoms
Payments and credentials
Payments that do not go through
Checkout fails, or payment appears successful while the app still treats the customer as unpaid.
Find whether a checkout fails before payment, inside the provider or while the app grants the purchased access.
Secret keys exposed in the browser
You find a key in downloaded JavaScript or a browser request and cannot tell whether it belongs there.
Identify a browser-visible credential by its provider and privilege before deciding whether to rotate it or repair access rules.
05 / Choose the next step
What the stamps mean.
WORKS means the stated check passed for the tested journey. BROKEN means the observation contradicts the behavior the app promises. FAKED marks a claimed result that the interface presents without doing the promised work. None of these stamps certifies an entire application.
Builder and stack pages appear only where the procedure changes. Choose a specific version from the base guide when it matches your setup. If your tool is absent, start with the symptom: the relevant boundary is often the database, payment provider or host.
Every guide includes its documentation and related case evidence. The studio records distinguish test fixtures from the studio’s own live apps. A related case explains what was observed there; it does not claim that your app has the same cause.
Let's look at it
What's
not working?
You don't need to explain it perfectly. Tell me what you expected and what happened instead.
I'll reply personally by email.
The diagnosis is free. No commitment.