At work, releases usually 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 someone arriving logged out, using a phone, reloading halfway through a process, or hitting an edge case I didn't encounter during development.
Do you have a practical pre-launch routine that has caught real problems? Do you use a checklist, automated tests, preview deployments, or some other lightweight process? Or do you mostly launch and fix issues when users report them?
I'm trying to figure out what's genuinely worthwhile before launch versus what just feels like pretend QA when working solo.
4 Answers
A few Playwright tests aimed at the most important user journeys give a good middle ground. For example, test the logged-out landing page, start a multi-step workflow, reload halfway through, and finish it. Run those against the preview deployment on every push. You don’t need to automate every button—just protect the flows that would be most damaging to break.
For a solo project, I’d keep the routine small: click through the main path on desktop and mobile, test logged out, and verify the deployment itself. A full QA process can consume more time than it saves when there aren’t many users yet. If something breaks, fix it quickly and add a regression check when the bug was important.
That makes sense. I think the anxiety is mostly about losing a potential user because of one broken flow, even when the rest of the product works.
Basic unit and integration tests plus a simple CI workflow are usually enough to start. I’d also include a short release checklist: deploy the exact build you tested, check authentication and permissions, try the main flow from a clean session, test on a phone, and confirm error handling. For anything involving payments or sensitive data, add a more serious review instead of relying only on clicking around.
Before deploying, I open the site on my phone in a private window with the cache cleared, usually over mobile data. That gives me a logged-out, first-time visitor setup, which is very different from the environment I use while building. It catches more issues for me than almost anything else.
That’s roughly what I do too, but I always worry I’m still missing something. Have you had important bugs slip through even after checking that way?
That sounds like the best effort-to-value tradeoff. I’m curious how much maintenance those tests need when the UI changes, though.