Your AI-Built Website Won't Work Yet. Here's Why, and How We Fix It

If you built your website or app with ChatGPT, Claude, Lovable, Bolt, v0 or Replit, it probably isn't ready for real customers yet, even if every screen looks finished. The screens are real. Much of what should happen behind them isn't: contact forms that thank the visitor and save nothing, admin pages anyone can open, checkouts that never charge a card, and pages search engines and AI assistants can barely read. The builder's preview won't show you any of that, because your customers never see the preview. They see your live site on their phones, and that's where it breaks.

What you've built isn't wasted, though. The screens and flow you've worked out are the clearest brief you could hand a developer. What's missing is the part nobody sees, and that's the part we build. At Upforge, we take sites and apps that AI started, fix what's broken underneath and launch them on your domain. Below are the ten places AI-built sites break, how to check each one without reading code, and what fixing it takes.

TL;DR

• An AI builder's preview runs on the builder's own setup. A live site needs its own database, email, hosting and security, and on AI-built projects that's the part that's missing or still on demo settings.
• The usual failures are forms that deliver nothing, admin pages protected only in the browser, open database rules, payments in test mode, and content that only exists after JavaScript runs.
• In Vercel's late-2024 study of AI crawler traffic, the crawlers behind ChatGPT, Claude and Perplexity didn't run JavaScript. A site drawn in the browser can look empty to the assistants people now ask for recommendations.
• You can run most of these checks yourself in about an hour. There's a one-table version near the end.
• Fixing an AI-built site rarely means throwing it away. We keep the design, words and flow, and rebuild what has to hold weight.

Why does an AI-built website look finished before it works?

AI tools build what you can see, and a preview only proves the screens render. It doesn't prove that anything gets saved, protected, delivered or found. Three things account for most of the gap.

The preview isn't production. Chat assistants like ChatGPT and Claude give you code, not the services that code expects. A chat window has no database or server behind it, so when you download the files and put them online, anything that needed a server has nothing to talk to. App builders like Lovable, Bolt, v0 and Replit go further and connect real services for you, but on starter settings made for trying ideas out, like test-mode payments and a subdomain on the builder's site.

AI writes the path you described. Ask for a contact form and you'll get one that says "Thanks, we'll be in touch!" when you click Submit. Unless you knew to ask, you won't get the handling for a spam bot, a failed email or a visitor who edits a price in their browser. Knowing what to ask for is most of the work, and a demo never tests it.

Nothing fails loudly. A broken form still shows its thank-you message. An open database still loads your dashboard. A page Google can't read still looks perfect on your laptop. Sites go live with these problems and keep them until a customer or an attacker finds them.

This isn't only a beginner's problem. When Veracode tested more than 100 AI models on coding tasks in 2025, 45% of the code samples introduced an OWASP Top 10 security flaw, the best-known list of serious web vulnerabilities. Its 2026 report still had only 56% of samples passing.

1. Do your forms actually deliver anything?

A thank-you message isn't a submission. The most common failure on an AI-built site is a form that looks like it worked while the message went nowhere. Sometimes the form only changes the screen and never sends the data to a server. Sometimes it sends email through a demo account or a free trial that quietly expired. And sometimes the email does go out, from a domain that hasn't set up email authentication. Gmail requires every sender to use SPF or DKIM, so mail from a domain without them can land in spam or never arrive. If nothing saved the submission first, that lead is gone.

How to check it: submit your own form from your phone on cellular data, using a phrase you'll recognize, like "form test 4417". Then find that exact submission somewhere other than your inbox, like the database or dashboard behind the form. Check your spam folder while you're at it. If the only evidence is the thank-you message, you've found the problem.

What fixing it takes: Every submission gets saved before anything else happens. Notifications go out from your own authenticated domain to the inbox that actually works your leads. Spam filtering stops bots without blocking people, and you hear about it if submissions suddenly stop.

2. Is your data stored somewhere real, and is it yours?

