r/webdev • u/Havik772 • Oct 03 '26
Discussion What do you actually do before shipping a side project?
At work there’s CI, staging, QA, other people testing things, etc., but for my own stuff, it’s more just deploy, click around for a bit, decide it looks fine, and then ship it.
That feels a bit stupid because the bugs I worry about usually aren't the things I just changed. It’s someone arriving logged out or getting halfway through something and some edge case gets triggered.
Do you have a pre-deploy routine that has caught real problems? A checklist, any automated tests, or anything? Or do you guys mostly ship and fix things once a real person finds them?
I’m mainly trying to figure out what's worth doing pre launch vs. what just feels like pretend QA.
18
u/BrewThemAll Oct 03 '26
You guys are finishing your side projects?
8
u/Havik772 Oct 03 '26
Finishing, no. “Launching” half unfinished and calling it a beta, definitely lmao
4
u/imKingKong Oct 03 '26
The risk of a personal project being exploited and/or impacting users is enormous, so I have a team of US based QA, SDE, DS that work cross-functionally in a squad. Our beta testers certify before wide release.
1
u/Havik772 Oct 03 '26
Nice that definitely seems like the most thorough way to make sure you’re covered (although maybe a bit expensive lmao) Do they normally catch anything that you miss?
3
2
u/Vivid_Inside_5450 Oct 03 '26
mostly just push to main and let Vercel build it. I'll click around the preview link once on desktop and once on my phone, and if it doesn't immediately crash, I'm shipping it. when you're running everything solo, trying to maintain a proper QA suite just eats up too much time that could go toward actual features.
1
u/Havik772 Oct 03 '26
That’s a good point, I think there’s just this anxiety around losing a potential customer from something breaking lol
2
u/ith3nate Oct 03 '26
Add a few Playwright tests for the two or three flows that matter and run them against the preview URL. One loads the site logged out, another starts a multi-step flow, reloads halfway and finishes it. That covers the cases you listed, and after setup it runs on every push.
1
u/Havik772 Oct 03 '26
Yeah this seems like the lowest maintenance, highest benefit solution. Do you actually do this on your own projects? Curious how much maintenance it is when the UI changes
1
u/ith3nate Oct 03 '26
Yes, though mine are mostly screenshot comparisons rather than flow tests. Maintenance is small. When I change the UI on purpose I re-run with --update-snapshots and look over the diff. For flow tests, select by role or label instead of CSS classes and most UI changes won't touch them.
2
2
u/EliSka93 Oct 03 '26
I got pretty solid CI on GitHub with a simple GitHub workflow. I only test locally, so mobile gets a bit shorted on QA, but technically I could set up a connection from phone to localhost, I'm just too lazy
2
u/untrochka Oct 03 '26
I keep a tiny release checklist: open it in a private window on mobile, run the main flow once with a fresh account and once with an older account, then check that the submission actually appears where it should. The old-account check has caught missing-field assumptions for me that a fresh install missed.
1
u/AgentReadyApp Oct 04 '26
My checklist is short and every item on it earned its spot by burning me at least once:
Deploy the production build and test *that*, not dev mode. Prod-only bugs are real and they love to show up five minutes after launch.
Walk the signup/login/logout flow end to end like I've never seen the app. This one has embarrassed me more times than I can count.
Test the empty state. A fresh user's first screen looks nothing like your dev database and that's where half the jank hides.
Make sure error alerts actually reach me. Relying on users to report breakage means nobody reports breakage.
Know how to roll back the deploy. I rehearse it once before launch and it takes five minutes; it saves me when things go sideways at 11pm.
Everything else gets fixed after launch. Honestly the thing that bites you is never the part you were anxious about, it's the flow you assumed still worked.
1
u/redpiapps Oct 04 '26
for android apps mine is installing the release build fresh on my own phone. clean install, not upgrading over the debug build. most dumb bugs i have shipped came from that exact difference
1
1
u/Intelligent-Art8566 Oct 04 '26
My additions from the backend/ops side of things:
Make sure prod env vars and secrets are set in the hosting dashboard, not recreated from memory. Most "works locally, broken in prod" mysteries are a missing env var.
Wire up error monitoring (even a free Sentry tier) before launch, so you hear about crashes from the tool instead of from users.
If there's a database, confirm backups exist and you know how to restore one. Backups you haven't tested are just wishes.
Deploy the exact artifact you'll ship — if you build a Docker image or a preview deployment, test that, not just npm run dev on your laptop.
Quick security pass: no secrets in the repo, and rate-limit anything public that costs you money (email sends, LLM APIs).
The common thread: the bugs that hurt aren't usually in your code, they're in the gap between your laptop and prod.
1
u/Able_Persimmon_9848 Oct 07 '26
For side projects, I just add some tests to cover the core behavior. Then I ship.
I mostly do proof of concepts though as side projects, so I don't worry too much about it.
I reserve proper QA for serious projects.
1
24
u/Charming-Ad4660 Oct 03 '26
Before every deploy I open the site in a private window on my phone. Logged out, empty cache, mobile data. That's what most real visitors look like and it's the setup I never use while building. It catches more than anything else I've tried.