I Built This Site on an AI Website Builder First: What Broke, What It Would Have Cost, and How to Check Your Own

This website used to be something else.

I built the first version of hustlelabs.llc on one of the popular AI website builders. I described what I wanted, watched it appear, and had something that looked finished in a couple of evenings. It was impressive and I am not going to pretend otherwise.

Then I started putting weight on it. Payments and security are where it came apart for me, and once I understood why, I rebuilt the whole thing from scratch on infrastructure I control.

That is an awkward thing for a person who sells websites to admit in public. I am telling you anyway, because I would rather you hear the failure modes from somebody who walked into them on his own site than find them yourself with a customer's card number sitting in the middle of it.

So here is what tends to break, written for an owner rather than an engineer, along with how to check whether your site has any of it.

First, the honest part: these tools are good

I use AI every day, including in my own work. For getting an idea onto a screen, the current crop of builders earns the attention it gets. If you need to show a partner what you are picturing, or find out in one evening whether an idea holds together at all, use one. You will be done before you would have finished writing the brief for me.

The trouble is not the code these tools write. The trouble is the decisions they are never asked to make. A site that takes money and holds customer information is maybe eight unglamorous decisions, made correctly, in the right order. Nothing in the conversation you have with an AI builder surfaces those eight decisions, so they get made by default, and the defaults are chosen to make the demo work.

Which is why the thing looks perfect right up until it does not.

The five that keep showing up

1. Anybody could make themselves an administrator

The pattern these tools reach for is a checkbox on each customer's own record that says whether that person is an admin. It reads as obvious. It is also the single most common way these sites get taken over, because the customer can edit their own record, and the checkbox is on it. Anyone who can update their profile can promote themselves.

What it costs you: somebody signs up with a free account, flips one value, and now has every other customer's information, your order history, and your settings.

Done properly, the permission lives somewhere the customer cannot reach at all, and the database checks it on every single request rather than the page politely hiding a button. Hiding a button is decoration. Anyone curious enough to look past the page can find what it hid. (If you want the term to search: role-based access control.)

2. The database was handing out data to anyone who asked

AI tools create the tables and stop there. Nothing is ever written down that says who is allowed to read which rows, so the piece of your site that fetches data will cheerfully hand a stranger every row in the table, other customers included.

The page still looks correct, which is what makes this one nasty. Your site shows each person their own orders because the page asked for their own orders. Nothing stopped it from asking for everybody's.

What it costs you: your customer list is effectively a public download, and you learn about it from a stranger or from a letter.

The fix is rules stored next to the data itself, saying this person may read these rows and no others, written at the same moment the table is created rather than added later when someone remembers. (The term is row-level security.)

3. The form checked itself and nothing else did

When a form tells you that you missed a field, that check is running inside your visitor's browser. It is a courtesy to the customer. It is not a lock, because anyone can talk to your website without using your form at all, and skip the check entirely.

So the same rules have to run a second time on your own server, where a visitor cannot reach in and change them, and a third time at the database, because the server is not the only thing that will ever write to it. Same rule, three places.

What it costs you: junk orders, quantities of negative four, a price field set to zero, and an afternoon spent cleaning up records by hand.

4. The payment key was sitting in the page

Two habits cause most of this. The first is putting a key or password into the part of the site that gets sent to the visitor, where anybody can read it, usually with a note to move it later. The second is accepting messages from your payment company without checking that they came from your payment company.

There is a third that nobody sees coming. Payment systems retry when they do not hear back fast enough. If your site treats the retry as a second order, a customer gets charged twice, and you find out when they are angry. Handling that correctly takes one decision at build time and a lot of apologizing later if you skip it. (The term is idempotency, and it is worth knowing the word purely so you can ask whether it was handled.)

What it costs you: double charges you refund by hand, or somebody else running up a bill on a key they read off your page.

5. Nobody found out things were broken except your customers

Most AI-built sites have no logs you can search, no alerts, and no health checks. The first sign that anything is wrong is a confused message from a customer, usually forwarded twice and screenshotted badly.

A contact form that stops delivering is the expensive version of this, because nothing on the page changes. It still says thank you. Every inquiry in that window never reached anybody, and afterwards there is no list of people to call back.

What it costs you: the leads you paid for and never saw.

Built properly, errors get caught and written somewhere a person can read tomorrow, a friendly message to the customer instead of a blank screen, and something watching the site around the clock so I find out before you do.

How to check your own site in about ten minutes

You do not need to understand any of the above to ask about it. Send whoever built it these five questions and read the answers.

Where does my site store who is an admin, and can a signed-in customer edit that field? If the answer involves a value on the customer's own record, that is the first problem.

If somebody talks to my database directly instead of through my website, what stops them reading other customers' rows? A confident, specific answer is what you want. Vagueness here is the answer.

Are my form rules enforced on the server as well as in the browser?

Where are my payment keys stored, and what happens if the payment company sends the same message twice?

If the contact form broke tonight, how would I find out?

A builder who knows what they are doing will answer all five in a couple of minutes. If the answers are fuzzy, you have found your next project, and it is cheaper to deal with now than after somebody else finds it.

The order I build in, and why it is the reverse

Most AI-first workflows start with the screens, because screens are the part you can see. I go the other way.

I model the data first, since the shape of your information is the contract every other part of the system depends on. Access rules go in at the same moment the tables do, so nothing is ever briefly unprotected. Then the server-side logic for anything that touches money or customer information, because the page in the browser should never be trusted with those. Then tests for the paths where a mistake is expensive. The screens come last.

That order is faster, not slower, because each step rests on the one below it. The AI-first order only feels quicker until you start pulling things back out.

Twenty-five years across operations, sales, marketing, web and software is mostly what I am charging for here. Not the typing. Knowing which of these decisions costs somebody real money later.

When the AI builder is the right call

I am not trying to talk anybody out of these tools. Three cases where I would use one without hesitating.

A throwaway prototype meant to test an idea on five friendly people. An internal tool used only by people you already trust, sitting behind a login somebody else built properly. A personal script that automates something only you will ever run.

If your project is one of those, go build it and stop reading. The mistake is carrying that same posture into the thing that takes payments, stores customer information, or has your name on it.

Questions I get asked

Do I have to throw away what I already built?

Almost never. The first step is a short audit of the six or seven areas above, and then an honest answer about whether hardening what exists is faster than rebuilding one slice of it. Sometimes it is. I will tell you which, and why, before you spend anything.

How long does a proper build take?

For a small business, a focused first release is usually a few weeks rather than months. I give you a written timeline before any work starts and I hit it. If you want the whole thing written out step by step, including everything I set up around the site, I published that separately.

Do I need to understand any of this?

No. Most of my clients are not technical and do not need to be. My job is to translate the decisions into plain English so you can make informed calls about your own business. You should not need a computer science degree to know what your own software is doing.

What happens after launch?

You own the accounts, the domain, the data and the code from day one. I can show you how to run it and leave, stay on month to month, or hand off cleanly to whoever comes next. That is a line item in every quote I send rather than a surprise afterwards.

The part that matters

AI is a power tool. Power tools build good things in trained hands and send untrained ones to the emergency room. The skill worth anything right now is knowing which code is safe to put in front of a paying customer. Getting an AI to write the code is something any of us can do this afternoon.

If you built something with one of these tools and it has started feeling fragile, or you have an idea that needs a foundation under it, tell me what you are working with. I will tell you what it would take, with a straight answer and a real timeline.