Building your app with AI: what works, what breaks, and when to call someone
You built a tool with Lovable, Bolt or Cursor, and it runs. The question isn't whether it will break, but where. Here are the places I look first.
In short An app built with AI breaks in five places: access control (number one), keys and passwords, data with no backups or validation, dependence on the platform, drifting costs. Call someone when people outside the team log in, when client or financial data lives in it, or when the team can't work without it anymore. I don't rewrite: I fix what's urgent.
A founder showed me the tool he'd built over a weekend with a coding assistant. A real tool, used by his team every day, for a problem no off-the-shelf software solved. Three years ago that would have cost a developer two months. It's excellent news, and I'm not going to play it down.
The question he asked next is the right one: "Can I trust it?"
What genuinely works
Today's tools are very good at producing a first version that works. Interface, forms, database, connection to a third-party service: all of that comes out clean in a few hours. For an internal tool used by five people, it's often more than enough, and it's a mistake to rebuild it "properly" on principle.
The trap isn't the quality of the code line by line. The trap is what the assistant doesn't tell you because you didn't ask.
The five places where it breaks
Access control. Number one, by a wide margin. Does the app have a real notion of who is allowed to see what? Very often the assistant added a login screen, and behind it any logged-in user can read or modify everything if they know the address. As long as it's your team, nobody notices. The day you open it to a client or a partner, it's a data leak.
Keys and passwords. API keys and database credentials easily end up in the code itself, or in a file pushed to GitHub. If the repository is public, or was for five minutes, consider them compromised.
Data. No backups, no constraints in the database, no validation of what gets written. The app works until the day someone types a date in the wrong format, or deletes a row everything else depended on. The damage is often already done by the time you notice.
Dependence on the tool that generated it. Some platforms host your app on their side and make leaving complicated. That's not a problem as long as you're happy. It becomes one the day the price changes or the service shuts down. Know where your code is, and check you can run it somewhere else.
Drifting costs. One call to an AI model per user action, with no limit and no cache, is a bill that follows usage. Fine for a prototype, less fine once the team really adopts it.
What I do when I'm called in
I don't rewrite. Nine times out of ten the app deserves to live. I read the code with the five points above in mind, note what's urgent, what can wait, and what's perfectly fine as is. Then I fix the urgent, usually in a day or two: access, secrets, an automatic backup. The rest goes on a list you keep.
And I show you how to keep evolving the tool yourself, with rules given to your assistant so it doesn't make the same mistakes again. That's the most valuable part: you leave more independent, not more dependent.
When to call someone
Not right away. If it's an internal tool for three people, with data that isn't sensitive, carry on. Call when one of these becomes true: people outside the team are going to log in, client or financial data lives in it, or the team couldn't work without it anymore. At that point, a day of review costs far less than the first leak or the first data loss.
If you're there, that's exactly what I do when taking an app built with AI to production: a test environment, verified backups, tests on what earns you money, and I won't tell you to rewrite everything.