Five things, before you launch.

Five tags cover Facebook, WhatsApp, iMessage, Slack, LinkedIn, Discord and X. They are og:title, og:description, og:image, og:type, and twitter:card set to summary_large_image so X uses the full-width layout. Watch the attribute split: og tags use property=, twitter tags use name=. They must appear in the server-rendered head, because scrapers do not run JavaScript. The exact block is in the steals below.

One 1200×630 image, served from an absolute https URL that opens in an incognito tab with no auth in the way. Design it for thumbnail size. One short line of large text, high contrast, subject centred. WhatsApp and iMessage often crop it to a small square, so keep nothing important near the edges. JPG or PNG under about 300KB. WhatsApp silently drops images over 600KB and does not render SVG. Zoom your browser to 25% and check you can still read it.

Export metadata from app/layout.tsx for the site-wide default, then override per page. Set metadataBase once in the root layout. It is what turns a relative image path into an absolute production URL. On current Next.js, forgetting it fails the build loudly. On older versions it silently resolved images against the deployment URL, which is how previews work locally and die when shared.

Drop a 1200×630 file named opengraph-image.png into app/. Next.js emits the og:image tags with a correct absolute URL, plus alt text from opengraph-image.alt.txt beside it. Two catches the docs bury. The static convention takes jpg, jpeg, png or gif only, never WebP. And it does not emit twitter:image. Either add a twitter-image file too, or leave it out and X falls back to og:image while your twitter:card export still controls the layout.

Every platform scrapes once and caches the card against the exact URL string. Slack holds it for half an hour to a few hours, so delete the message and repost. WhatsApp holds it for days to weeks with no official flush. iMessage renders on the sender's device at send time, and bubbles already sent never update. The universal escape is a throwaway query string. yourdomain.com/?v=2 is a new exact URL, so everything scrapes it fresh. Facebook and Messenger have the Sharing Debugger's Scrape Again button. LinkedIn has the Post Inspector.

Domains attach to projects, so the split starts with two projects even if both live in one repo. The marketing project gets example.com and www.example.com. The app project gets app.example.com. Settings → Domains → Add Domain in each. Custom domains work on the free Hobby plan.

At your registrar, add one CNAME. Name is app, value is copied from the Vercel domain card. Copy the card, not a tutorial. Vercel now issues per-project targets like d1d4fc829fe7bc7c.vercel-dns-017.com. The old shared cname.vercel-dns.com still resolves, but verification checks for the exact value your card shows. TLS is provisioned automatically once it propagates. This one record is the entire separation.

The DNS spec forbids CNAMEs on an apex, so example.com gets an A record. Most projects show 76.76.21.21. Newer ones draw from an anycast pool and may show a different IP, so again: copy the card. www is an ordinary CNAME, like the app subdomain.

In the marketing project, set the secondary domain to redirect to the primary with a permanent 308. Vercel's dropdown does it. Then forward the app paths people will inevitably type on the wrong domain. /login and /app/* on the marketing site should land on app.example.com. Two lines of next.config, in the steals.

Auth cookies are host-scoped. The sb-…-auth-token cookie Supabase sets on example.com is never sent to app.example.com. So moving the app after launch force-logs-out every user you have. You would also rewrite Supabase's Site URL and every Redirect URL, while magic-link emails already sitting in inboxes still point at the old host. Search engines treat the subdomain as a separate site, so months of indexed app routes become 301s you maintain forever. Before launch, all of that is one CNAME.

Finish this sentence before touching any UI copy. A user has gotten the point of this app the moment they ___. That moment is your activation event. The one first action is the smallest visible step that causes it. The first screen exists to cause that action and nothing else. Every other card, nav item and settings link is a competitor. If you cannot name a single action, that is a positioning problem, and no amount of UI fixes it.

A brand-new account sees empty screens. So the empty state is your onboarding whether you wrote it or not, and “No items yet” is an onboarding screen that teaches nothing. Give it three lines: what this screen becomes, the one action as an imperative button, and an escape hatch for people not ready to commit real data. The button repeats the exact promise your landing page made, in the same words.

For a run-something-on-my-thing tool, the input field is the app. Put it above the fold. The headline does the instructing, the field is autofocused, and the placeholder is a realistic example. Never the word URL. Fire activation when the report renders, not when the button is clicked, because a crawl that errored is not an activated user.

A booking or chat product only feels real when the owner experiences it from their customer's side. The empty inbox shows their new number and tells them to text it from their own phone. The assistant's reply landing on their personal mobile is the magic moment, and it doubles as an end-to-end test of their telephony wiring. Activation is the reply. Not the signup, not the number provisioning.

