What do I need before launching an app built with AI?

Is the domain and DNS done?

Done means the apex and www both answer over https with a valid certificate, plain http redirects, the registration has auto-renew on with more than 30 days left, and the nameservers are the ones you expect. Check each from outside with one request; the builder cannot see any of it.

The builder deploys to its own subdomain and stops. Attaching your domain is DNS work at the registrar and the host, and it is where launch day breaks: a CNAME on the apex that the registrar refuses, www pointed at the host and the apex at nothing, a certificate that never issues because a stale record is still in the way. From outside, the checks are tls-valid, https-redirect, hsts, nameservers and domain-expiry, which reads the expiry from the registry's RDAP service and fails under 30 days.

Expiry is the cheapest outage there is. The site, the mail and every login stop at once, and the people who could tell you are the ones who can no longer reach you. Turn auto-renew on the day you buy the domain, with a card that outlives the next renewal. Then prove the whole chain with single requests, never a loop:

curl -sI http://YOUR_DOMAIN | head -1            # 301 or 308 to https
curl -sI https://YOUR_DOMAIN | grep -i '^strict'   # the HSTS header
curl -sI https://www.YOUR_DOMAIN | head -1         # 200 or a redirect to the apex

Will my sign-in and receipt emails arrive?

Only if the domain they send from has SPF, DKIM and DMARC. That is the domain your auth provider or email service actually uses, not the one on your business card. Google and Yahoo have required authentication on every sender since February 2024; an unauthenticated magic link lands in spam and nobody can log in.

Google's bulk sender requirements say every sender must set up SPF or DKIM, and anyone sending 5,000 or more messages a day to Gmail must have both plus DMARC. Receivers apply the same reasoning to a brand-new domain sending sign-in codes. Supabase's built-in email sends from a supabase.io address at 2 messages per hour and is documented as for demonstration only; production means custom SMTP from your own domain.

The checks are spf (exactly one record; two equals none), dkim, dmarc (a policy of quarantine or reject and a reporting address, not p=none) and auth-sender-authenticated, which works out the sending domain from the DKIM selectors on your domain and judges that domain. The magic-link guide has the records and the order to add them. Finish with one real send: request a password reset for your own address and read the headers for SPF: PASS, DKIM: PASS, DMARC: PASS.

Are payments wired for the live domain?

Wired means the page ships a pk_live key, the server holds the matching sk_live key with no trailing newline, and a webhook endpoint exists for the production domain in live mode, enabled, subscribed to the events your handler reads. Payments can succeed without the webhook; your app just never hears about them.

Stripe keeps sandbox and live mode entirely apart: each mode has its own set of API keys, and objects in one mode aren't accessible to the other. A test key in production means test cards succeed and real cards are refused, with the page looking finished. stripe-test-key-in-prod reads the publishable key from your bundle and fails a pk_test_ on a production domain; the same key on a preview subdomain only warns.

The webhook is the other half, and the half that fails quietly. It is registered per mode and per URL, and the signing secret differs between modes, so an endpoint created against the preview URL in sandbox mode delivers nothing to the live domain. stripe-webhook-wiring runs on your own machine with your own secret key and reports whether an enabled endpoint exists for the live domain, in the right mode, subscribed to the checkout and payment events. The Stripe guide covers the switch step by step. Then buy the smallest plan with your own card and refund it; the card fee is the cost of knowing.

Is anything measuring the launch?

Not unless a tag is on every page and the events you care about arrive. Check that the home page loads GA4, Plausible, PostHog, Fathom or an equivalent, then do the action and look for the event in the browser console. Analytics installed is not analytics working; one misordered script drops every event silently.

analytics-present looks for a known loader on the home page: a G- measurement id, the gtag loader, or a Plausible, PostHog or Fathom script. That is the floor. The failure that costs money is the tag that loads after the component that fires the event, so the guard drops it and nothing arrives, which is why the Fix Kit refuses to start paid traffic until measurement is proven in the browser: window.dataLayer must contain your event after the action. If your site targets regions that require it, consent-mechanism looks for the control. Add og-image, title, meta-description, robots-txt and sitemap here too, because the launch post is the first time anyone shares the link and the preview card is what they see.

Do missing pages, privacy and terms work?

A random path on your domain must answer HTTP 404 with your own page, not 200 with the home page, and the home page must link to a privacy policy and terms that both load. The first keeps search engines from indexing every typo; the second is what Stripe, app stores and ad platforms ask for.

The soft 404 is the most common builder leftover: a catch-all rewrite sends every path to index.html, so every mistyped URL becomes a page in the index and broken-link reports stay empty forever. not-found-page requests a path that cannot exist and reads the status. The fix is a real 404.html at the root of the output, or app/not-found.tsx on Next.js, and removing the rewrite that answers first. legal-pages fetches the home page, finds the privacy and terms links by text and href, and requires 200 from each; supply the legal text yourself, because no tool should invent it. ai-leftovers catches the rest: placeholder copy, dev-server hints, builder badges and chat residue still in the HTML.

None of these is a security finding, and all of them are what a customer sees first. The grade reads them together with the security classes because they fail together, on the same day, at the seams between the builder, the host, the registrar, the email service and the payment provider. Each vendor checks its own box. The grade is the one place all of them are read at once, and it works on the preview URL before the domain is attached.