Eleven places fast-built apps quietly break.

Common failureA site can look finished on the home page and still be missing the parts that search engines, shared links and first visits actually see. A typo URL, a pasted link or a browser tab then shows a blank page, a framework default or a title copied onto every page.

• Custom 404. On the production domain, visit a made-up path such as /this-page-should-not-exist-123. In the Network panel, the response status should be 404. The page should be yours, with a clear way back to a real page, not a blank screen, a framework default or a 200 that pretends the page exists.
• CTA above the fold. On a desktop window and on a phone, load the main landing page. A clear next step should be visible without scrolling, not only in the footer or buried in the nav.
• Unique title and description. View source on every public page. Each should have its own title and meta description, written for that page, not one site-wide string or a framework default such as "Vite App" or "Create Next App".
• Open Graph image and tags. Check for og:title, og:description, og:image and og:url. Paste a production URL into a share preview tool or a chat app and confirm the image and text appear, not a blank card or an internal preview domain.
• Favicon set. Confirm a favicon shows in the browser tab, and that the head includes an apple-touch-icon whose file actually loads. Add the site to the home screen on a phone if you want to see the icon there.
• Robots and sitemap. Open /robots.txt. In production it should not Disallow the whole site, and it should point to your sitemap. Open the sitemap and check it lists real production URLs, not localhost or a preview domain, and that every important page is there, including new ones.
• Alt text. Check every meaningful image, such as photos, diagrams and icons that convey meaning. Each should have alt text that describes the image. Decorative images can use empty alt. In dev tools, search for img tags and review the attributes.
• Analytics. If you use analytics, open the live site in a private window, trigger a page view and confirm the visit appears in your analytics tool. A tag in the page source is not enough.

Common failureAuth tends to work for the account it was built with and fail for everyone else: a brand-new signup, a returning user in another browser, or someone holding an older reset email.

• New account. In a private window, sign up with an email address never used on the app. Confirm you land where a new user should, not on an error or an empty screen that never loads.
• Returning login. Log out, close the window, open a fresh private window and log in again. Then enter a wrong password and confirm the error message is clear.
• Same email, typed differently. Try signing up again with the same address in capitals or with a trailing space. You should not end up with two accounts, and login should work either way.
• Reset mail. Request a password reset. Confirm the email arrives, the link opens on your production domain rather than localhost or a preview address, and the new password works.
• Stale reset links. Request two resets in a row, then open the earlier link. It should be refused. Use the newest link once, then open it a second time. That should be refused too.

Common failureA saved message is a screen state, not proof. Apps often show success based on what is on the page while the write failed, went to the wrong place, or is replaced by an older copy on reload.

• Refresh. Create or edit something real. When the app says it is saved, refresh. Check every field is there exactly as typed.
• New tab. Open the same item in a second tab. Change it in one tab, refresh the other, and confirm the newer version shows.
• Logout and back. Log out, log back in and check again. Then log in from a different browser or device and check once more.
• Leave early. Make an edit and navigate away or close the tab straight away. Reopen it: the app should have kept the change or warned you before you left.
• Failed save. In browser dev tools, set the network to offline and try to save. The app should show a failure, not a success message.
• Slow network. In dev tools, set the network to Slow 3G and run a save, a submit and a page that loads a list. Buttons should show progress and should not accept a second click while the first request is still running. Empty and loading screens should not flash an error or a blank page before the data arrives.

Common failureWhen people can start before signing up, the signup step in the middle of the flow is where work gets dropped, or tied to a temporary session that disappears. The success message can still say it was saved.

• Start as a guest. Logged out, go far enough into the main task, such as a draft, a cart or a setup, that losing it would be annoying.
• Sign up mid-flow. At the point where the app asks for an account, create one from there. Afterwards the work should still be on screen.
• Prove it stuck. Refresh, log out and log back in. The guest work should now belong to the new account.
• Log in instead. Repeat with an existing account that already has saved data. The guest work should merge or be offered, never silently replace what was saved.
• Message versus data. If the app says your work was saved to your account, open the account in a fresh private window and confirm the saved data matches what the message claimed.

Common failureCheckout often works on localhost and fails after deploy, because webhook endpoints, signing secrets, return URLs or test and live keys were only set up for the local environment.

• Sandbox only. Put the payment provider in test or sandbox mode for the deployed environment. Never use a real card for this check.
• Checkout on the live URL. On staging or production, not localhost, pay with the provider's test card and confirm you return to the right page on your own domain.
• Access actually changes. The paid feature unlocks, the plan name updates, and both survive a refresh and a fresh login.
• Callback delivered in production. In the provider dashboard, open the webhook or event log for that test payment. Confirm it reached your deployed endpoint and got a success response, not a timeout, a not found or a signature error.
• Unhappy paths. Use a declined test card, and abandon a checkout halfway. Neither should grant access. After a successful payment, press back and confirm no second order is created.
• Cancel and downgrade. If you offer them, run them and confirm access is removed when your rules say it should be.