Never render an empty dashboard as blank panels. Use grey ghost charts, so they see the shape of what they are buying. Put one connect button centred over them with a time estimate on it. Sample data is the escape hatch, behind a link. Activation is not the OAuth callback. It is the first render containing their real data.

Tours teach where buttons are. The single action delivers the thing the buttons exist for. The industry's own benchmark data shows barely six in ten started tours even get finished, which measures patience, not activation. Instrument two things in PostHog. The activation event, fired server-side where the value is delivered. And a signup-to-activation funnel, so the drop-off is visible. On serverless, flush before the function exits or the event dies with it.

Sign up, pick your region, grab the project token, npm install posthog-js. The current App Router pattern is an instrumentation-client.ts file in the project root. If your app uses a src directory it must live there instead, or it is silently ignored. No provider component, no wrapper. Next.js runs it before hydration. Call identify after login so replays have names, and reset on logout. Add the env vars to Vercel too, then redeploy, because NEXT_PUBLIC values bake in at build time.

Recording stays off until you enable it in the PostHog app: Settings → Session replay → Record user sessions. SDK config alone does nothing. The defaults protect inputs. Every input is masked before it leaves the browser, so emails, passwords and card fields never reach PostHog. Text that your app renders on screen is not masked by default. If the screen shows sensitive data, health or finance, mask all text or put ph-no-capture on the element and it renders as a black box.

You choose the region at signup and it sticks. Moving later is a support ticket, not a toggle. Same product and free tier either way. The only code difference is the host URL. If your users are mostly European, or you want data-stays-in-the-EU as a one-line GDPR answer, pick Frankfurt now.

PostHog sets a first-party cookie by default. For an AU or US audience no law forces a banner for that. Disclose analytics in the privacy policy and move on. For EU and UK visitors you need consent, or no storage at all. Cookieless mode set to always never touches storage and counts uniques with a daily server-side hash, so no banner is needed. But session replay does not work without storage consent, full stop. The honest EU combination is a banner with cookieless on_reject. Nothing at all is captured while the banner sits unanswered, because pre-consent events are dropped rather than queued. Then full tracking from the moment they accept, and hash-counting if they decline.

After launch, open Session replay daily until you have watched ten real strangers. Sampling comes later. Use the built-in frustration filter, turn on skip-inactivity, run at 2×. Look for three things. Rage clicks, meaning three clicks inside a second in the same spot, flagged automatically on the timeline. Dead ends, where they bounce between the same two screens. And the stall, the long motionless pause on a form or pricing page right before the tab closes. Fix the single worst stall before you fix anything else.

A default-exported function returning MetadataRoute.Sitemap, served automatically at /sitemap.xml. Make it async if it needs to pull blog slugs from the database, because it runs at build time by default. Only url is required per entry. Set lastModified when it is real, and skip changeFrequency and priority entirely, because Google ignores both.

List only what a logged-out stranger should see: landing, pricing, blog, legal. Never /dashboard, /admin, /app, /login, /api. The sitemap is a public file, so listing private routes publishes a map of your app's internal surface. Googlebot also crawls what you list, so login redirects become junk results under your brand. If a “protected” page only checks auth client-side, a common bug in AI-generated code, the sitemap fast-tracks it straight into the index. If something private does get indexed, the Removals tool hides it from results within about a day for six months, which buys the time to fix the actual auth.

Same convention, served at /robots.txt. It has two jobs. Point crawlers at the sitemap with its absolute URL, and keep them off private paths. Never Disallow a path that appears in the sitemap, because those are contradictory signals. And remember robots.txt is a request, not security. A blocked URL can still appear in results as a bare title if anything links to it. Pages that must stay out of Google need noindex. Pages that must stay private need server-side auth.

Add a Domain property, the left option. One verification covers www and every subdomain. Google hands you a TXT record, and it goes wherever your DNS actually lives, which for most setups is the registrar. Only add it in Vercel if your domain genuinely uses Vercel's nameservers. Connecting a domain with A and CNAME records leaves DNS at the registrar, and a TXT added in the wrong place verifies nothing. Propagation is usually minutes, and the dialog lets you retry without losing anything.

Sitemaps → paste sitemap.xml → Submit. A “Couldn't fetch” shown immediately after submission usually means Google has not fetched it yet, so wait a day before debugging. Genuine failures are 404s, server errors or robots blocks, and a malformed file shows a parse error instead. Success means the XML parsed and the URLs are queued. It does not mean indexed. A brand-new domain takes one to three weeks to index meaningfully, and “Discovered, currently not indexed” is normal early. A sitemap earns zero rankings. It just guarantees Google knows the pages exist.