A website or app that looks finished in a design file can still fail the moment real users touch it. Most of the problems that surface after launch were visible earlier, they just were not checked for. This list covers what to verify before anything goes live, not after.
Research you should not skip
Even a short round of research changes a design meaningfully. At minimum, look at how competitors structure their core flows, talk to five to eight real or prospective users about what they expect to find and where, and write down the three tasks a visitor most needs to complete. Every screen should be judged against whether it moves someone closer to completing one of those three tasks.
Information architecture basics
Before any visual design starts, map out every page and how they connect. A simple sitemap on paper or in a tool like Figma reveals problems that are expensive to fix once development has started: duplicate pages trying to do the same job, a navigation menu with too many top level items, or a checkout flow that is actually six steps when it should be three. Test the navigation labels with someone unfamiliar with the project. If they cannot guess what a menu item leads to, rename it.
Mobile first checks
In most markets, the majority of traffic arrives on a phone, so design decisions should be validated on mobile first, not as an afterthought. Check that every tappable element is large enough to hit accurately, that forms do not require excessive zooming or scrolling, that images load fast on a typical mobile connection, and that nothing important is hidden behind a hover state, since hover does not exist on a touchscreen. Test on an actual mid range device, not just a resized browser window, since real devices reveal font rendering and tap target issues that simulators miss.
Accessibility essentials
Accessibility is often treated as optional, but a meaningful share of visitors will interact with a site using a screen reader, keyboard navigation, or with reduced vision. Before launch, confirm that text has sufficient contrast against its background, that every image has descriptive alt text, that the site is fully navigable using only a keyboard, and that form fields have clear, programmatically linked labels, not just placeholder text that disappears when someone starts typing. These checks also tend to improve usability for every visitor, not only those using assistive technology.
Usability testing before launch
The cheapest bugs to fix are the ones caught before launch. Hand the live staging site, not a prototype, to five people who have never seen it and ask them to complete the core tasks you identified earlier, out loud, without guidance. Watch where they hesitate, where they click the wrong thing, and where they give up. A pattern across even three or four testers is worth fixing before launch, a single person's confusion might just be one person's habit.
This kind of testing takes a day, sometimes less, and it consistently catches the issues that would otherwise show up as support tickets or silent drop off in the first week after launch.