How do you find out when something on your site quietly breaks?

I've been working on a couple of products, and since it's just me, I've handling everything: building, marketing, support, all of it. The main problem is on the building side, now that it's so easy and fast to iterate, changes happen so fast that I don't always know what a change actually touched.

Lately I've realized I don't have a real way to know when something breaks. If signup stopped working or a confirmation email stopped sending, I'd probably only find out when someone emailed me or they'd just leave and I'd never hear about it. This is where I have a lot of anxiety. Every person who hits a broken page and bounces is someone I worked hard to get there in the first place, and it would suck to lose them over something so trivial.

Right now my "process" is clicking through the main pages after every change and hoping for the best. I've tried a couple of pre-launch checklists from online, but they seem either way too long or way too generic for my setup. I've looked into automated testing too, but setting up and maintaining a whole test suite feels like a lot when I'm already doing everything else.

So I'm curious what the rest of you actually do. Have you ever had something break quietly and only found out later? How'd you find out, and did you change anything after? Especially interested in hearing from other people running things solo, since I feel like a lot of advice out there assumes you have a team.

reddit.com
u/Havik772 — 10 days ago

How do you know your app still works after you change something?

Every time I make a change/fix, I always get a little nervous it broke something somewhere else. Right now I just click through the main pages after each change and hope.

Does anyone have any checks they actually do to check? Has anyone ever had a change break something you didn't notice until a user told you?

reddit.com
u/Havik772 — 11 days ago
▲ 10 r/webdev

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.

reddit.com
u/Havik772 — 12 days ago

A couple months ago I launched something I'd spent months building, and got almost 100% churn. I told myself it was a marketing problem and poured more money into it. It wasn't. I had built something for a customer I'd made up in my head and never actually validated.

I'd read The Mom Test and knew I should talk to customers. I just never did, it felt too slow and tedious, so I skipped it and built instead (that's the fun part anyways).

So I built Corta to fix the thing I kept skipping.

Describe your idea in a short conversation. Corta searches hundreds of Reddit and X posts, finds real people expressing that pain, and produces a grounded ICP showing who your customer actually is, what they've tried, and what to build first, all backed by real posts.

trycorta.com

Honest feedback is really appreciated! Is anything missing, does the output help?

u/Havik772 — 6 months ago