Six troubling things we found when we reviewed a working, AI-coded portal that was about to be put in front of real clients.
A few weeks ago, a founder I respect walked me through a client portal he had built himself. He runs a growing financial advisory practice in Toronto, client onboarding had become painful enough to fix, and he had coded the entire thing with AI tools, without ever bringing in a developer. The portal worked. The forms rendered, the logic branched the way it should, documents uploaded to SharePoint, and the admin view showed the files coming in. It looked like a real app.
He thought so too. But before putting real client data through it, he wanted someone with development experience to take a look. He told me, candidly, that for all he knew, "the thing might blow up as soon as he tried to push ten applications through."
And I'm glad he took this step, here are 6 critical problems we found:
01 Everything sat in one file.
The application's main file was about 8,800 lines of code mixing the look of the app, the logic, and the data handling all together. Because it was one file, the whole thing had to load every time, which makes the app slower than it needs to be. For context, the common practice in production applications is to break that work into several small files, each responsible for one thing, so only what is needed loads at any moment.
Imagine running your whole marketing function out of one Word document. Brand guidelines, campaign briefs, customer emails, vendor contracts, all in the same file. It works, right up until someone needs to change the email signature and has to scroll through ninety pages to find it, or two people edit at once and one of them quietly loses their work. Split it into separate documents, each holding one thing, and every one of those problems goes away.
02 Visual styling was duplicated everywhere.
Instead of defining the visual styles once and reusing them across the app, the same styling instructions were repeated inline across many places in the code. Changing a button color, a font size, or how the mobile layout breaks meant finding every instance and editing each one by hand. Miss one, and the app looks inconsistent.
Picture a room where every bulb has its own switch. To lower the lights you walk around clicking each one down, and you always miss the lamp in the corner, so it stays bright and the room looks uneven. One dimmer does the whole room at once. You turn the dial and every light follows. The styling in this app was a room full of separate switches. It could have been one dimmer.
03 Client data was stored in flat files, not a database.
Quick and easy in early development, but it doesn't hold up. Databases exist for reasons that become urgent quickly: protecting data when two people write to it at the same time, recovering it cleanly if something corrupts, indexing it so the app stays fast as records accumulate, backing it up reliably so a bad day doesn't become a catastrophic one. None of that was in place.
A folder of files is a garage stacked with unlabeled boxes. The part you need is in there somewhere. Finding it means opening box after box until you get lucky, and nobody really knows what is in stock until they look. A database is the hardware store. Every item has an aisle, a bay, and a label, so you walk in, read the signs, and have the exact part in your hand in under a minute. The store also knows what it has, what is running low, and what sold last week. With client data, that gap is not about convenience. It is whether you can find a record, trust it is the only copy, and get it back when something goes wrong.
04 Client data was reachable from the public web.
The folder where those flat files sat was being served by the web server itself, so typing the predictable URL returned the files with no login and no permission check of any kind. Once a real client filled out a questionnaire, their name, SIN, income, and asset disclosures would have been one guessed URL away from anyone who wanted them.
This is the part of the review where I stopped to make sure I understood what I was looking at. A web server is essentially a public hallway. Anything you put in it is visible to anyone who knows where to look, unless you explicitly put a lock on it. There was no lock here. The folder full of client data was sitting in the hallway with a sign that said "client data," waiting for the first person to walk by and notice.
05 The credentials to the firm's SharePoint were reachable too.
The portal needed credentials to talk to SharePoint. Those credentials lived in a file in the application's folder, which is normal. That file was also sitting in the public hallway, which is not.
Anyone who found it could read or write anything in the firm's SharePoint, not just things related to the portal. The keys to the whole document storage, in the same hallway as the client data.
06 The admin password was visible to every visitor.
It was hardcoded into the JavaScript that loads in every visitor's browser, so anyone could right-click, choose view source, and read it directly. The line that should have separated a regular client from an administrator was effectively gone.
Anyone with three minutes of curiosity and a basic browser could act as an administrator.
There were more findings. There always are.
The portal worked. From where the founder stood, everything looked right, and that is the trap. Building something that works is exactly what these tools are good at. The part they do not cover yet is everything that never shows up in the demo. An app with visible cracks gets fixed before it ships, because someone gets nervous and brings in help. An app that looks finished gets shipped, because nothing on the surface tells anyone to stop. The risk was never that these tools build things that don't work. It is that the things most likely to hurt you are the ones you cannot see from where you are standing.