For founders whose AI built app works in the demo and falls over with real users

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.

Book an App Rescue Call (03) 9003 0111

Realistic ROI

8 to 14 findings

Is a typical count on a first audit

That is the range our own engagements return: usually two or three items with real consequence and a longer tail of smaller reliability issues. Yours may return more or fewer

3 recurring faults

Are the faults we look for first

Database row level security never enabled, API keys sitting in client side code, and authorisation checks that exist in the interface but not on the server

Fixed fee audit

Quoted before we start, repair quoted after

We never bundle audit and repair into one number, because a bundled price gives us a reason to find more work

Point in time

Is what any audit can honestly claim

A review tells you what was true on the day it was run. It is not a warranty and nobody should sell it as one

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.

Anyone can read everything

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.

Keys shipped to every visitor

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.

Checks that only exist in the UI

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.

Whatever the user types goes through

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.

White screens and silent failures

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.

More is sent than is shown

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.

FAQ

My app was built in Lovable and now it is broken. Can you fix it?

Usually yes, and the first step is finding out what is actually wrong rather than guessing from symptoms. Applications generated by Lovable, Bolt, Cursor, Replit, v0 and similar tools tend to fail in a predictable set of places, so a structured review finds the real causes quickly. We charge a fixed fee for that review, deliver the findings whether or not you engage us further, and quote the repair separately once there is a specific list to price. If the symptoms are severe and obviously data related, tell us on the first call, because that changes the order we do things in.

Why does it work perfectly for me and break for my users?

Because your account is not like their accounts. During development you created records by hand, granted yourself permissions directly in the database, and never went through the signup flow you shipped. New users hit code paths you have never executed: the first login, the empty state before any data exists, the default settings that were supposed to be created and never were, and the permission that was assigned manually to you and automatically to nobody. It is one of the most reliable patterns in AI built applications, and it is generally quick to fix once identified.

Is my app actually insecure, or am I being sold fear?

A fair question and you should keep asking it. The honest position is that AI coding tools produce working software fast, and the boring protections are the first thing left out when nobody asks for them, most sharply in the tools that stand up the database for you. So certain faults recur very often: database row level security never enabled, API keys shipped in client side code, and permission checks that exist in the interface but not on the server. That does not mean your app definitely has them. It means the base rate is high enough to be worth twenty minutes of your own checking before you pay anyone. There is a self check list on our page about whether a Lovable app is secure, and you are welcome to run it and conclude you are fine.

How much does it cost to fix an AI built app?

The audit is a fixed fee agreed before we start, so there is no open ended exposure at that stage. The repair depends entirely on what is found, which is exactly why we quote it separately rather than bundling. A typical outcome is a small number of serious items that are each a few hours to a day, plus a tail of smaller ones you may reasonably choose to leave. Larger structural work, such as consolidating duplicated logic so the application can accept new features again, sits in our consulting ladder and gets scoped properly rather than estimated on a call.

Should I just rebuild it from scratch instead?

Sometimes, but far less often than people expect and far less often than a developer who did not write it will tell you. A rebuild throws away every decision that was correct along with every decision that was not, and it restarts the clock on your product at the moment you finally have users. The test we apply is whether the data model is roughly right and whether the application can accept a new feature without breaking two old ones. If both are yes, remediation is almost always cheaper. If the data model is genuinely wrong, that is when we say rebuild and mean it.

Can you just finish building it for me?

Often that is what people actually want, and it is worth naming it early. Finishing a partially built product is a different engagement from auditing one: it involves scope, priorities, a delivery plan and usually ongoing work, whereas an audit is a bounded review with a written output. We do both, but we price and run them differently, and trying to do the second under the pricing of the first is how projects go wrong for everyone. Say on the first call if what you really need is somebody to take the build the rest of the way.

Will my app be secure after you have fixed it?

No, and be wary of anyone who says otherwise. What you will have is a set of specific, identified faults that have been fixed and verified, plus visibility you did not have before through logging and error reporting. Security is a state that decays: you will deploy changes, dependencies will update, and services you depend on will change their defaults. An audit is a point in time review, not a warranty. The realistic goal is knowing your actual position, closing the serious gaps, and having a way to notice when something new goes wrong. Call (03) 9003 0111 or book a call if you want a frank conversation about where yours sits.

Find Out What You Are Actually Holding

Book a call. In a 30-minute consultation, we will discuss 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.