"I'll check it before launch" usually means clicking the homepage once on your own laptop. This week we ran passive checks against a few dozen freshly launched indie apps. None of it was intrusive: plain GET/HEAD requests to the site each project listed, reading status codes and headers. Here's what came up, roughly in order of how much it would hurt.
Things that break the launch itself
- The listed demo link returned 404. The project was active and the demo URL was still on its project page, but the hosted preview behind it no longer loaded.
- The site timed out twice in a row from a clean request. On launch day that reads as "dead project".
- A HEAD request returned 405. GET worked, but uptime monitors and link-preview bots often send HEAD first, then report the site as down or show no preview.
- The listed site was a design-tool page (a Figma Sites URL) rather than the product's own domain. That's fine for a mockup, but it's a fragile thing to send launch traffic to.
Baseline hardening that was simply missing
- No Content-Security-Policy header on most sites checked. It's not a vulnerability by itself, but it's the first thing a security-minded user or reviewer looks for.
-
CSP present, but with
unsafe-inlineandunsafe-evalfor scripts, which removes most of what CSP is for. - No HSTS, so the first visit over plain http isn't forced to https.
- No Referrer-Policy or X-Content-Type-Options. These are one-line headers, and most hosting platforms let you set them in a config file.
Also worth a look (not from this batch)
A few other checks cost nothing: an Open Graph image so shared links get a preview, a real page title instead of the framework default, www and the bare domain both resolving, and a real favicon.
What to take from it
The items that cost the most (1-4) take a minute to catch and aren't about security at all. They're about whether the thing you're pointing people at actually loads for a stranger. Before posting, open your launch link in a private window on your phone, and paste it into a Slack DM to yourself to see the preview.
If you want this as a checklist that runs in your browser, the free 12-check version is here: https://launch-gate-demo.smagnezi8.workers.dev
Launch Gate only runs passive checks. It is not a security audit or a penetration test.
Top comments (3)
This is such a pragmatic, high-value checklist that most builders overlook on launch day.
The point about HEAD requests returning 405 Method Not Allowed is a silent killer—so many preview scrapers (Slack, Discord, Twitter/X, LinkedIn) rely on lightweight HEAD checks before rendering rich unfurls, and returning a 405 immediately kills social reach before anyone even visits the page.
Coupling this with baseline HTTP security headers (HSTS and strict Referrer-Policy) should really be automated as a standard pre-flight checklist for indie launches.
Thanks for compiling these real-world failure modes; definitely bookmarking this for future releases!
I'd narrow my own wording on HEAD here: the observation was "HEAD returned 405 while GET worked," not a verified preview failure on those platforms or a measured loss of reach. I'd record those as separate checks and test the actual shared-link preview before claiming an impact. Likewise, a header-presence check is a review prompt, not a reason to apply a policy blindly or label a site secure. Launch Gate stays a passive preflight, not a security audit. Thanks for reading the checklist.
Thanks for the clarification, that makes sense. Separating the observation (405 on HEAD) from actual impact is the right call, and testing the real preview in each platform debugger would settle it. Honestly, the server saying Method Not Allowed to HEAD while GET walks right in is the most relatable thing I have seen all week. Appreciate the thoughtful follow-up!