Someone marks a comment “Fixed.” You glance at it, it looks fine, you click approve. Three days later the same bug — or a new one right next to it — shows up on the live site. That gap between “marked fixed” and “actually fixed” is where a surprising number of website review cycles quietly restart.
Why do “fixed” website bugs come back after you already approved them?
They come back because “fixed” and “verified” are two different claims, and most review workflows only check the first one. A developer marking a comment “fixed” means they believe the change addresses what was reported. It doesn’t mean anyone re-ran the steps that surfaced the bug in the first place, and it definitely doesn’t mean anyone checked whether the change broke something nearby. Testing terminology treats these as two distinct passes: confirmation testing, which re-runs the exact steps that found the original defect, and regression testing, which checks that the fix didn’t break something the change wasn’t supposed to touch. Skip either one and “fixed” is a developer’s opinion, not a confirmed fact.
Fred Brooks made a version of this point decades ago in The Mythical Man-Month: maintenance work requires far more testing per line of code than the original build did, because every change lands on top of everything that was already working. A website redesign has the same shape — every fix is a small change to a system that was, until that moment, functioning. The fix can be correct on its own and still create a new problem two sections down the page.
What’s the difference between confirming a fix and actually verifying it?
Confirming a fix means checking that the specific bug you reported is gone. Verifying it means also checking that nothing around it broke. Founder-developer reviews tend to treat these as the same step — someone looks at the one thing that was wrong, sees it’s fixed, and approves. By the ISTQB definition, confirmation testing is testing performed on a fixed defect to confirm the failure it caused no longer occurs — that’s the narrow check, and it says nothing about the rest of the page.
For a website review, that means two passes instead of one: re-run the exact steps that found the bug — same browser, same viewport, same click path — and then look at what sits near the fix. If a developer adjusted spacing on a pricing table, scroll the rest of that page and any other page that shares the same layout before you approve. A fix being correct in isolation doesn’t mean the page is correct as a whole.
Why shouldn’t the developer be the only person who checks their own fix?
Because the person who wrote the fix is the least likely person to spot what’s still wrong with it. They already believe it works — that’s why they marked it fixed — and that belief shapes what they look at when they check their own work. Developers testing their own code tend to test to confirm it works, while an independent reviewer tests with the intent to break it — two different mindsets aimed at two different outcomes. One line from that piece puts it bluntly: a developer evaluating their own code is “like a mother who could not find faults in her own baby.”
This isn’t a knock on developer competence. It’s a structural blind spot — someone who just spent an hour reasoning about why a fix should work is reasoning from the same assumptions that produced the bug in the first place. The founder or reviewer who reported the original issue doesn’t share those assumptions. Checking from the outside is exactly the perspective that catches what the developer can’t see in their own change.
How do you catch a regression a fix accidentally introduces somewhere else?
You catch it by checking the areas that share code, layout, or components with whatever just changed — not by re-checking only the one spot that was reported. A regression is a defect that shows up in a part of the site that wasn’t the target of the change and was previously working correctly. A summary of the concept lists the most common causes: a fix that solves the narrow case it was written for but not the general one, and a change that inadvertently produces a new bug somewhere else in the process of fixing the first one.
On a website, the highest-risk spots for this are shared components — a header, a footer, a card layout, a font size defined once and reused on a dozen pages. If the fix touched something that’s shared, check every page that reuses it, not just the page where the bug was originally pinned. A one-line style change to fix a button on the pricing page can just as easily shift a button on the homepage that pulls from the same class.
What does a fix-verification pass actually look like, step by step?
A four-step pass: re-run the original repro, check the rest of the page the fix touched, check any shared components elsewhere on the site, and re-check on the same device and viewport where the bug first appeared. Skipping the device step is common and costly — a fix built and tested on desktop can look complete while the mobile viewport still shows the original problem, since the two often render from different code paths.
This is where a status-tracked tool earns its keep over a Slack thread of screenshots. Simpl_Markup keeps every comment’s status — open, fixed, approved — pinned against the exact element and viewport it was reported on, so re-checking a fix means clicking back to the same pin instead of reconstructing which screenshot showed what. Compare that to a screenshot-and-arrow workflow in Slack, where the original context — which element, which viewport, which page state — usually isn’t preserved anywhere, so “verifying” a fix means trusting memory instead of re-checking the original website annotation.
What if there isn’t time to re-check every page after every fix?
Prioritize by where the fix landed, not by checking the whole site every round. A one-line copy fix on a single page carries almost no regression risk and barely needs more than the confirmation pass. A change to a shared component — navigation, a card grid, a font token used across templates — carries real risk, because the blast radius extends past the page where the bug was reported. This is the same logic testing teams use when they can’t test everything: risk-based testing prioritizes test effort using two factors, the likelihood a defect exists and the impact it would have if it did, rather than spreading a fixed amount of checking evenly across low- and high-risk changes.
Applied to a website review, that means asking one question before deciding how hard to check a fix: does this change touch something used in more than one place? If yes, spend the extra five minutes checking the other pages that share it. If no — a single isolated element on a single page — the confirmation pass is usually enough, and the founder’s limited review time is better spent elsewhere in the backlog.
When should you reopen the original comment instead of filing a new one?
Reopen the original comment if the fix didn’t fully resolve what was reported or introduced a new problem in the same area; file a new comment only if it’s a genuinely separate issue. In defect-tracking terms, this is the “Reopened” status: a fix that didn’t resolve the original issue or introduced a regression sends the item back through the cycle rather than starting a new one. Reopening keeps the full history — the original repro, the fix attempt, and why it fell short — attached to one thread instead of scattered across two.
This matters more for async feedback than for a live call, because there’s no shared memory of “wait, didn’t we already cover this” to catch the duplicate. A new comment with no link back to the first attempt reads to the next reviewer as a brand-new bug, and the developer loses the context of what they already tried. Reopening the original thread is the difference between a two-line follow-up and a fix getting re-explained from scratch.
None of this needs to slow a review down. It needs one habit change: treat “fixed” as a claim to check, not a status to trust. Re-run the steps that found the bug, glance at what’s nearby, and only then hit approve.