You check an app you paid for by asking for demonstrations and grading the answers that come back. The code is out of reach, and running things yourself is a later step, so the instrument you have is a conversation. Eight requests cover almost everything that goes wrong on a delivered app, each one has a shape that a straight answer takes and a shape that a stalling answer takes, and holding both shapes in your head is the whole method.
This page gives three things: the eight requests, the answer key for grading what comes back, and the point where no answer is enough and somebody has to open the code. If you have been searching how to check an app a developer built for me, or how to check work a developer did for me, that list is the answer, and it works whether the app was built by hand, by a machine, or by both.
Checking an app a developer built for you runs on eight requests you can make in one message. Ask to be shown the running app, the last recorded error, the check before release, the public surface, a second customer account, the accounts in your name, the route for the next person, and what was left unfinished.
Everything below about how the people who sell app reviews describe their own process comes from reading three of their pages on 25 August 2026, and every question in the table was checked against what AxonBuild’s fixed study of 26 AI-built applications audited in June and July 2026 actually found missing. No app was examined for this page, no tool was run, and nobody’s contractor was contacted.
What you are actually checking when you cannot read the code
Three separate questions hide inside “is it any good”, and they have different answers. Does the app do the things you paid for. Does it hold up when somebody uses it carelessly, or in bad faith, or at the same time as a hundred other people. Can anybody other than this one person keep it running next year. Most disputes that end badly are the third question wearing the clothes of the first: the features work, the owner is happy, and then the builder stops replying and nobody else can start the thing.
If the person you paid built it with AI tools, one more thing changes: where the weak spots sit, and how often each one turned up when a fixed set of AI-built apps was examined. That shifts what is worth asking about first. It does not change the requests themselves, and it is not evidence that anybody cut corners.
Working out what the app was actually built with, and whether AI wrote most of it, is a different question with its own visible signs, and it changes none of the requests below. Treat it as settled in either direction and keep going.
The same things can be wrong under an app nobody was paid to build, and checking an app you built yourself starts from a different place, because there is no one to ask. Having somebody to ask is the advantage you are holding here, and it is worth spending before it expires. If somebody outside is about to look at the same app, an investor’s technical reviewer or a large customer’s vendor review, the list an outside reviewer works from is a different document with a different order.
One limit on all of this, stated plainly because the rest of the page depends on it. An answer is evidence about the person as much as about the app. A builder who cannot show you the last error a customer hit might have a gap in the app, or might not know where to look, or might be avoiding the question. The request separates those three, because it asks for a thing that either opens on screen or does not.
What to ask a developer about the app they built, and what a good answer sounds like
Three companies currently rank on Google for audit an app someone built for me, and all three answer a different question than the one an owner is asking. Valletta Software publishes a review workflow the owner is meant to work through themselves. Productera publishes a security walkthrough that starts by installing a coding agent from npm and pointing it at the project directory. Hoyack publishes an intake form for a fixed-fee review with a two-week process and a list of what gets handed over at the end. As of 25 August 2026, none of those three pages gives the owner a single question to put to the person who built the app.
Those three pages were read on 25 August 2026 and are named without links, because all three sell work that competes with AxonBuild’s: vallettasoftware.com/blog/post/code-review-vibe-coded-apps, productera.io/audit-guide and hoyack.com/ai-vibe-code-audit/.
The eight requests are ordered so the easy and least confrontational ones come first. Every one of them is something the builder can show you while you watch, and none of them asks you to understand what you are looking at.
| What to ask for | What a straight answer sounds like | What a stalling answer sounds like |
|---|---|---|
| Open the app the way a customer does, sign in on an ordinary paid account, and do the one thing I paid for while I am watching | The builder signs in on a normal account, does the thing end to end in the live product, then reloads the page and the result is still there | The builder opens the code where the feature lives, plays a recording made earlier, or says the feature shipped in the last release and the demo account is broken |
| Show me where the last error a customer hit was recorded, and read it out to me | The builder opens the place errors collect, finds the most recent one, and says the time it happened and the page it came from. So does “nothing records them”, which is the answer 17 of the 21 third-party apps in AxonBuild’s fixed June to July 2026 study gave, counted from that study’s findings ledger, and set out in what 26 audited AI-built apps actually contained | The builder says errors are logged, or that the hosting platform handles it, without naming the place they are kept or opening it |
| Show me what runs between somebody making a change and customers seeing it | The builder names the check that runs on every change, says what happens when it fails, and points at a time it stopped something from going out | The builder says changes are tested before release without naming what runs, or explains that the platform deploys automatically, which describes the shipping and not the checking |
| Tell me what a stranger can do on this app without signing in at all | The builder names the pages and actions that are open to the public and says what each one can reach. An honest list is normal: 11 of the 21 third-party apps in the same study had an endpoint doing privileged work with nobody signed in, counted from that study’s findings ledger | The builder says nothing important, or that everything sits behind the login, without naming the public pages that obviously exist, such as sign-up and password reset |
| Make a second customer account in front of me and show me it cannot see the first one’s data | The builder creates the second account while you watch, signs into it, opens the place the first account’s data would appear, and it is empty | The builder says the database is secure, names a security feature by its product name, or offers to check and come back to you |
| Tell me which accounts and cards are in my name and which are in yours | The builder goes down the list out loud, account by account, and says whose login and whose card is on each: hosting, code repository, database, domain, AI provider, payment processor, email sender | The builder says everything gets transferred at the end, or that it is all under an agency account for now and that is how it is normally done |
| Show me what a different person would need to make a change next month | The builder names where the code lives, how somebody else would run it on their own machine, and which passwords and keys a new person would need on day one | The builder says any developer can pick it up, or that it is all standard, without naming the place a new person would start |
| Tell me what you did not finish, and what you would fix first if you had a week | The builder names two or three specific unfinished things and picks one. Nobody’s app is clean: of the 26 applications in AxonBuild’s fixed June to July 2026 study, 22 came out red and none came out green | The builder says nothing, or that it is all done, or lists work that would be a new purchase rather than work that was already owed |
The pattern running down the middle column is the thing worth memorising, because it survives every topic on the list.
A straight answer names a specific thing that can be opened. A stalling answer names a category.
“The errors go to our monitoring” is a category. “Here is the one from Tuesday at 14:12, from the checkout page” is a thing. That difference holds even when you have no idea what monitoring means, which is why the grading works without technical knowledge. It also explains why asking to be shown the running product rather than the code is not an insult and not an accusation. Code is where a feature can exist without ever running, and the audits kept finding exactly that: a safety control written into a file that no request ever reaches. Asking for the running app is asking a smaller question, not a ruder one.
Behind the second request sits a companion topic worth knowing about, the failure that hides behind a success response, where the app answers every request successfully while the work behind it quietly fails. Grading the third request is easier if you already know what a check that runs before a change actually is and what only looks like one.
The request almost every owner skips is the seventh, and it is the one with the longest tail. Nobody wants to open a conversation about what happens if this person leaves while the person is still working for them. It costs nothing to ask, it is the only request whose answer you can still use a year later, and a builder who answers it well has just told you something no other question reveals. If the honest answer to the last request is that a chunk was never started, buying the missing part is priced from a named list rather than from a percentage.
How to tell a stalling answer from an honest no
Most of the gaps on that list are ordinary. They are what code generators leave out by default, and at least one “no, we do not have that” is the answer an honest builder gives to a set of eight requests like this. Reading every no as a confession is the fastest way to lose a working relationship over something that would have taken an afternoon to add.
AxonBuild’s fixed study of 26 AI-built applications audited in June and July 2026 recorded, across the 21 third-party apps in the study, 958 confirmed findings, about 46 per app, of which 58 were critical, all counted from that study’s findings ledger with every finding checked against the code rather than pattern matched. Forty-six items per app is the number that frightens owners when they hear it. Fifty-eight criticals across twenty-one apps is the number worth acting on.
A long list of findings is not itself a finding, and a short list is not itself reassurance.
Owners usually phrase the worry to themselves as how do I know if my developer did a good job, which has no answer, because it asks about a person and you can only see the app. The eight requests work because each one converts that into something with a yes or a no attached to it.
Two classes of no are worth treating differently from the rest. The first is personal data. Personal data was exposed in at least 5 of the 21 third-party apps the same study covered, and the count says at least because the study’s ledger keeps the notable findings rather than every one of the 958. If the app holds customer names, addresses, health information or anything a customer would be upset to see published, “we have not looked at that” is not an ordinary answer and it does not get to wait. The second is anything a stranger can reach without signing in. A gap behind a login needs somebody with an account to find it. A gap in front of the login is available to everybody, all the time, including automated traffic that is not looking for your app specifically.
Listen for vagueness about what runs. That is the tell, more often than a missing control is. A builder who says the app has no error recording has told you a fact you can act on. A builder who says errors are handled, then cannot say by what, has told you they do not know what the running app does, and that is the more expensive problem of the two.
What to gather before you ask
Three things are worth having in front of you, and none of them requires opening anything technical. This is not a procedure and there is nothing here to run.
The first is what you actually paid for, in writing. Whatever exists: the quote, the email thread where the features were agreed, the invoice line items. The eighth request only works if you can compare the answer against something.
The second is what you have already seen work with your own hands, as an ordinary user. Set aside what you were shown in a demonstration and what the interface implies. Sign up, pay if there is a payment, use the app for ten minutes as a customer would, and write down which of the things you paid for you have personally watched happen. Some of this you can see for yourself first, from a browser and an email address, and the short procedure for looking without touching the code is worth doing before the conversation rather than during it.
The third is which accounts you can already sign into yourself. One owner, asking other founders what had actually been hard after they switched the people building their product, posted the list in full:
things like GitHub access, cloud accounts, databases, domains/DNS, app store accounts, API accounts, production credentials, deployment knowledge, backups, etc. Did your company already control everything …
They were asking about a change that had already happened. The same list works before one, and it costs less than anything else on this page: go down the list, try to sign into each thing, and mark the ones where you cannot. Which accounts belong in your name, and how to check each one, is a list rather than a conversation, and it is worth having before you ask anything else.
Those three together turn the sixth request from an accusation into a reconciliation. You are not asking whether the builder is holding your accounts hostage. You are reading them your own list and asking them to fill in the gaps.
What changes if you still owe them money
An unpaid balance or an unreleased final milestone is leverage and a deadline in the same object. Every request on this page costs the builder almost nothing while a job is still open and becomes awkward the moment it closes. Ask before the last payment goes out. The answers are cheap to give while somebody is still inside the work and expensive to reconstruct afterwards, and the money itself is no threat.
Word it as a condition of finishing rather than as a complaint. “Before I pay the last invoice, can you walk me through these eight things” is a normal request in every trade that involves paying somebody for work you cannot inspect yourself. It reads very differently from the same eight questions arriving three weeks after final payment, which is when how do I check an app I paid for usually gets typed into a search box.
Two things this page deliberately does not do. It is not legal advice, and it does not settle whether you were treated fairly, because the eight answers describe an app and not an intention, and the failures they surface turn up in work done carefully by people acting in good faith. And if the person has stopped replying altogether, questions are not the first move: getting the code, the data and the accounts back into your own name is. That is the same position as when the app lands on you with nobody left to ask, except that you paid for it.
Choosing who to hire in the first place asks a different set of questions, because nothing exists yet to be shown. Keep the two conversations separate. The requests here all depend on there being a running app on the other end of them.
When the answers are not enough
Three of the eight requests cannot be settled by any answer, however straight. Whether one signed-in customer can open another customer’s records, whether a real password or key was committed into the project’s history, and whether the version of the framework underneath has a publicly known hole all live below the surface a demonstration reaches. A builder answering honestly about those is telling you what they believe to be true, which is a weaker thing than being shown.
The question people ask out loud at this point is how do I find someone trustworthy to look at it. On Google on 25 August 2026 the top two results for the review version of this query are two community threads rather than articles, both asking exactly that, one in a vibe coding community and one in a group thread on Facebook, both read here from their search snippets only because neither could be opened. The first asks who to trust with the job. The second asks how to get it done at all. Neither asks what to run, and that is the same instinct behind the eight requests.
Who reads an app you did not build covers the practical route, and what a code review is when you cannot read code, and what you get out of one, is longer than a bullet and worth reading before you buy. What happens step by step once somebody does read the code, and what access they need to do it, is set out separately.
Two nearby routes go somewhere else. If the answers pushed you toward replacing the builder rather than checking them, bringing in a different person to run the app from here is a separate purchase, and it has four checks of its own before anyone has really taken it over. If the specific worry is what the app is carrying rather than who built it, whether the app needs an outside look at its security is a narrower question than this page, and buying an outside read of the code is where the sellers and their prices sit.
Be clear about what comes back, because this is where the market oversells.
What comes back from somebody reading the code is a person opening the specific thing they found, on your app, and showing you on screen what it lets somebody do.
That is also the honest limit. A reading tells you what is in the code today. It does not tell you whether the person you paid was good value, whether the price was fair, or whether the next change will be written any better than the last one. Checking an app you are about to buy from a stranger adds two questions this page does not cover, which are whether the revenue is real and whether the thing can be transferred at all.
Common questions about checking an app a developer built for you
What should I ask for before I make the final payment?
Ask for the eight requests above, in one message, framed as the last step of the job rather than as a dispute. The three that matter most before money moves are the demonstration on a live paid account, the account and card list, and the answer to what was left unfinished, because all three are cheap while the job is open and awkward afterwards.
Send them as a list rather than one at a time. A builder answering six of eight and going quiet on two has told you which two to press on.
What does a good reply to “what happens when a customer hits an error” sound like?
A good answer opens something. The builder goes to wherever errors collect, finds the most recent one, and tells you when it happened and which page it came from. That is the whole test, and it works even if the screen they open means nothing to you.
“Nothing records them” is also a good answer, and one of the commonest on the whole list, which is why the table above treats it as ordinary rather than alarming. A vague third answer, where errors are said to be handled but nobody can say by what, is the one worth following up.
How long should a developer take to answer these questions?
Six of the eight are answerable in the sitting you ask them in, because they are things to open rather than things to prepare: the live demonstration, the last recorded error, the public surface, the second account, the account list, and what runs before release. Nobody needs to build anything to answer those.
The other two, what a new person would need and what was left unfinished, are worth writing down properly, so it is reasonable for a builder to take those away. What is not reasonable is silence about which requests need time and why.
Is it fair to ask for a demonstration when the work is already delivered?
Yes, and it is normal in every trade where the buyer cannot inspect the work. A builder who is asked plainly will usually answer plainly, and a request to be shown the thing running is smaller than a request to justify the code.
The framing does the work. Asking to be walked through the app is a request. Asking whether the app was built properly is a verdict with a question mark on it, and it puts a competent person on the defensive for no gain.
What if every answer sounds fine and the app still breaks a week later?
Answers describe the app as it is on the day you ask, and eight of them cannot cover everything that runs. In AxonBuild’s fixed study of 26 AI-built applications audited in June and July 2026, the 26 scores ran between 29 and 81 out of 100, the mean landed at 52.1, the median at 51, and not one application came out green, including apps whose owners were perfectly happy with them.
The usual cause of a break a week later is the part that no conversation reaches, which is the point where somebody has to read the code rather than ask about it. It rarely means the answers were false.
Can I get a second opinion without ending the working relationship?
Yes, and saying so up front is what keeps it civil. Bringing in an outside reader is a normal thing an owner does with an asset they paid for, in the same way a landlord has a survey done without accusing the builder of anything.
Tell the person who built it that you are having it read, and tell them they will see whatever comes back. A builder who objects to that has given you an extra data point. A builder who welcomes it will often clear some of what turns up before anybody bills you for it.
What if I cannot get a straight answer at all?
Stop asking and start collecting. Get the code repository, the hosting account, the database, the domain and the payment processor into your own name first, because ownership decides every option after this and it gets harder to unwind the longer it waits.
A builder who will not demonstrate the running app or name the accounts has already answered the only question that matters about the working relationship. The app itself may still be perfectly fine, and it can be read by somebody else once the accounts are yours.
Was I overcharged?
Nothing on this page answers that, and the eight requests are deliberately about the app rather than the invoice. Price depends on what was built, where the builder is, and what was agreed, and a well-built app can cost more than a badly built one for entirely legitimate reasons.
If the question is really about money rather than quality, what the work is worth is the comparison to make, and it is a separate exercise from grading the eight answers.
Built it with AI. Can’t get the last part right?
That’s the normal state of an AI-built app, and it’s fixable. I trace what the app actually does, explain what needs changing, and build it if you want me to.
Talk about your app → 
Free 20-minute video call with Bilal.