I Almost Shipped a Vibe-Coded Site Without Testing These 8 Flows

I built a site with an AI coding tool in a weekend. It loaded. The buttons worked. The main feature did what I asked. I was one click away from shipping it.

Then I ran these 8 flows and found three bugs.

AI coding tools can turn an idea into a working website fast. A manual walkthrough does not prove that real users can finish the same tasks. They enter unexpected data, refresh at the wrong time, lose their session, or hit a slow network. Test the journeys that matter from start to finish before you launch.

8 user journeys to test before launching a website

1. First visit and page loading

Open the homepage. Wait for it to load. Review the navigation and main content. Refresh the page. Check it on a mobile screen.

• Any blank screens, console errors, or long loading times?
• Do images, fonts, icons, and backgrounds load?
• Does the layout work on desktop and mobile?
• Is the page still usable after a refresh?
• Are the main buttons clear and clickable?

2. Sign-up and login

Open the sign-up page. Create an account. Sign in. Reach the account page.

• Are email addresses, phone numbers, and passwords validated?
• Does the form say which required fields are missing?
• Does the app handle an account that already exists?
• Do invalid credentials show a useful message?
• Does a successful sign-in lead to the right page?
• Does the session stay active after a refresh, as the product design intends?

3. The core feature

Open the main feature. Provide the required input or file. Start the task. Wait for it to finish. Review the result. This is often the most important journey to test before launch.

• Is submission blocked when required information is missing?
• Does invalid input show a clear message?
• Is there a loading or progress state while the task runs?
• Can repeated clicks submit the task more than once?
• Is the result accurate and easy to find?
• Does the app explain what happened if the task fails, times out, or hits an API error?

First bug: my core feature submitted twice when I double-clicked the button.

4. Form submission

Complete a form. Submit it. Check the validation messages and the saved result.

• Are required fields validated?
• Do character limits, special characters, and long values behave as expected?
• If submission fails, does the form keep what the user entered?
• Can double-clicking submit create duplicate records?
• After success, does the app show the right page or confirmation?
• Is the data saved in the backend or shown in the right list?

5. File upload and processing

Choose or drag in a file. Follow the upload progress. Wait for processing. View or download the result.

• Are the supported file types and size limits clear?
• Do both the file picker and drag-and-drop upload work, if both are offered?
• Can users cancel an upload or pick a different file?
• Does the app explain what to do after a network interruption?
• Do filenames with spaces, non-English characters, or symbols work?
• Can users retry after a processing failure?

6. Navigation, redirects, and browser history

Move from the homepage to a feature. Open a detail page. Edit an item. Return to the list or previous page.

• Do navigation links, buttons, and text links open the intended page?
• Do the browser Back and Forward buttons work as expected?
• Does a detail page still load after a refresh?
• Does the app warn users before they leave an unsaved edit?
• Are page parameters passed to the right place?
• Does an unknown URL show a useful not-found page?

7. Permissions, sessions, and error states

Open a protected page while signed out. Sign in. Use the feature. Sign out. Revisit the page.

• Are signed-out users sent to the right sign-in flow?
• Can a standard user access admin-only actions?
• Does access control still work when someone enters a protected URL directly?
• Does an expired session ask the user to sign in again?
• Are permission errors, failed requests, and server errors explained clearly?
• After signing out, can the user still reach content that requires an account?

Second bug: after signing out, I could still open a protected page with a saved URL. Nothing on the page told me I shouldn't be there.

8. Payment, subscription, or conversion

Review a plan. Select an option. Start payment. Confirm success. Check that the order and account status are updated.

If your website has paid features, also check:

• Do the plan price, discount, and final amount match?
• What happens when payment is cancelled, fails, or is submitted twice?
• Are the purchased features available after a successful payment?
• Does the order status stay correct after a page refresh?
• Can users find their order history, refund information, or support contact?

Turn risky journeys into repeatable regression tests

A change to the page, API, or business logic can break a flow that worked yesterday. Repeating every check by hand after every change takes time and misses regressions. The third bug appeared after a change that I never re-tested.

Start by testing the app by hand. Then turn the high-frequency, high-impact journeys into automated tests.

For browser workflows such as sign-in, form submission, file upload, and admin tasks, CueCast lets a team record steps on a real web page and replay them later. The recorded steps become reusable test cases. A team can run the same checks after a release without writing a browser test framework first.

Results include step status, screenshots, and logs to help find a failure. Small UI changes may not need a full test rebuild. A change to the business flow still means updating the relevant steps. The goal is to keep the most important regression tests easy to run and easy to maintain.

Before you launch

Start from the user's first visit and go through the actions that deliver value. If time is short, prioritize sign-up and login, the core feature, form submission, and permissions and error handling. Once those journeys work by hand, automate the ones your team needs to repeat after every meaningful change.