How to Check Whether Your Vibe-Coded Website Is Ready to Launch

You built the thing. It loads, the buttons mostly work, and you have stared at it long enough that every page is burned into your head. The AI has finally stopped finding something new to rewrite every time you ask it to take another look, so now you are staring at what feels like a finished website and asking the obvious question: is it actually done?

That is where vibe coding gets tricky. AI is very good at helping you get from an idea to something real, and I use it too. The problem is that getting something to look finished and proving that it is ready for real people are two different jobs.

The things that hurt you after launch are usually not the giant, obvious problems you spent three nights fighting. They are the contact form that says it submitted but never sends anything, the page that works perfectly until somebody reloads it directly, the API key that ended up somewhere a browser can download it, or the checkout that works when everything goes right and falls apart the first time a card declines.

None of that means vibe coding is bad. It just means building something and checking what you built are different jobs. Before you launch, stop building for a little while and try to break what you made.

First, stop using the site like its creator

One of the easiest ways to find problems is to stop using the site like the person who built it. You know your site too well. You know which button comes next, what every field expects, and which page you are supposed to visit before another page works. Even when you are trying to test honestly, you are still following the path you built.

A customer does not know any of that. Open the site in a private browser window, or better yet, use a browser you normally do not use. Start at the home page like you have never seen the site before and try to accomplish whatever the site is actually supposed to help somebody do. Send the message. Book the appointment. Find the price. Create the account. Buy the product.

Then do it badly. Leave something blank, put the wrong kind of information into a field, back out halfway through, hit submit twice, refresh a page in the middle of something, or open a page directly instead of navigating to it through the menu. After that, grab your phone and do it again.

Do not start fixing things the second you find them. Write them down first. You are trying to learn what is actually wrong, not disappear into another six-hour coding session because one button moved three pixels.

Use a real phone

Responsive mode in your browser is useful, but it is not a phone. A real phone gives you touch controls, a mobile keyboard, slower connections, browser quirks, scrolling behavior, and all the other little things that do not quite show up when you drag the edge of Chrome smaller.

Use the site the way you actually would. Can you read it without zooming? Can you tap the buttons without hitting something next to them? Does the menu behave? Does anything cover the form when the keyboard opens? Is something fixed to the bottom of the screen sitting on top of the button you need? Make sure you cannot scroll sideways just to read normal text.

Then go the other direction and look at the site on a large screen if you can. A layout that looks great on the laptop you built it on can get strange when it suddenly has a lot more room. You are not chasing pixel perfection here. You are looking for anything that makes the site harder to use.

Click the stuff nobody remembers to click

Go through the whole site and use every link, not just the big call-to-action buttons. Click the logo, every navigation item, everything in the footer, and links inside privacy policies and terms pages. Follow anything that leaves your website and make sure it still goes somewhere you are comfortable sending a customer.

Generated projects are especially good at producing links that look right while pointing at the wrong thing. The route might be /contact-us while the button goes to /contact. The AI may have changed a page name in one file and never updated the footer. A feature may have been removed while its old link stayed behind.

Now type a page into the address bar that absolutely does not exist, something like:

yoursite.com/i-made-this-page-up

You should get a real page-not-found response that still feels like your website and gives the visitor somewhere to go. You should not get a white screen, a hosting company's generic error page, a server stack trace, or your home page pretending nothing happened.

There is another one worth checking if your site behaves like an app. Navigate to an inside page normally, then refresh the browser. If the page works when you click to it but breaks when you reload it directly, you have a routing or hosting problem. That can affect customers, search engines, and anybody following a link directly to that page.

We actually caught that exact class of problem on House of Crimson. The application built correctly, the local tests passed, and the hosting platform simply was not running part of what had been built. The code saying something exists does not mean the internet is actually serving it.

Actually send every form

Never trust a success message by itself. If your website has a contact form, fill it out and send yourself something, then check your inbox.

That sounds painfully obvious, but forms are one of the easiest things to fake accidentally. The front end can show “Thank you!” whether the message ever reached another system or not. Make sure the submission arrives where you expect, check spam, and hit reply to confirm you are replying to the person who sent the form instead of replying back to your own website.

