At work, releases go through CI, staging, QA, and testing by other people. With my own projects, I usually deploy, click around for a few minutes, decide everything looks okay, and ship it. That feels risky because the bugs I'm most concerned about usually aren't in the code I just changed. They're things like a visitor arriving logged out, using a phone, refreshing halfway through a multi-step process, or hitting an unusual edge case. Do you have a practical pre-launch routine that has caught real problems? I'm especially interested in checklists, automated tests, and deciding what's worth testing before launch versus what's better handled after a user reports it.
4 Answers
One of the highest-value checks is opening the site in a private browser window on your phone, with an empty cache and mobile data. That’s much closer to how a first-time visitor experiences it than your usual development setup. It catches login, loading, responsive-layout, and network issues surprisingly often.
A simple continuous-integration workflow is worthwhile even if you’re working alone. It can catch build failures, type errors, and broken tests on every push. Manual mobile testing may still be necessary, but automated checks give you a safety net before you start clicking through a release.
My routine is pretty lightweight: run the existing unit and integration tests, check the preview build, then manually test the main flow once on desktop and once on a phone. I also try a logged-out session and a fresh account. For a small project, pushing every change through an elaborate test process can cost more time than it saves, so I focus on the paths that would lose users or corrupt data.
For a solo project, I’d keep the automated coverage small and focused. A few Playwright tests against the preview deployment can cover the important paths: loading the site logged out, completing the main action, and refreshing halfway through a multi-step flow. Those tests give you useful protection without turning the project into a full QA operation.
That seems like a good balance. My main concern is how much maintenance the tests need when the UI changes, but the core flows probably don’t change that often.
That’s roughly what I do now, but I still worry I’m missing something that only appears in a less obvious flow.