When an AI-built website is still a beta
There's a state every AI-built website passes through where it looks finished from inside the project but isn't actually safe to publish. From the operator's seat, it feels close. The pages exist, the copy reads well, the navigation works in the preview pane, and the AI's status messages all say "complete." From a real visitor's seat, looking at it cold on whatever browser and device they happen to use, the site is still a beta. Forms might or might not submit. Mobile layout might or might not hold. Performance might or might not be acceptable. Edge cases might or might not be handled.
The gap between those two states is invisible from inside the build. You can't tell whether your site is a finished draft or a still-a-beta until something gets stress-tested. Recognizing the signals is the easier path. If you can name what's still beta about the site, you can either harden the specific parts that need hardening or hold off on launch until that work is done. Shipping a beta as production is the expensive failure.
I'll walk through the five signals that show up most often. If any of them are true about your site right now, the site is still a beta, and pretending it isn't is the trap.
Signal one: the entire site has only ever been tested in one browser
If you built the site and the AI tested it, "tested" usually means "rendered in the AI's environment, which is one browser, one viewport size, no privacy shields, no ad blockers, full-speed connection." That's a thin slice of how real visitors will arrive.
Real visitors arrive across at least five environments that matter: a current Chromium browser without extensions, a current Chromium browser with shields up (Brave, uBlock Origin), Safari on a current iPhone, Chrome on a current Android, and at least one slow connection profile (older device, throttled cellular). If the site has only ever rendered in the AI's preview pane, you don't know which of these environments it works in.
This is one of the easiest signals to test for and one of the most consistently skipped. Open the site in each environment. Walk the user path. Note what fails. Each failure is beta debt that hasn't been paid yet.
I documented one version of this in the /log mesh polish leg of this site. The mesh visualization rendered perfectly in the build environment. Real testing surfaced a hydration flash that lasted long enough to feel broken, and node identification that worked in the build but was missing on hover. Both were beta state that the build environment couldn't show. The fix was a small leg, but the work had to happen before launch could.
Signal two: forms submit but you've never received a real submission
The form has a submit button. You clicked it once. Something happened that looked successful. You moved on. Then real visitors start trying to submit, and the submissions never arrive, or arrive without the data filled in correctly, or arrive but get filtered as spam, or arrive but the notification email goes to a deprecated inbox.
A working form is one where the entire round trip has been verified. A real submission with realistic data. The submission landing in the destination. The notification reaching the operator. The data structured the way it'll be needed downstream. If any of that chain hasn't been verified end to end, the form is still a beta, even if it looks done.
The discipline here is the three-leg gate: structure (form renders, submit button exists), function (a real submission actually round-trips), and performance (the submission completes quickly enough that a visitor doesn't bounce). All three need to pass before a form is genuinely shipped.
Signal three: nobody's actually loaded the site on a phone
The desktop preview pane has a mobile emulator. The mobile emulator is close to real mobile, but it's not real mobile. Real mobile has different touch interactions, real network conditions, the actual viewport rendering of the real device's browser version, and real interaction patterns (vertical thumb-reach, scroll behavior, keyboard appearance pushing the layout, focus-trap behavior on input).
If nobody has actually held a phone, navigated to the site, and tried to do the visitor task, the mobile experience is still a beta. The number of failures that only show up on real mobile is genuinely surprising the first time you do this check. Modals that can't be dismissed. Sticky elements covering the form. Input fields that don't trigger the right keyboard. Layouts that overflow horizontally on iPhone but not Android.
The fix is sometimes mechanical (a CSS adjustment) and sometimes architectural (a redesign for thumb-first interaction). You can't know which one until you've actually walked the path on the device.
Signal four: nobody has tried to do the actual visitor task in one sitting
The way an AI builds is iteratively. Build the hero. Test the hero. Build the nav. Test the nav. Build the form. Test the form. Each piece gets tested in isolation. That's good development. It's not equivalent to testing the whole visitor experience.
A real visitor doesn't arrive piece by piece. They land. They read the hero. They scan the layout. They navigate. They engage with whatever the conversion surface is. They make a decision. That entire arc, from cold arrival to whatever counts as a conversion, is a different test from any single piece passing.
If nobody has sat down, navigated to the site as if they'd never seen it, read everything in order, and tried to complete the visitor task as a stranger would, the visitor flow is still a beta. The pieces might all work in isolation while the whole experience is still broken.
The test is uncomfortable. You have to pretend you don't know what's on each page. You have to read every sentence the way someone seeing it for the first time would. You'll find things you'd stopped seeing.
Signal five: there's no way to know if the site is broken in production
The site is live. A visitor hits an error. Nothing tells you that happened. You find out hours or days later when someone mentions it, or when traffic patterns shift, or when you happen to check yourself and see something broken.
Production-ready means you have a way to know when things break. That can be as simple as a status check that pings the site once a minute, as substantial as full application monitoring with error tracking, or as direct as a uptime monitor that alerts on failure. The minimum threshold is: if the site goes down or starts erroring at 3 AM, you find out before your visitors do.
If you have no monitoring at all, the site is operationally still a beta. Production-grade includes knowing when production breaks.
The cost of shipping a beta as production
The reason this matters is reputation. Visitors don't know the site is a beta. They land, find the dead-ends, and form an impression. If the form silently swallows their submission, they don't write you to complain. They write you off. The lost visitor is permanent, and you don't even know it happened, because the signal that should have surfaced the failure (the form submission) never reached you.
A site that's still a beta when it ships costs you the early visitors you most needed to convert. The fix is either to harden the site before launch or to label it explicitly as a beta and manage expectations. Pretending the beta is production is the path that loses you the most ground.
What the hardening pass actually does
A hardening pass takes the existing site and runs it through the five signals above as a checklist. Each environment gets tested. Forms get round-tripped. Real mobile gets walked. The full visitor task gets attempted from a cold-start perspective. Monitoring gets added. The output is one of two things: a list of specific issues to fix before launch, or confirmation that the site has crossed from beta into production-grade.
Either output is useful. The list of issues is a scoped repair job. The confirmation is permission to launch confidently.
If your AI-built site is at the "draft feels close" stage, the hardening pass is the work that gets you from beta to production. It's a known scope, it has a definite end state, and it costs less than launching a beta and dealing with the visitor fallout.
Got an AI-built site that feels close but you're not sure it's ready? Send the site URL, what's been tested, and your launch timeline. VibeKoded can scope the build, ship the prototype, or hand off the production site. → Work with VibeKoded