Then submit the form incorrectly. Leave a required field empty, use a bad email address, or send it while your connection is poor. Find out what a customer sees when something goes wrong. A form that fails should say it failed, and a form that succeeds should actually succeed.

If you are using a third-party form service, check its limits too. Free tiers are great until the service quietly stops accepting submissions because you hit the month's allowance.

Make sure nothing private accidentally became public

This is where I would slow down. A broken button is annoying. A leaked key, open database, or unsecured customer endpoint is a different class of problem.

Secrets and API keys

API keys, database passwords, private payment keys, and service tokens should not be sitting inside files the browser downloads. Search through your project for things named like:

secret token password apiKey .env

Do not immediately panic if you find the word “key.” Some identifiers are designed to be public. Stripe publishable keys and analytics IDs are common examples. The question is whether the service says that particular value is safe to expose.

If something private has already been published, deleting it from the project is not enough. Rotate it. Revoke the exposed credential and create another one. Once a secret has been public, assume somebody else could have it.

Environment variables

Environment variables are one of those things that work beautifully until they do not. A value can exist on your computer and be completely missing from the deployed site, or it can be placed into a variable that your framework intentionally exposes to the browser.

Different frameworks handle this differently, so do not memorize one naming rule and assume it applies everywhere. What matters is simple: your production environment should have every value it actually needs, and secrets should stay on the private side of the application.

Admin pages and APIs

If your project has an admin area, sign out and try to open it directly. You should not be able to see protected information just because you know the address.

Hiding a button is not security. If the browser says, “this user is not an admin, so do not show the Admin button,” that is fine for the interface, but the server still has to make the same decision when somebody asks for the data directly.

The same goes for APIs. If an endpoint returns customer information, order history, private files, or account details, the server needs to verify who is asking before it hands anything back.

If users can create accounts, test with two of them

One test account is not enough. Create two, sign into the first one and make some data, then sign into the second account and see what it can access.

Can account two see anything from account one? This is the kind of bug that can hide forever when the developer has only ever tested one user.

Also test signing out, signing back in, opening protected pages while logged out, and password recovery if you offer it. Authentication is one of those areas where “it worked once” does not tell you very much.

If money moves through the site, test the ugly paths

Test mode exists for a reason. Run a successful payment, then run a declined payment. Cancel halfway through, close the tab, reload something at a stupid time, and see what gets recorded and what the customer sees.

Make sure the price ultimately comes from somewhere the customer cannot simply edit in their browser. Make sure a successful payment produces whatever is supposed to happen after payment, whether that means recording the order, sending a receipt, unlocking something, or creating a booking.

Before launch, switch to the real payment environment and make one small real transaction yourself. I would rather lose a dollar testing my own checkout than learn from a customer that the live one never worked.

Know what information you are collecting

If somebody gives you their name, email address, account information, or anything else, know where it goes. Your privacy policy should describe the website you actually have, not the website an AI imagined while generating a generic privacy policy.

If the policy talks about five services you do not use, fix it. If you added analytics, a chat service, embedded media, or something else that collects information after the policy was written, update it.

Do not collect information simply because you can. Every piece of customer data you never store is one less thing you can lose.

Your site should also be running over HTTPS with a valid certificate. If a browser throws a security warning before somebody even gets through the door, most people are leaving.

Find out what failure looks like

Disconnect from the internet halfway through something. Submit a form. Load a feature when the backend is unavailable. You are looking for what the customer sees when reality gets involved.

They should not see database information, file paths, code, stack traces, or giant technical errors. They should see something useful, such as “Something went wrong. Try again,” “Your message could not be sent,” or “Please check your connection.”

If an action takes a few seconds, tell them it is happening. A button that appears dead gets clicked again, sometimes several times. That gets really entertaining when the button charges a credit card.

Do not obsess over a perfect speed score

A fast website matters. A perfect benchmark score usually does not.

What I care about is whether the site feels broken on an ordinary phone using an ordinary connection. Images are usually the first place to look. A photograph or generated image can be several megabytes without looking any better on a screen than a properly resized version that is a fraction of the size.

