A founder asked me this after a review turned up a handful of findings right before a planned launch date: does everything genuinely need to be fixed before going live, or is it reasonable to launch with some of it still open and address it shortly after? I don't think there's one universal answer, but there is a real, useful way to think through it rather than treating every finding as equally urgent.
Why treating every finding identically is itself a mistake
Security findings aren't uniform in severity, and a policy of "nothing ships until everything is fixed" tends to produce one of two bad outcomes: launches get delayed indefinitely chasing an ever-growing list, or the whole list gets ignored under deadline pressure because treating a minor header misconfiguration with the same urgency as an open database feels disproportionate, and eventually that disproportion causes people to stop taking the list seriously at all.
What actually deserves a hard stop before launch
- Anything letting one account see or modify another account's data. This is the core failure mode behind nearly every real incident and it's never reasonable to launch with this open.
- Any exposed key or secret with real, active permissions attached, especially anything touching payments, admin access, or third-party billing.
- A missing or broken authentication check on any route handling real user data.
- Anything a regulator, a specific law, or a signed contractual commitment requires before launch, regardless of how the technical severity feels.
What's more reasonable to launch with and fix shortly after
- Missing or incomplete security headers, genuinely worth fixing soon, rarely the difference between safe and unsafe on their own.
- A rate limit that's present but more generous than ideal, as long as some limit exists at all.
- Non-sensitive information disclosure that doesn't expose anything about a real user or account.
- Findings on features not yet live or not yet handling real data, where the fix has a natural, non-arbitrary deadline attached to when that feature actually ships.
The actual test worth applying
Ask, honestly, about each specific finding: if this were exploited on day one, what's the actual damage, and is that damage something a real person would experience directly, their data, their money, their account? If the honest answer involves a real person's data or money, that's a hard stop, not a post-launch fix. If the honest answer is closer to a hardening improvement with no direct path to real harm, a scheduled, near-term fix is a reasonable, non-reckless choice.
Perfect security before any launch is rarely a realistic bar, and pretending otherwise usually just produces indefinite delay or quiet non-compliance. A clear-eyed, honest severity judgment, applied specifically rather than as a blanket rule, is what actually lets you ship responsibly instead of either recklessly or never.