What to check before you accept a fixed AI-built app

The short answer

“It’s fixed” is a claim about one machine at one moment. Acceptance has to show it is fixed on your live app, on your accounts, for your users, and that you can keep it that way without the developer in the room.

So before the final payment, do four kinds of checks yourself: follow your own reproduction steps on the live app; check the places a desktop demo never shows (phone, fresh browser, a new user); confirm the code, settings and accounts are all yours; and deploy one small change yourself from the README. The acceptance list on the AI-built app job page is the short version. This guide is the long one, with the reasons.

Why a fix can pass a demo and still not be fixed

Most “it worked when they showed me” failures come from the difference between where the developer tested and where your users are. I build and run my own automations with an AI coding tool, and my records have three versions of this.

The settings were there by hand and missing when it ran by itself. A publishing job of mine worked when I ran it by hand. When the scheduler ran it, the login token was empty. The token lived in a settings file that the manual route loaded and the scheduled route did not. Nothing crashed; it just failed quietly. For an app, the same gap shows up as settings and keys that exist on the developer’s machine or preview but not on the live host.

The page was fine on a laptop and broken on a phone. On a site of mine, a table that looked right on desktop broke apart on phones, down to single letters per line. The build and its automated audit had passed. It turned up only when I checked the pages at phone size.

A check said “OK” and the code still failed. A small script of mine passed a syntax check that reported everything fine, then failed when it actually ran, because of where one line break sat. A tool saying the code is valid is not the same as the code working.

None of these needed a better developer. They needed a test run in the place where it counts.

The ten checks before final payment

Checks 1 to 5 test the fix. Checks 6 to 10 test whether it is yours. Both halves matter: a fix you cannot deploy again is a fix that lasts until the next change.

What to verify rather than take on trust

A hand-over note is a description of what someone believes they did. It is worth checking against reality once.

I learned this from my own notes. I had written down that I had changed a setting on my scheduled jobs so they would run while nobody was logged in. A week later I checked the jobs directly: none of them had the new setting. The change needed administrator rights, and it had not actually been applied. My note was sincere and wrong. I wrote a rule into the project notes afterwards: before leaving anything to run unattended for days, check the actual state with one command instead of trusting the document.

For an app, the equivalents are simple:

The note says	Check it by
“Keys are in environment settings”	Open the hosting dashboard and look; search the repository for the key’s first characters
“Access between users is fixed”	Check 4 above, yourself
“Deployed to production”	Open the live site in a fresh browser and follow the steps
“Tests added”	Ask to see them run, and what they check, in plain words

This is not distrust. Good developers expect it, and many will offer a short walkthrough video or call. The job page notes which sellers mention walkthroughs and documentation in their gigs.

What to ask for in writing

Put these in the brief so the fixer quotes for them. The AI-built app brief has fields for most of them:

• A note per fix: what broke, where, and why.
• A “change together” list: places where one change needs another. It is what stops the next edit from undoing this one. Why your AI-built app breaks after every change explains why this list matters most.
• A README you have tried: how to run it, deploy it and roll back.
• The settings list from check 7.
• The security list from check 10.

If you will keep editing with the same AI tool, also ask for its standing instructions file to be updated with the “change together” list. What a Claude Code expert actually does covers that file.

When it fails a check

A failed check before payment is normal and cheap. Send the developer the step, what you expected and what happened, with a screenshot. Most fixes at this stage are small.

If the same kind of check keeps failing, ask for a short call rather than another round of messages. And agree now who fixes things found in the first 30 days, and at what rate. That is a line in the job page brief, and putting maintenance in the contract covers the rest.

If you are not sure the app is worth fixing at all, a paid review first is the smaller step. On the job page, Amish Sohail offers a review of vibe-coded sites before you commit to bigger fixes.

Wrap-up

A fixed AI-built app is accepted when the problems no longer reproduce on the live app, on a phone and for a new user, and when you can deploy it yourself from your own accounts. Run the ten checks, verify the hand-over note once against reality, and get the fix notes and the “change together” list in writing. Then the fix outlives the order.