Load your site on mobile data. Watch whether content jumps around while it loads and whether you are staring at blank space waiting for a giant image. Use performance tools, absolutely, but treat them like diagnostic tools instead of a video game score.

Fix the big stuff. Do not spend your weekend chasing three points while the contact form still does not send.

Now ask the uncomfortable question: can anybody actually find it?

This part gets missed constantly because search visibility has almost nothing to do with whether the page looks good on your monitor. A beautiful website can still be nearly invisible to search engines.

Titles and descriptions

Open the raw page source and find the page title and meta description, then do the same thing on another page. They should not all be identical.

If the title still says React App, Vite App, Untitled, or something else left behind by the starter project, fix that before worrying about clever SEO tricks. The title should tell somebody what the page is, and the description should sound like a sentence a human would actually read.

Do not stuff a pile of keywords into either one.

What does the server actually send?

Open “View page source,” not the browser inspector, and search for your actual headline and a paragraph from the page. If your important content is missing and all you see is a mostly empty shell plus JavaScript files, the page depends heavily on the browser to construct what users see.

That does not automatically mean your site is doomed. Modern search engines can execute JavaScript. It does mean you should know what your rendering setup is instead of assuming the crawler sees exactly what you see.

There is a larger lesson here too. If your framework generates server-rendered output, that still does not prove your hosting provider is actually serving it. Test the live site, because local output and deployed behavior are not always the same thing.

Check robots.txt and sitemap.xml yourself

Open:

yoursite.com/robots.txt

and:

yoursite.com/sitemap.xml

Do not just check that the files exist in your repository. Open the real URLs.

If robots.txt says:

Disallow: /

you are telling compliant crawlers to leave the entire site alone. Sometimes that is intentional on a staging site. It is usually a disaster on the real one.

Your sitemap should load successfully and list the pages you actually want people to find. Click some of those URLs too. A sitemap that points search engines toward broken pages is not much of a sitemap.

Also look for noindex on public pages. That directive means exactly what it sounds like: please do not put this page into search results. There are valid reasons to use it, but your public services page probably is not one of them.

Structured data can help machines understand what you are

Structured data is information written specifically so machines can understand a page more clearly. It can describe the business, the services it offers, an article, a product, breadcrumbs, and other relationships that are obvious to a human but harder for software to infer.

It is useful, but it is not magic, and it should never claim something the visible website does not. Do not add fake reviews. Do not invent prices. Do not call yourself something in structured data that you never actually say you are on the page.

The goal is to make the truth easier for machines to read.

A few generated-project mistakes worth searching for

Before calling it done, search the whole project for leftovers like:

lorem example.com your@email.com TODO

Look for phone numbers, business names, and prices that changed halfway through the project. Look for features that exist visually but never got wired up. A newsletter field that does nothing is not a newsletter feature.

Look at your dependencies too. AI assistants are perfectly capable of installing a library, changing direction ten minutes later, and leaving the old package behind forever.

None of this means the tool did something wrong. AI works inside the context you give it, and it is very good at solving the problem sitting directly in front of it. What it is not naturally good at is stepping outside the project, looking at the whole system, and proving that everything still agrees.

That is why the last part matters.

Give your AI a different job: review instead of build

If you still have the AI assistant you used to build the project, you can make it useful here too. Just change the assignment.

Do not ask, “Can you improve my site?” That is how you end up building again.

Ask it to inspect what exists and explain what it finds without touching anything. You can copy the prompt below into ChatGPT, Claude, Codex, Cursor, or another assistant that can inspect your project. A fresh conversation is better, and a different model from the one that built the project can be even better.

You are reviewing this web project before it launches.

I own the project, but I may not understand every technical part of it. Explain
your findings in normal language first. Technical details can follow when they
are useful.

INSPECT ONLY.

Do not edit, refactor, delete, move, install, upgrade, replace, or automatically
fix anything.

Start by identifying the project's actual framework, rendering approach,
backend if one exists, hosting/deployment setup, and important external
services. Do not assume the stack from a single file.

Review the project for:

1. Security
   Look for exposed secrets, API keys, tokens, passwords, unsafe handling of
   user input, authorization that exists only in the interface, and endpoints
   that may expose information without properly checking who is asking.