Plenty of AI-built apps keep data in places that only hold up in a demo. The most common is the browser's own storage, which makes an app feel like it has a database while every record lives on one device. Clear the browser or open the app on another phone, and the data isn't there. Uploads have their own trap. Serverless hosts like Vercel and Netlify don't keep files an app writes to disk while it runs, so photos and documents saved that way can vanish.

How to check it:

• Create a record on your phone, then open the app on a laptop and look for it.
• Upload a file and open it again the next day.
• Ask which company holds your database and whose account it's in. "The builder" or "I'm not sure" is a finding.
• Ask when the last backup ran, and whether anyone has ever restored one.

What fixing it takes: A real database and file storage replace whatever the demo used. Backups get proven by actually restoring one. And the data model gets shaped around how your business works, down to who can see which records and what happens when a customer asks to be deleted.

3. Can a stranger get into your admin pages?

In many AI-built apps, security only exists on the screen. The Admin link is hidden from regular visitors, or a password gets checked by JavaScript in the browser, but the page and the data behind it still answer anyone who asks for them directly. Any rule enforced only in the browser can be skipped, because the visitor controls the browser.

How to check it:

• Log out, open a private window and go straight to your admin address, such as /admin or /dashboard.
• Log in as an ordinary user and paste the admin address into the address bar.
• If users can view their own records, change the number or ID in the address and see whether someone else's record loads.
• View the page source (Ctrl+U on Windows, Option+Command+U on a Mac) and search for "password".

What fixing it takes: Sign-in moves to the server, with sessions that expire and a password reset that can't be abused. Every request for data gets a permission check, so staff and customers only reach what they're allowed to, no matter which buttons are hidden.

4. Are your database and secret keys exposed?

This is the one that makes the news. An app built on a hosted database like Supabase or Firebase puts a public key in the browser. That's normal, and it's safe only when the database has rules limiting what each visitor can read and change. Supabase's documentation is blunt about it: until row-level security and a policy are in place, anyone holding that key can read and write every row. In 2025, a researcher found this gap exposing user data in 170 of the 1,645 Lovable-built apps he checked. It was filed as CVE-2025-48757, a record Lovable disputes on the grounds that each customer is responsible for protecting their own app's data. Either way, it's your customers' data.

The second version is a secret key sitting in front-end code, like an OpenAI or Stripe secret key. Anyone who opens your page's code can copy it and run up your bill.

How to check it:

• Ask whoever set up the database: "Is row-level security on for every table, and what can a visitor who isn't logged in read?" A vague answer is an answer.
• Open your browser's developer tools, reload the page and search the loaded files for "sk_", "secret" and "api_key". A key beginning with sk_live_ in the browser is an emergency.
• If your builder offers a security scan, run it and read everything it flags.

What fixing it takes: Secret keys move to the server, and any that were exposed get replaced. Every table gets access rules that are tested, not assumed. Rate limits stop one visitor from hammering your forms or running up your AI bill.

5. Does checkout charge real cards and record real orders?

A checkout page isn't a checkout. An AI-built store can go live with payments still in test mode (Stripe now calls it a sandbox), where test cards go through and no real money moves. Other stores take real payments but trust the wrong signal. They mark an order paid when the customer reaches the thank-you page, which misses anyone who closes the tab, or they take the price from the page itself, where a visitor can change it.

How to check it: buy something with your own card for the smallest amount you can, then refund it. Confirm that:

• the charge shows up in your Stripe, Square or PayPal dashboard
• the order is recorded in your app
• the receipt arrives
• the refund goes through

Then ask two questions. How does the app learn a payment succeeded? The answer should involve a webhook, a message sent from the payment processor straight to your server. And where do prices come from? They should come from your server or your payment account, never from the page.

What fixing it takes: Prices come from the server. The processor's webhooks become the record of what was paid, including the duplicate and late ones. Receipts and refunds match what your accountant sees.

6. Are your pages real pages?

Plenty of AI-built sites are single-page apps. The server sends a nearly empty HTML file plus a large JavaScript bundle, and the browser draws every "page" once that bundle loads. That can be fine behind a login. On public pages, which need to load fast and get found, it causes problems you can see:

• Refreshing an inner page, or opening a shared link to one, can return a 404 on hosts that aren't set up for it.
• Every page sends the same title and description in its HTML, so link previews in texts, Slack and social posts show the wrong thing.
• Visitors on slower phones wait on a blank or half-drawn screen while the JavaScript downloads and runs.
• Crawlers that don't run JavaScript see an empty page. More on that in check 8.

How to check it: refresh an inner page, such as your services page, then paste its link into a text message and look at the preview. Then view the page source and search for a sentence you can read on the page. If it isn't there, and you mostly see something like <div id="root"></div> and script tags, your page is being drawn in the browser.

What fixing it takes: Public pages get rendered on the server or generated ahead of time, and browser rendering stays with the logged-in screens where it belongs. We built the same page all three ways and measured the difference in which rendering approach fits your app, including a page the build labeled static that didn't serve its words as HTML.

7. Can Google find, read and rank each page?

Google can run JavaScript, but it queues pages for rendering first, and it still calls server-side rendering or pre-rendering a great idea because not every bot can run JavaScript. Rendering is only the start, though. Plenty of AI-built sites skip the basics that decide whether a page can rank at all. The same title and description appear on every page. The sitemap is missing, or lists pages that don't exist. A noindex tag left over from the preview tells search engines to stay away. The builder's subdomain and your real domain compete as duplicates because no canonical address is set. Nothing on the page tells search engines who you are and where you work in a form they can parse. And instead of a page for each service and each area you serve, everything sits on one long page, so there's nothing specific to rank.

How to check it:

• Search Google for site:yourdomain.com and see which pages show up.
• Open yourdomain.com/sitemap.xml and yourdomain.com/robots.txt.
• View the source of three different pages and compare their title tags.
• Set up Google Search Console if you haven't, and read its Pages report.

What fixing it takes: Every page gets its own title and description, and the sitemap updates itself. Canonical addresses point to your own domain, and structured data states your business details. The page structure follows what customers actually search for. Our website audit checklist covers the full baseline.

8. Can ChatGPT, Claude and Perplexity read your site?

Here's the irony: a site built with AI can be invisible to AI. When someone asks an assistant to recommend a business, it works from pages its crawler can fetch and read. When Vercel analyzed AI crawler traffic in late 2024, none of the major AI crawlers it observed ran JavaScript, including OpenAI's, Anthropic's and Perplexity's. Google's Gemini was the exception, because it uses Googlebot's rendering. None of those three companies documents JavaScript rendering for its crawlers today, so a page drawn in the browser is a bet that they read it anyway. Some builders now hand pre-rendered pages to the crawlers they recognize, while everything else, including link previews, still gets the empty shell.

Two quieter problems block AI visibility on sites that look fine. The first is a crawler rule nobody chose. OAI-SearchBot is the crawler OpenAI uses to surface sites in ChatGPT search, and sites that block it aren't shown in those answers. CDNs like Cloudflare now sort AI bots into search, agent and training traffic, and a setting picked at signup can shut out the assistants you actually want reaching you. The second is facts an assistant can't pin down, like hours or prices that only appear inside an image.

How to check it:

• Repeat the view-source test from check 6. If your words aren't in the HTML, most AI crawlers won't see them either.
• Open yourdomain.com/robots.txt and look for Disallow rules under GPTBot, OAI-SearchBot, ClaudeBot or PerplexityBot. If your site runs through Cloudflare, check its AI crawler settings too.
• Ask ChatGPT, Claude and Perplexity what your business does and where. Wrong or missing answers are a signal, though answers vary from one ask to the next.

What fixing it takes: Your content ships in the HTML, and your crawler rules are chosen on purpose. Structured data states your business facts, and pages answer customers' questions in plain sentences. An llms.txt file is a cheap extra on top, but it's a proposal rather than a standard, and it only helps when the pages it points to are readable.

9. Does it work on a phone, for everyone?

AI builders design for how a page looks, and weight is invisible in a preview. Large JavaScript bundles and full-size images mean a site that feels instant on your laptop can take several seconds to become usable on a mid-range phone. Accessibility gets even less attention. Clickable things that aren't real buttons and form fields without labels shut out anyone using a screen reader or a keyboard, and that's legal exposure on top of lost customers.

