1. Dependencies patched, lock file checked
A framework version with a known remote-code-execution flaw is enough to hand a server to a stranger. Before launch, and monthly while we maintain a project, we run npm audit --omit=dev (or composer audit, pip-audit) and read the framework's security bulletins. A release with a known remote-code-execution or authentication-bypass issue does not ship.
The second half matters as much: after patching, we check the lock file. If package-lock.json still pins the old version, the next clean build quietly puts the vulnerable version back.
2. Each service isolated
Every Node or Python service runs under systemd with its own user, a memory cap, a private temp directory, no new privileges and a read-only view of the system. Databases and caches listen only on localhost; the firewall opens only SSH, HTTP and HTTPS. The goal is simple: one compromised app must not be able to take the whole machine with it.
3. Inputs validated on the server
Every form, route handler and API input is checked against a schema on the server, with a rate limit and a spam check. User input is never passed to a shell command or used to build a file path. Uploads live outside the web root with size and type limits, and admin endpoints require authentication.
4. The funnel counted on the server
Browser analytics undercount: consent choices, ad blockers and privacy browsers all remove visits. So each step that matters (page view, button click, form start, submit, error) is also counted on our own server, anonymously, with no cookie and no IP. Errors are counted with their reason. "Could not save" on its own is not enough; "validation", "rate limit" or "server" tells you what to fix.
We never send a fake purchase or sign-up to production analytics to see if tracking works. One fake event in a small table ruins it. Instead, we cut the request in the browser and read the payload it would have sent.
5. No personal data in analytics
By default, Google Analytics receives the full page URL and the page title. If a path or title contains a name, an order number or a private link, that goes to a third party. We turn off the automatic page view and send our own, with paths reduced to patterns (/order/8423 becomes /order/[id]) and fixed titles on sensitive pages. Session-recording masks are written in code and checked against the live page, not left to a dashboard setting.
6. Mobile Lighthouse target of 95+
Most visitors arrive on a phone. We aim for 95 or higher in Lighthouse mobile for performance, accessibility and SEO, near-zero layout shift and a largest contentful paint under two seconds, and we report the measured numbers at handoff.
7. AI-facing facts verified
Files like llms.txt, structured data and FAQ blocks are read by AI search tools as an authoritative source. A wrong claim there gets repeated as fact. So every product claim in those files (prices, timelines, what data is kept, what a product does) is matched to a live page before release, and every link in them is opened to make sure it works. If there is no source, the line is not written.
Why a checklist, not good intentions
Each item is cheap on launch day and expensive later. Writing them down turns "we usually do this" into a gate that stops a release. It is the same list for every project.
- Dependencies patchednpm audit --omit=dev → 0 known issues Rule 1
- Service isolatedown user · memory cap · read-only system Rule 2
- Inputs validated on the serverschema · rate limit · spam check Rule 5
- Funnel counted server-sideview → CTA → submit → error + reason Rule 14
- No personal data in analyticspaths reduced to patterns Rule 11
- Mobile Lighthouse target 95+performance · accessibility · SEO Target
- AI-facing facts verifiedevery llms.txt line matched to a live page Rule 12
Start here
Want your next launch to pass all seven?
A short form is enough. You get a written scope with a date, free, whether or not you go ahead.