Self-serve invoicing is a smart wedge — making the customer do the data entry removes the worst part of billing. And the auth foundation here is done right: Clerk running as a proper production instance (live keys, dedicated clerk.trybillhog.com domain), which is rarer than it should be in launch cohorts. The rest of the basics hold too: HSTS two-year with includeSubDomains, X-Frame-Options DENY, nosniff, strict-origin-when-cross-origin, robots.txt sensibly fencing off /i/, /dashboard and /api/ while the sitemap stays clean, ~250ms TTFB.

Passive launch-day check (headers + public HTML only), two findings:

1. There is no Content-Security-Policy anywhere — not on the landing, not on /pricing, not even on the 404 page. For a product whose whole job is rendering customer-facing invoice pages (the /i/ routes you've disallowed in robots.txt), that's the one header I'd want most: invoice views mix your markup with arbitrary customer-supplied data (names, line items, notes), which is exactly the XSS surface CSP exists to contain. A starter policy (default-src 'self') is a one-line header on Vercel and can go out in Report-Only first if you want to watch violations before enforcing.

2. Permissions-Policy is missing — the other standard one-liner. An invoicing app never needs camera, microphone or geolocation; locking them off (camera=(), microphone=(), geolocation=()) costs nothing and removes a whole class of "why is the browser asking for that" support tickets.

Minor observation: every route, landing included, responds with access-control-allow-origin: *. Harmless on static pages with no credentials involved, but it's the kind of global header that quietly lands on API routes later — worth scoping before /api/ grows.

Happy to re-check free of charge once a CSP ships — the rest of the header set is already solid, so this is the gap that stands out.