How to check it: run PageSpeed Insights on your home page and one inner page, and read the mobile Performance and Accessibility scores. Scores from 90 to 100 are in the green. Then set your mouse aside, try the site with only the Tab and Enter keys, and load it on a phone over cellular data.

What fixing it takes: Images get sized and compressed for phones, and public pages ship far less JavaScript. Buttons, labels and focus states work for keyboards and screen readers. Speed gets measured before launch, not after complaints. Core Web Vitals in Practice shows how to find the JavaScript slowing a page down.

10. Is it deployed properly, and who fixes it when it breaks?

Getting an AI-built site onto a real domain is its own job, and it's where a lot of them stall. The domain, DNS, SSL certificate, hosting, secret keys and email records all have to line up. The pieces end up spread across accounts nobody is tracking: code in a builder workspace, a database in the builder's organization, hosting tied to a subscription. Let a card expire or lose a login, and the site can go down with no clear way back in.

Then there's upkeep. Your app depends on outside code packages that need security updates, and payment processors and email providers change their rules. Without error monitoring, your first alert is a customer complaint. Giving an AI agent direct access to a live app carries its own risk, too. In July 2025, Replit's AI agent deleted the production database behind an app that SaaStr founder Jason Lemkin was building, in the middle of a code freeze. Replit has since separated development and production databases, but that protection only exists where someone built it.

How to check it:

• List every service the site depends on, from the domain and DNS to hosting, the database, email and payments, and note who holds each account. Someone you trust should be able to log in to every one.
• Confirm the code lives in a repository you can get to, and that the code and your data belong to you.
• Ask what happens when something breaks at 9 p.m. on a Friday: who gets alerted, and who fixes it.
• Ask whether changes get tried on a test copy before customers see them.

What fixing it takes: A production deploy on your own domain, with every account accounted for. Backups that run on their own. And a named team responsible for updates and fixes.

The one-hour AI-built website checklist

Rather hand this list to someone? That's our job. Send us your AI-built site and we'll walk you through what it needs.

Should you fix an AI-built site or start over?

The answer is almost never all or nothing. Keep what the AI did well, and rebuild what it had no way of knowing.

Keep the design and the flow. You've already decided what customers see and do, which is the part many projects spend their first weeks working out.

Rebuild the plumbing, meaning everything that touches your data or your money. On public sites, that can also mean moving from pages drawn in the browser to pages rendered on the server, which changes how pages are delivered without changing how they look.

Start the code fresh when data only lives in the browser, when nothing separates what visitors can see from what they can change, or when every fix breaks something else. At that point, carrying the old code forward costs more than rebuilding its foundation, and your screens still carry over as the spec.

A word on asking the AI to fix it. That works for a typo or a color. For anything touching money or personal data, each prompt fixes the symptom in front of it, and you won't see what else changed. Keep backups and a test copy, and keep AI agents away from your live database.

How Upforge fixes and launches AI-built websites and apps

This is the work we do. You bring what AI started, and we make it hold up for real customers on your own domain.

1. You send us what you have. That's the live link, the builder project or code export, and a few sentences about what it needs to do for your business.
2. We test it against every check above. You get a plain-English read on what's real, what's a mockup and what's a risk. If it's in good shape, we'll tell you.
3. We keep what works and rebuild what has to hold weight. Your design, words and flow stay. The data, logins, payments and page rendering get built properly, with SEO and AI visibility handled from the start.
4. We deploy it properly. Your site goes live on your domain with production hosting and SSL, email that's authenticated so your notifications land, and secret keys kept off the browser. You own the code.
5. We stay on if you want us. Maintenance and support keeps it updated and fixed after launch.

We've shipped more than 150 projects since 2017 and hold a 5.0 rating on Google. We build public sites to server-render every word, so search engines and AI crawlers can read them. Discovery, Scope, Build, Launch walks through how a build runs with us.

Talk through your AI-built site with us, or start with a free website audit of the public side. The same audit engine reviews web apps, so mention that yours is an app when you request it.