Fix My AI Built App: What Actually Breaks and Why
You built something real with an AI coding tool. It demoed beautifully. Then a handful of actual users arrived and it started doing things you cannot explain: data showing up in the wrong account, a page that hangs on the second click, an upload that silently disappears, a login that works for you and not for anyone else. Nothing in the build process warned you, because nothing in the build process was looking.
This is not a story about AI coding tools being bad. They are extremely good at producing something that runs. What they do not do reliably is produce something that holds up when a stranger uses it, when two people use it at once, or when someone curious opens the browser console. We audit the thing you have already built at a fixed fee, tell you plainly what is wrong, and quote any repair separately so you can decide with the findings in front of you.
Realistic ROI
Four Reasons AI Built Apps Fail in the Same Places
The failures are remarkably consistent, and they are structural rather than random. Understanding why makes them much less frightening.
The tool only sees what you asked for
An AI coding assistant builds what the prompt described, and prompts describe features rather than threat models. Nobody types "and make sure a signed in customer cannot read another customer’s invoices by changing the number in the URL", so nothing in the generated code enforces it. The interface hides the gap perfectly, because the menu only shows you your own records. The gap is real anyway, and the first person to notice it will not be you.
The demo path is the only path that was tested
When you build interactively you follow the happy path over and over: log in, create the thing, see the thing, feel good. Real users arrive from a bookmarked link, with an expired session, on a phone, with an apostrophe in their surname, pressing back mid form, uploading a forty megabyte photo. Each of those is a branch the code has never executed. Most AI built apps have no error handling on those branches at all, so the screen simply goes white and the user leaves.
Convenience settings become permanent settings
To get you moving, tooling and tutorials often suggest relaxing a database access rule, opening a storage bucket, or letting the front end talk directly to a service with a key that has more power than it needs. Those are reasonable choices for an afternoon of prototyping. They become genuinely dangerous the moment the app is public and holds real names, addresses, orders or health information, and there is no prompt at that moment telling you to put them back.
It works until you ask it to change
The eighty percent wall is usually not a security problem, it is a structure problem. Generated code tends to repeat itself instead of sharing logic, so the same rule is written in six places with three slightly different behaviours. Change one and two of the others quietly disagree with it. That is why the last twenty percent takes longer than the first eighty and why each new feature seems to break something older. The fix is refactoring, not more prompting.
The Six Things That Break Most Often
In roughly the order they show up when we look at an application that was generated rather than engineered.
Database access rules
Modern hosted databases let each row carry a rule about who may read or write it. Where the app was generated on a hosted database such as Supabase, that protection is frequently never enabled in the first place, because a new table is unprotected until someone switches it on. Sometimes it does get turned off so the app "just works" and is then never restored. The practical consequence is that the security of your entire customer table depends on the front end deciding to only ask for the right rows. Anyone who opens the network tab, copies the request and changes one value gets the rest. This is the single most common serious finding.
Secrets in the browser
An API key for a payment provider, an email service, a mapping service or a model provider ends up in the JavaScript bundle because that was the quickest way to make a call work. Everything in that bundle is public by definition, and credentials committed to public repositories are found by automated scanners within minutes. Treat a key that has ever reached a browser or a repository as already known. The consequences range from a surprising bill to someone sending email that appears to come from you. The fix is moving the call behind a server route and rotating the key, which is usually a day, not a rebuild.
Authorisation on the server
Hiding the admin menu from ordinary users is presentation, not protection. The question is whether the endpoint behind that menu asks who is calling and whether they are allowed. Generated code very often authenticates, meaning it knows who you are, without authorising, meaning it never checks what you may do. The test is simple: take a request that only an admin should be able to make and issue it as a normal signed in user.
Input handling
Fields accept anything and pass it straight into a query, a file path, an email body or a page. Sometimes that is a security issue. Very often it is just a reliability issue: a quotation mark in a company name breaks a search, a very large upload takes down a function, a pasted block of text with unusual characters corrupts a record. Validating on the server rather than only in the form is unglamorous and removes a surprising share of the mysterious bugs.
Error handling
When a call fails, a well built app tells the user something honest and tells you something useful. A generated app usually does neither. The user sees a blank page or a spinner forever, and you find out only when they email. Worse, some failures are silent successes: the form clears, the user believes it saved, and nothing was written. Adding real failure states and a place where errors are recorded is often the change that most improves how the product feels.
Data exposure through the interface
A screen shows a customer’s name and suburb, but the request that fed it returned the whole record including phone, email, notes and internal flags, and it is all sitting in the browser. Similarly, list endpoints often return every record and let the front end filter. Nobody sees it in normal use and it is fully visible to anyone who looks. Trimming what the server returns is straightforward and materially reduces what a curious visitor can collect.
Symptom, Likely Cause, and What the Fix Usually Involves
| Task | Traditional | After remediation | Notes |
|---|---|---|---|
| A user can see someone else’s data | Assumed to be a display bug | Row level rules and server side ownership checks | Almost never a display bug. Treat it as urgent and check whether it has already happened in your logs. |
| Works for you, fails for new signups | Blamed on the browser | Missing default records or a role never assigned | Your own account was created by hand during development and has state that the signup flow never creates. |
| Blank white screen on some clicks | Refresh and hope | Error boundaries and honest failure states | The underlying call is failing. Without an error path the interface has nothing to render. |
| Unexpected bill from a service provider | Assumed to be usage growth | Key moved server side, rotated, and rate limited | Check whether the key is in your public bundle before assuming the traffic was yours. |
| Saves that do not save | Chalked up to user error | Response checking and confirmed writes | The request was rejected and nothing was watching the response. Very common with file uploads. |
| Every new feature breaks an old one | More prompting | Consolidating duplicated logic first | This is the eighty percent wall. Prompting harder makes the duplication worse, not better. |
| Slows to a crawl as data grows | Blamed on hosting | Query shape, indexes and pagination | Usually a query fetching every row and filtering in the browser. Fast at fifty records, unusable at fifty thousand. |
| Cannot tell what happened when it broke | Guesswork from user descriptions | Basic logging and error reporting | The cheapest single improvement to any app that already has users. Do it before the next incident, not after. |
What to Do, and Not Do, Before Anyone Touches the Code
Do not let a first audit turn into a rebuild pitch
A rebuild is sometimes the right answer, but it should be a conclusion, not an opening position. Ask anybody quoting you to separate the findings from the recommendation, and to say clearly which findings are cheap to fix in the existing codebase. Plenty of AI built apps have serious faults and a perfectly workable structure underneath. Paying to start again when four days of remediation would have done it is the most expensive mistake in this category.
Take a backup and know how to restore it
Before any remediation begins there must be a copy of the database that you have actually restored somewhere else at least once. An untested backup is a belief, not a backup. This matters more than usual with AI built apps because the deployment path is often a single hosted environment with no separate staging copy, so a bad change goes straight to the people using it. If there is no way to roll back, that is the first thing to build.
If you suspect data has already been exposed, stop and get advice
Australian privacy obligations can require you to assess and, in serious cases, notify affected individuals and the regulator when personal information is accessed without authorisation. That assessment has timeframes attached. If your audit finds an open database rule on a table holding personal information, the right next move is a conversation about whether anything was actually accessed, using logs, before you quietly patch it and move on. Patching first and asking later removes the evidence you would need.
Rotate every credential the tool ever saw
Keys pasted into prompts, committed to a repository, left in a hosting environment variable from an abandoned experiment, or shipped in a public bundle should all be treated as compromised regardless of whether you have evidence. Rotation is cheap and takes an afternoon. Include payment providers, email senders, storage, model providers and anything with a webhook signing secret. Then decide which of those calls belongs on the server rather than the browser.
Do not add features while the foundation is being fixed
It is very tempting to bundle "and while you are in there, add the reporting screen". It reliably doubles the time and makes it impossible to tell whether a new problem came from the repair or the feature. Fix, verify, deploy, watch for a week, then build. If a feature is genuinely urgent for a customer commitment, say so up front so it can be sequenced deliberately rather than smuggled in.
Understand that an audit is a snapshot, not a certificate
Nobody honest will tell you your application is secure after a review. What a review tells you is what was found on a given day, by a given method, in the code and configuration as they stood. Tomorrow you deploy a change, a dependency updates, or a service you rely on alters a default. The value is in knowing your real position and having a prioritised list, not in a badge you can put in a pitch deck.
How Yes AI Handles an AI Built App Rescue
Fixed fee audit first, always separate from the fix
You pay a known amount for the review and you get the findings regardless of what you do next, including taking them to another developer. The repair is quoted afterwards against a specific list. We will not give you a single number covering both, because that arrangement quietly rewards whoever is doing the finding.
Findings ranked by real consequence, in English
Every finding says what it is, how someone would actually reach it, what the worst realistic outcome is, and roughly what it takes to fix. No severity scores without explanation and no screenshots of a scanner. You should be able to read it yourself and brief a developer from it without us in the room.
We tell you when the honest answer is a rebuild
Sometimes the structure genuinely cannot carry what you want next and patching it is money down a hole. When that is true we say so, explain which parts are worth keeping, and are perfectly happy for you to take that conclusion elsewhere. It is a worse outcome for us commercially and a better one for you.
Straight talk about what you are actually asking for
A good share of the people who ask us to fix an AI built app really want us to finish building it. That is a legitimate and often sensible request, and it is a much larger engagement than an audit and a patch. We would rather establish that in the first conversation than discover it three invoices in.
From First Call to a Prioritised List You Can Act On
Five steps. The audit stops at the list on purpose, so the decision about repair is yours and it is informed.
A short call about what is actually happening
What was it built with, what breaks, who is using it, what data is in it, and what commercial pressure you are under. This is where we work out whether you need an audit, a repair, or somebody to finish the build, because those are three different engagements.
Read only access and a fixed fee agreed
We take read access to the code and the hosting or database console, agree the fee in writing before starting, and confirm what is in scope. If the honest answer is that a two hour conversation would serve you better than a full audit, we will say that too.
The review itself
Authentication and authorisation, database access rules, secrets and key exposure, input handling and validation, error handling and logging, and what the interface actually sends to the browser. Manual review of the paths that matter, not just an automated scan pasted into a template.
Findings delivered and walked through
A written report with each finding ranked by consequence, a plain description of how it is reached, and an indicative effort to fix. We walk you through it live so you can ask the awkward questions. The repair is quoted here, as a separate document, against a specific list.
Remediation, verified, if you want it
Each fix implemented against the finding it addresses, retested by reproducing the original problem, deployed with a rollback path, and logging turned on so the next issue is visible rather than mysterious. You can also take the list to your own developer with our blessing.
Related Reading
Vibe Code Audit
The productised review: what is checked, what the report contains, and the fixed fee.
Is My Lovable App Secure?
A twenty minute self check you can run before paying anybody.
Bug Fix Blitz
Short, sharp engagements to clear a backlog of defects.
Website Security Audit
The equivalent review for a public website rather than an application.
Claude Code Consulting
Using AI coding tools properly, with review and structure around them.
AI for Startups
Where AI genuinely helps a small team ship, and where it quietly costs you.
FAQ
Find Out What You Are Actually Holding
Book a call. We will tell you within twenty minutes whether you need a full audit, a couple of targeted fixes, or somebody to finish the build. The audit is a fixed fee, the findings are yours either way, and the repair is quoted separately.
All discussions held in confidence. Australian-based consultants.