Somebody posted this to r/smallbusiness on 8 August 2026. AxonBuild captured it on 14 August as part of its own record of what owners of AI-built apps actually ask (reddit.com/r/smallbusiness/comments/1vj21cd/, quoted from that capture, not read live for this page):
“A few months back I paid someone to build an app for my business using AI tools. It works, and it looks fine. But I’ve got this nagging feeling I can’t shake: I have no real way to know if it was actually built properly underneath. I can’t read the code. I don’t know if my data is safe, or if there’s something that could cost me later. I basically just had to trust that it works.”
An app built with AI by somebody you paid usually fails where the popular guides do not send you. Across the 21 apps in AxonBuild’s fixed June to July 2026 study that somebody else built, 6 shipped a real secret and at least 18 had no working test anywhere. Check what actually runs.
Everything below about what the ranked guides say comes from reading four of them on 16 August 2026. Every number comes from AxonBuild’s fixed study of 26 AI-built applications audited in June and July 2026. Nothing here was run hands-on against a tool, and nobody’s app was examined for this page.
This page covers the one thing that changes because a machine wrote most of the code. It deliberately stops short of the browser procedure, the visible tells, and the list of accounts that should be in your name. Those are separate jobs, and they get pointed at where they come up.
Does it matter that your developer used AI?
AI in your contractor’s toolchain changes where the weak spots sit. It says nothing about whether you were cheated, because the same failure shape turns up whoever drove the tool. AxonBuild ran the same audit on the founder’s own five production apps, and all five came out red, scoring 36 to 63 out of 100.
That last part matters more than it looks. The person who built the audit method could not pass it either. Nothing about the pattern requires a careless contractor, a cheap rate, or a rushed timeline. Generators produce feature code, because feature code is what the prompt asks for, and the parts that prove the feature keeps working are not features. What 26 audited AI-built apps actually contained has the full breakdown, including the founder’s five.
A whole slice of the fractional-CTO market now sells to exactly the feeling in that Reddit post: the owner who hired people, got working software back, and has no way to judge it. The feeling is common enough to be a business model. That does not make it a diagnosis, which is what the rest of this page is for.
Was it built with AI at all?
Signs that an app was built with AI do exist: the shape of the interface, the way the repository is laid out, how the error messages read. They are the wrong place to start, because they tell you who typed the code and not whether anything checks it.
Justin McKelvey, a fractional CTO who sells rescues for AI-built codebases, writes on his own site that “‘my app was built with AI’ isn’t embarrassing; ‘nobody has read the code my app runs on’ is.” He is named here and not linked, because he sells the same kind of work AxonBuild does. The visible signs, and the signs in the code itself, are two separate questions with their own answers, and neither one changes what you should check next. Take the AI question as settled in either direction and keep reading.
What the popular guides tell you to check first, and what 26 audited apps actually contained
Four guides rank for versions of this question. Two of them are written for the person who built the app themselves, one is about spotting AI-built apps in the wild, and the fourth opens on the person whose freelancer delivered something and then answers a developer’s question. Set what each one tells you to check against how often that failure actually turned up in the audits.
| The check | Where it appears | How often that failure showed up in the audits |
|---|---|---|
| Search the code and the browser bundle for exposed keys | Top of McKelvey’s fix order, and fifth of six checks in the r/SaaS thread | 6 of 21, the least common failure in the study |
| Create two accounts and see whether they can see each other’s data | The r/SaaS thread | 7 of 21 confirmed a signed-in user reaching another customer’s data |
| Look for tests that assert nothing | Fifth of McKelvey’s nine tells | At least 18 of 21 had no working test at all, so there is usually nothing to inspect |
| Read the interface: emoji, glowing buttons, maximum border radius, purple and cyan | Marcia Cripps on Medium | Not measured. These identify who typed the code, and stop there |
| Break your own payments with a card that declines, and check something is listening | The r/SaaS thread | 10 of 21 accepted whatever the browser asserted |
| Hand a URL and a one-line description to an AI testing tool and let it explore | The dev.to post, which promotes one macOS testing product | Not measured. Surface behaviour only |
| Ask what happens when something breaks | The r/SaaS thread | 17 of 21 recorded errors nowhere |
| Whether a stranger can run up the app’s AI bill | None of the four | 12 of the 14 apps with an AI surface |
| Whether anything runs before a change reaches customers | None of the four | At least 17 of 21 had no deploy gate |
Sources read on 16 August 2026: the r/SaaS thread Built your app with AI. Here’s what to check before you show it to real users, posted 8 March 2026; justinmckelvey.com/blog/how-to-tell-if-code-was-written-by-ai; medium.com/@marciacripps/how-to-spot-an-app-built-by-ai-and-why-i-still-love-vibe-coded-apps-02e78d41373f; dev.to/brianmello/how-to-test-your-ai-built-app-without-writing-a-single-test-b64. The last three are named and not linked: two sell work that competes with AxonBuild’s, and the third is a product promotion.
Across the 21 apps in a fixed June to July 2026 study of 26 AI-built applications, 6 shipped a real secret and at least 18 had no working test anywhere.
One cohort and one denominator, giving opposite answers. Keys are the thing these apps mostly get right, and the audits are blunt about why: of the twelve areas scored, secrets handling came out on top at an average of 84 out of 100, because generators do put keys in environment variables most of the time. When they fail there it is serious, and git history never forgets, which is why 6 of 21 is worth knowing. It remains the least common of the failures on this page.
As of 16 August 2026, none of the four guides tells the owner to check whether a stranger can run up the app’s AI bill, and none tells them to check whether anything runs before a change reaches customers. McKelvey comes nearest on the second one: he tells builders to get the app deploying reproducibly instead of from somebody’s laptop, which is advice for the person doing the work rather than a check the owner can run. All of this is a statement about those four pages on that date, and it dies the day one of them adds a line.
What to check on an AI built app you did not build, in order of how often it goes wrong
Ranked by the share of its own cohort, which is not the same denominator in every row: “of 21” means the third-party apps in the study, “of 26” includes the founder’s five, and “of the 14” means only the apps with an AI feature in them.
| What can be wrong | How often, out of how many | What it looks like from the outside |
|---|---|---|
| No working test anywhere | At least 18 of 21, and at least 23 of 26 | Nobody can tell you whether a change broke something else. Fixes come back |
| A stranger can run up the AI bill, the pattern known as denial of wallet | 12 of the 14 apps with an AI surface | A bill that moves with strangers rather than with customers |
| Nothing records the error a customer hit | 17 of 21 | You hear about problems from customers, or not at all. The failure hides behind a success response |
| No deploy gate | At least 17 of 21 | A change goes live the moment somebody makes it, with nothing checking it first |
| No rate limit on the most expensive thing the app does | 13 of 21 | Sign-up floods, repeated emails, a database or email bill nobody can explain |
| The browser decides what the server accepts | 10 of 21 | Prices, roles or limits that hold in normal use and give way to anyone editing the request. Six ways a working checkout still leaks money |
| A publicly known, reachable hole in the framework version | 9 of 26 | Nothing at all, until it is used. The fix was usually a one-line version bump |
| A signed-in customer can reach another customer’s data, which OWASP calls broken object level authorization | 7 of 21 confirmed | Nothing, unless somebody looks. Worst consequences of anything here, quietest surface |
| A real secret shipped | 6 of 21 | Nothing visible. Three of the six were permanently in git history and one was handed to every visitor’s browser |
Two honest limits on that table. The ordering describes what a fixed set of 26 apps contained between June and July 2026, and it says nothing about rates across the market or about what any contractor knew. Most of these are also invisible from the outside, which is the whole difficulty: the handful you can see from a browser are their own short procedure, and running that procedure is a different job from reading this page. Before an app carries real customers, the evidence it has to clear first is a useful place to compare what you have.
Is the app you paid for actually finished?
A finished app, for somebody who paid to have one built, is one where the parts you paid for run in the live product. AxonBuild’s June and July 2026 audits kept finding controls that exist in the code and never execute: a rate limiter no route calls, an error boundary nobody mounted, a written set of safety rules the running server never opens.
Those three are examples. The audits recorded them as recurring findings with no counted denominator behind them, so treat them as a shape to look for rather than a percentage.
The feature you paid for can be present in the code and absent from the running app.
This is the part a person holding an invoice was never given a definition for. “It’s in there” is a true answer to a different question than “does it work”. A generator will happily write the safety feature you asked for, put it in a file, and never wire it into the path that needs it, because writing it satisfied the prompt. The same mechanism explains why passing tests are not proof the app works, and why an AI-built app gets steadily harder to change as it grows: every new part is written against code nobody has read.
If you want one concrete thing to ask for, ask to be shown the feature working in the live app, on a real account, not in the code.
The bill nobody mentioned
If the app has an AI feature in it, somebody is paying per use, and the audits found that path open far more often than not: 12 of the 14 apps with an AI surface had a confirmed way for a stranger or a free account to burn the owner’s paid AI bill, and 13 of 21 had no rate limit on their most expensive endpoint. The three bills that move this way are all metered:
- Model calls, billed per request to whichever AI provider the app uses.
- Emails, texts and file storage, billed per send or per gigabyte.
- The database and hosting plan, which climbs when something hammers it.
Every one of those runs on an account with a card attached, and it is worth knowing whose name is on each of them, because the accounts are where an app quietly stops being yours. Which accounts have to be in your name is its own question with its own answer, and it is longer than a paragraph. The related pattern of a paid feature ending up free to strangers is the same failure viewed from the revenue side.
Who can actually answer this for you
Three real options, ordered by effort rather than by price.
- Ask the person who built it. The AI-specific version is narrow: ask what the app does when a customer hits an error, ask which tests run before a change goes live, and ask to see the feature working on a live account. A useful answer names a thing you can look at. Judging a developer’s answers before you hire them is a separate skill and a separate question.
- Run what you can see yourself. A short procedure works from a browser and an email address, with no code: two accounts that cannot see each other’s data, a card that declines, a page opened while logged out. Most of the table above stays out of reach that way.
- Pay somebody to read it. A code review of an app you did not build is the only route to the invisible rows. Whether an app needs an outside review at all depends on what the app is carrying, and it is worth knowing what a real finding should contain before you buy one, because “we scanned it and found 40 issues” is not a finding.
On price, the top of this market is public. Justin McKelvey publishes full rescues of AI-built codebases at $25,000 to $50,000 fixed. Price checked on justinmckelvey.com on 16 August 2026. That figure buys a whole rescue, which is a much larger job than a second opinion on the app you paid for, and having somebody read the code you paid for is priced very differently by different sellers. Comparing those sellers, and what each one hands back at the end, is the next thing to read.
Common questions about an app somebody built for you with AI
Should I have someone build an app for me with AI?
Hiring somebody who builds with AI is reasonable and normal, and it is how a lot of working software gets built now. Agree up front on what gets shown to you at the end: the feature working on a live account, an answer to what happens when a customer hits an error, and which checks run before a change ships.
Those three requests cost the builder almost nothing at the start of a job and are awkward to add at the end. They also line up with three of the failures the audits found most often. None of them requires you to understand the code.
Is an app built with AI worse than one built by hand?
An AI-built app fails in a more predictable place than a hand-built one. Across the 21 third-party apps in AxonBuild’s June to July 2026 study, the weakest areas were reliability, dependency hygiene and operations, averaging 31 to 37 out of 100. The failures cluster where nobody asked for anything.
My contractor says the code is fine. How would I know?
You cannot verify that claim from the code, and you do not have to. Ask for three demonstrations instead: the feature working on a live account, whatever recorded the last error a customer hit, and whichever check runs before a change reaches customers. Each answer is a thing you can be shown.
If the answer to the second one is that nothing records errors, that is the same answer the audits got from 17 of 21 apps. It is common, it is fixable, and it is not evidence that anyone acted in bad faith.
Can I check the app without the code?
A browser check gets you part of the way. Two accounts that cannot see each other’s data, a card that declines at checkout, a logged-out browser opening a page that should need a login: all of that works with no code at all. The rows above about tests, deploy gates, the AI bill and framework versions stay out of reach.
Do I need to tell my contractor I am checking?
You do not need permission to look at your own app from a browser or to ask what happens when something breaks. Telling them is usually the faster route anyway, because a builder who is asked plainly will normally answer plainly, and the questions above are ones a competent person can answer in an email.
The one thing worth avoiding is framing it as an accusation. The failures on this page are what generators produce by default, and the audits found them in the founder’s own apps too.
What if my contractor will not hand anything over?
A contractor who will not hand anything over has given you an ownership problem, and it is more urgent than any code problem. The accounts and the code repository need to be in your name whoever writes the software next, and a refusal to transfer them tells you something useful on its own.
Which specific accounts to move, and in what order, is a longer answer than fits here: hosting, the code repository, the database, the domain, the AI provider and the payment processor are the usual set.
How much does it cost to have somebody read it?
Published prices vary widely and most sellers do not post one. The public number at the top of this market is Justin McKelvey’s, at $25,000 to $50,000 fixed for a full rescue of an AI-built codebase, checked on 16 August 2026. Reading the code is a much smaller job than rescuing it, and priced accordingly.
What you get back at the end varies far more than the price does, so compare the sellers on that first. A side by side of who sells this, what each one hands over, and what they charge is the next thing to read after this page.
Should I rebuild it?
A rebuild is rarely the right first move. Nothing in the audits suggests that a working app with customers should be thrown away, and the rows above are mostly things that get added to a working app rather than reasons to start over. A rebuild also discards the one thing you have already proven, which is that people use it.
Decide that question after you know what is actually wrong, not before. Cleaning up what exists versus starting again is a real decision with real numbers on both sides, and it deserves its own comparison.
Not sure what your app needs yet?
See how we follow one real problem from the behavior through the code and decide what should happen next.
