I Built My Website With AI Tools. What Do I Fix Before Real Customers Use It?

How to use this

Work through it in order, and stop at each "Done when"

AI builders and tutorials are very good at getting you to a working screen. They are much less reliable at the parts nobody sees: who can read which rows in your database, what happens when a payment webhook arrives twice, or what a visitor sees when your API quota runs out at midnight.

Each check below has the same shape: what to do, what a pass or fail looks like, and a one-line Done when so you can tick it off and move on. They are ordered by how badly each one hurts if skipped. Commands assume you have Git and Node installed; adapt names to your own stack.

Check 1

Are your API keys and secrets out of your code?

This is the most common serious mistake in AI-generated projects. A key pasted into a file ends up in your Git history, and a key used in front-end code ends up in every visitor's browser, where anyone can open the network tab and copy it.

Do this

1. Search the project and its full Git history for key-shaped strings (commands below).
2. Open your live site, press F12, go to Sources, and search all files for sk_, secret and token. Anything you find there is public.
3. For every key you find, decide: is it designed to be public (a publishable or "anon" key) or must it stay on a server?
4. Move every private key into an environment variable on your host, and make sure the code that uses it runs on a server or serverless function.

# current files
git grep -nIiE "sk_live|sk_test|secret|api[_-]?key|token|password"

# was .env ever committed? (any output means yes)
git log --all --oneline -- .env

# is .env ignored going forward? (should print ".env")
git check-ignore .env

If you find a leaked key

Rotate it immediately: generate a new key in the provider's dashboard, update your host's environment variable, then revoke the old one. Deleting the line from your code is not enough, because the old value is still in your Git history and possibly in a cached build. Start with anything that calls a paid API (AI models, SMS, email), since leaked keys get used up quickly.

Pass: no private key appears in the repo, its history, or the browser's Sources tab. Fail: any one does.

Check 2

Can one user read or change another user's data?

If your app stores anything about people, such as orders, messages, profiles or uploads, this is the second thing to test. Many AI-built apps connect the browser straight to a hosted database. That is fine, but only if the database enforces who can see what. In some platforms this is called row-level security or access rules, and if it is off or set to "allow all", the front end is the only thing standing between your users and each other's data.

The two-account test

1. Create two test accounts, A and B, and add some data to each.
2. Log in as A and note the ID in a URL or request, for example /orders/123.
3. Log in as B and try to open that same URL or request, then try to edit and delete it.
4. Log out completely and try the same request with no login at all.
5. If B or the logged-out visitor can see or change A's record, you have an access-control gap. Fix it in the database rules, not only in the interface.

If you use Supabase or another Postgres database

List which tables have row-level security switched on, then add an owner-only policy to each table that holds user data. Replace the table and column names with your own.

-- tables where rowsecurity is false are open to anyone with your public key
select tablename, rowsecurity
from pg_tables
where schemaname = 'public';

alter table orders enable row level security;

create policy "owners read their orders"
  on orders for select
  using (auth.uid() = user_id);

create policy "owners change their orders"
  on orders for update
  using (auth.uid() = user_id)
  with check (auth.uid() = user_id);

Also check file uploads. A storage bucket set to public means anyone with a link can open every file in it, including invoices and ID documents if users upload them. Make private buckets the default and serve files through short-lived signed links.

Pass: account B and the logged-out visitor get an error or an empty result for every one of A's records. Fail: any record loads or changes.

Check 3

What happens when something goes wrong?

Demos only show the happy path. Real users submit empty forms, lose connection halfway through checkout, double-click buttons and paste emoji into number fields. Walk through each critical flow (sign up, log in, pay, contact form) and deliberately break it using the table below.

Fix the three that matter most

• Validate on the server. Never trust the browser. Re-check every field, length and type in the code that receives the request.
• Make payments idempotent. Treat the payment provider's webhook as the source of truth, not the customer landing on a thank-you page. Store each event ID you process and skip any you have already seen. In Stripe, verify the signature on every webhook too.
• Show a human message. Catch errors around every external call (payments, email, AI) and show a clear next step instead of a raw error or blank screen.

Add monitoring so you hear first

1. Set up a free uptime monitor (for example UptimeRobot or Better Stack) on your home page and your most important API route, with email or SMS alerts to you.
2. Add an error tracker such as Sentry to both front end and server. Trigger a deliberate test error and confirm it arrives.
3. Set a spending cap and usage alert on every paid API (AI, SMS, email) so a bug or abuse cannot run up a surprise bill.

This takes under an hour and is the best return on time in the whole guide.

Check 4

Can you recover if you break something or lose your data?

Ask three questions. If your database were deleted today, when was the last backup and have you ever restored one? If your latest change breaks the site, can you roll back in a minute? And do you have somewhere to test changes that is not the live site?

1. Backups: turn on automated database backups and check how long they are kept. Then do one real test restore into a scratch database. A backup you have never restored is a hope, not a backup.
2. Version control: keep your code in Git on a service like GitHub, with commits that describe what changed. Many AI tools edit files in bulk, so a clean history is your undo button. Commit before every large AI-assisted change.
3. Separate environments: run a staging copy with its own database and test payment keys. Never test with real customers' data.
4. Deploys: host somewhere that keeps previous deployments so you can roll back with one click. Practise the rollback once before you need it.

# back up
pg_dump "$DATABASE_URL" --format=custom --file=backup.dump

# restore into a scratch database to prove it works
pg_restore --dbname="$SCRATCH_DATABASE_URL" --clean backup.dump

Pass: you can state your last backup time, you have restored one, and you have rolled back a deploy. Fail: any of those is a guess.

Check 5

Is it fast and usable on a mid-range phone?

You built it on a fast laptop with a good connection. Most visitors will arrive on a phone, often on mobile data. Generated code tends to ship large images, many fonts and heavy JavaScript libraries, because adding them is easy and nobody removes them.

Do this

1. Run Lighthouse on your home page and your most important page in mobile mode, and note the performance and accessibility scores (command below, or DevTools, Lighthouse tab).
2. Open the report's opportunities list and fix only the two or three heaviest items. These are usually images and third-party scripts.
3. Convert large images to WebP or AVIF and set explicit width and height so the layout does not jump.
4. Limit fonts to one or two families and the weights you actually use.
5. Check that buttons are at least 44 pixels tall and text is readable without zooming.
6. Tab through the page with only a keyboard. Every link and form field should be reachable and visibly focused.

npx lighthouse https://your-site.com \
  --only-categories=performance,accessibility \
  --view

Do not chase a perfect score. A realistic target for launch is a performance score in the 70s or better on mobile, an accessibility score above 90, and no layout jumping as the page loads.

Check 6 and 7

Do you actually own and understand what you launched?

This is the check that matters most a year from now. Make a short list of every account and service your site depends on: domain registrar, hosting, database, email sender, payment provider, analytics and the AI builder itself. For each one, confirm that the account is under your email, that billing is under your name or company, and that you could log in tomorrow if the person who set it up disappeared.

If any row feels out of your depth, that is useful information. It is the signal covered in our guide on when to bring in a developer, and it is much cheaper to ask for a review now than to fix an incident later.

Launch-day gate

The go or no-go list

Copy this into your notes and tick it off on launch day. Any unticked item in the first two groups is a no-go.

FAQ

Frequently asked questions