Common failureGenerated code often checks that someone is logged in, but not that the record they asked for belongs to them.

• Two accounts. Create test accounts A and B. Use two different browsers, or one normal and one private window.
• Direct links. As A, create a record and copy its URL. As B, open that URL. B should see a refusal or not found, not A's data.
• Changes across accounts. As B, look for any way to edit or delete A's record: shared links, ids in the address bar, list pages. None should work.
• Lists and search. As B, check lists, search results and exports for anything belonging to A.
• Lower role, higher page. If the app has roles, log in as the lowest one and type the address of an admin or settings page directly.

Run these on your own app with your own test accounts only.

Common failureSecret keys end up in the browser when they are imported into front-end code or given a public prefix, and admin, debug or seed routes get shipped without a login check.

• Search what ships. On the deployed site, open dev tools, look through the loaded JavaScript files and search for words like secret, sk_, service_role, private and password. Publishable keys meant for the browser are expected. Secret keys are not.
• Public prefixes. Check your environment variable names. Many frameworks send anything with a public prefix, such as NEXT_PUBLIC_ or VITE_, to the browser. Secret keys should never carry one.
• Routes you forgot. Logged out, visit addresses you never meant to be public: /admin, test pages, debug or seed endpoints. They should ask for login or not exist.
• Database rules. If your database has access rules, confirm they are switched on for every table holding user data, not only the first one you set up.
• Rotate, do not just delete. If a secret key was ever exposed, rotate it in the provider dashboard. Removing it from the code does not take it back.
• Paid API spend cap. If the app calls an AI model or any other paid API, set a usage cap or a budget alert in that provider's dashboard. Then, from your own test account, send repeated rapid requests and confirm they are refused or queued once the limit is hit, rather than running without a cap.

Common failureA successful publish means the build finished. It does not mean the live URL works. Preview and production often differ in environment values, auth settings and domains, so a flow that passed in preview can fail live.

• Fresh window. Open the production URL in a private window, signed out, with nothing cached.
• Login on the real domain. Sign up or log in on production. If it worked in preview but fails live, check that the auth provider's allowed redirect URLs and origins include the production domain, with and without www.
• Main flow end to end. Run the one flow the app exists for, start to finish.
• Console and network. Keep dev tools open while you do it. Look for red console errors, failed requests, CORS errors and any request still going to localhost or a preview address.
• Environment values. Compare preview and production settings: API base URL, database, auth keys and payment keys. Production should use the ones you intended.
• Domain and HTTPS. Load both the bare domain and the www address. Both should reach the site without a certificate warning.

Common failureApps checked in a wide desktop window break on phones: fixed bars cover buttons, dialogs run off screen, and the on-screen keyboard hides the field being typed in.

• Real phones. On an actual phone, ideally Safari on iOS and Chrome on Android, run signup, login and the main flow.
• Keyboard open. Fill every form with the on-screen keyboard showing. You should see the field you are typing in and reach the submit button.
• Sideways scroll. Look for pages that scroll sideways, text cut off at the edge and buttons too close together to tap accurately.
• Rotate and dismiss. Rotate the phone mid-flow and back. Open and close every menu and dialog.
• Narrow desktop. Shrink a desktop browser to about 360 pixels wide as an extra pass. It does not replace a real phone.

Common failureEmail that worked in development can fail quietly in production when the sending domain is not verified, the email provider is still in test mode, or links are built from a local base address.

• Trigger each one. Welcome, verification, password reset, receipts and invites. Send each to a real inbox you control.
• Arrival. Confirm each one arrives, and check the spam folder too.
• Every link. Click each link inside. It should open the right page on your production domain, including when opened on a different device.
• Content. Check the sender name and subject, and that placeholders such as a first name are filled in, not blank or showing template code.
• Right person only. With accounts A and B, confirm notifications reach the account they are meant for and nobody else.

Common failureAn AI-assisted fix often touches shared code: a helper, a layout, an auth check. The reported bug goes away and a nearby flow breaks. Being told something is fixed is not the same as it being fixed in the app.

• Retest the original bug. Use the original steps on the deployed site, not the description of the fix.
• Rerun the neighbors. After an auth change, rerun C02 and C06. After a save or data change, C03 and C04. After a payment change, C05. After every deploy, C01 and C08.
• Read the change list. Look at which files changed. If anything outside the bug's area was touched, test those features too.
• Keep a short flow list. Write down your core flows once and rerun them after each change. This page is a starting point.
• Record the result. Note what you retested and what happened, so the next change starts from a known state.