What launch ready means here
The About page's contact cards, the site-wide Organization JSON-LD, and the header's fallback email all pointed at hello@beemmeup.dev, a domain with no DNS record at all.
A read-only SEO and accessibility audit, run on 23 September against all 52 app/**/page.tsx routes plus lib/seo/*, middleware.ts and next.config.ts, is what caught it. mcp-catalog.ts already had a comment noting that domain "never existed." The fix, the same day, switched everything to hello@/bugs@beemmeup.io (BMU-379). The PR is explicit that this isn't fully resolved: beemmeup.io itself has no MX record either, so the new addresses bounce until inbound mail is set up. That one is on me, and it's on the launch checklist.
Two more findings came from checking the deployed site rather than just reading the source. Every "Authorize" button on the public /mcp marketing page links to /mcp/authorize?client=<id>, but the real consent screen needs client_id plus PKCE parameters. The link can't be valid for any client. Fixed by deleting the buttons rather than wiring real OAuth into a marketing page (BMU-369). And the apex domain, beemmeup.io, redirects to www with a 307, a temporary redirect, not a 301 or 308: curl -sI https://beemmeup.io/ confirms it. Search engines can keep treating the apex as canonical and split ranking signals between the two hosts. That one's a Vercel domain setting, also mine to change.
Zero blockers, a short list of everything else
Code review found 1 major and 8 minor findings. None of them breaks anything today, and all of them should be fixed before launch. Preview deployments had no noindex gate at all, so a Vercel preview URL shared in a Slack link or a PR comment would index as ordinary duplicate content. /upload-demo, an internal upload-comparison page linked from nowhere, was set index: true and sitting in the live sitemap. Neither one tripped the audit's actual blocker bar, which is the one combination that would have been a real leak: a route with index: true and an auth gate at the same time. Zero routes matched it.
Local production-build Lighthouse runs, taken while a browser QA pass ran on the same machine so mobile numbers read pessimistic: SEO 100 on every public page, accessibility 94-98, CLS 0 everywhere. Two accessibility failures repeat across every marketing page: no <main> landmark, and low-contrast small labels sitting around oklch(1 0 0 / .34-.45).
Four decisions, none of them started
The same day, four ADRs went in: Supabase Auth hardening, Resend, Sentry, and Stripe. All four dated 23 September. All four status Proposed. Every action item in all four is an unchecked box.
The Stripe ADR opens with this: "The product already has a price. It just can't be paid yet." /pricing is real: Free, and Pro at $12.99 a month or $129 a year. Account → Billing is real too, in the sense that it renders: the plan is hard-coded to 'free', the invoices are fake, every button on the page is disabled. No Stripe SDK, no keys, no schema, anywhere in the repo. What's decided but not yet built is a direct Stripe account rather than the Vercel Marketplace route, hosted Checkout and Customer Portal, and webhooks as the only writer of subscription state, since every event re-fetches the Subscription object instead of trusting what the payload says.
The Sentry ADR describes a repo with no error monitoring at all, about 100 raw console.error calls spread across roughly 50 files, no source maps, and, until a same-day fix closed the gap, no error.tsx. The Resend ADR is the one that connects back to the contact-email bug: the app sends no email of its own, and the domain split between beemmeup.io and the nonexistent beemmeup.dev is the kind of drift an owned mail sender should stop.
Ten action items sit under the Stripe ADR alone. The first one is mine: activate Stripe, create sandboxes, decide on tax and payment methods. Nothing under it is checked yet.