2. Configuration and deployment
   Look for required environment variables, local-only configuration,
   hardcoded production values, undocumented deployment requirements, or
   anything likely to work locally and fail after deployment.

3. Routing and navigation
   Look for dead links, missing routes, broken direct loads or refreshes,
   incorrect 404 behavior, and pages that only work when reached through
   client-side navigation.

4. Forms and important user flows
   Look for submissions that can silently fail, missing error or success
   feedback, bad validation, incorrect destinations, and unfinished flows.

5. Accessibility
   Check labels, headings, keyboard access, accessible names, focus behavior,
   image alternatives, obvious contrast problems, and other barriers you can
   actually verify.

6. Search and discoverability
   Check page titles, descriptions, canonical URLs, robots directives,
   robots.txt, sitemap behavior, structured data, crawler-visible content,
   and anything that may prevent important public pages from being discovered.

7. Error handling
   Look for unhandled failures, internal information exposed to users,
   technical errors presented to customers, and important operations that can
   fail without a useful message.

8. Content and usability
   Look for placeholder content, inconsistent business information, dead ends,
   half-built features, and anything that makes an important customer path
   confusing.

For every finding, label it as one of these:

CONFIRMED
You have direct evidence in the code, configuration, deployed response, or a
test you actually ran.

POSSIBLE
Something looks suspicious, but you do not have enough evidence to call it a
confirmed problem.

MANUAL CHECK
It requires access, a device, an account, a production environment, or some
other evidence you do not have.

Do not turn POSSIBLE findings into facts.

Do not say something was tested unless you actually tested it.

Rank confirmed findings using:

CRITICAL
Exposed secrets, unauthorized data access, serious payment/authentication
problems, or something that makes the site unsafe to launch.

HIGH
Broken core features, serious deployment failures, blocked indexing, lost
submissions, or other problems that can materially hurt the business.

MEDIUM
Accessibility barriers, discoverability weaknesses, poor failure handling, or
issues worth correcting that do not block the entire launch.

LOW
Cleanup, consistency, polish, and smaller improvements.

For each confirmed issue include:

- Where you found it
- What is wrong, in plain language
- The evidence
- What could actually happen because of it
- The recommended next step
- How the fix should be verified afterward

If an area appears clean, say so briefly.

If the project is too large to review fully, state exactly what you reviewed
and what remains unchecked.

Finish with:

1. The five things worth addressing first, in order.
2. Anything I personally need to test because you could not.
3. A short plain-language summary of whether the project appears ready to
   launch and why.

Do not make any changes after the report.

After giving me the report, ask whether I want you to help correct the
confirmed issues one at a time using the recommendations you already gave.
Wait for my approval before changing anything.

The report comes first. You decide whether it gets to start changing things.

Read the report like a lead sheet, not a court ruling

AI audits can be useful, and they can also be confidently wrong. If it says something is CRITICAL, look at the evidence before panicking. If it says something is POSSIBLE, treat it like a lead to investigate.

If it says everything is perfect after looking at eight files in a 400-file project, you have learned something too.

Start with confirmed security, payment, authentication, and data problems. After that, deal with broken customer flows, then discoverability and accessibility. Polish can wait.

Your launch does not need to be perfect. It needs to be safe enough, understandable enough, and functional enough to put in front of another human being.

When another set of eyes is worth it

There is a point where throwing another prompt at the project stops helping. Maybe the report found something around authentication and you cannot tell whether it is actually dangerous. Maybe payments work, but you do not understand why the AI keeps warning about part of the checkout. Maybe it gave you twenty-seven findings and you have no idea which three matter, or maybe everything supposedly passes and you still do not trust the thing enough to launch it.

That is when a human review starts making sense.

A Project Review is exactly what it sounds like. I look at what you actually built, what is working, what is not, what I think is risky, and what it would realistically take to finish. You get the written assessment either way.

Sometimes the answer is that the project needs serious work. Sometimes it needs three boring fixes and you were closer than you thought. Sometimes I am not the right person for the job, and that is useful information too.

If you are not ready for that and just want to explain what is happening, tell me what you are working on. You do not need to know the technical name for the problem. Figuring that part out is the job.