Launch checklist

Publishing takes one click. Launching, telling people the link and meaning it, deserves an hour of checks first. This is the pre-launch pass we recommend for any app that is about to meet strangers, in the order that catches problems soonest.

1. Walk it as a stranger

Open the published app in a private browser window, signed out, on your phone.

• Does the first screen say what the app is, or does it assume the visitor already knows?
• Sign up as a brand-new user and do the one thing the app is for. Any step that confuses you will lose a stranger twice as fast.
• If something works in preview but not on the published app, publish again and re-check; only published code is live.

2. Prove the privacy boundary

If your app has sign-in, run the two-account test before strangers hold accounts: create two users, add data as one, and confirm the other cannot see it. The recipe is in How data privacy works. This is the single highest-value check on this page.

While you are in the auth settings, confirm the two access decisions are what you intend:

• Who can register: open to anyone, or invite-only. See Add sign-in.
• Whether viewing requires sign-in at all: the strict wall, in Public vs private apps.

3. Dress the link

Most people meet your app as a link card in a chat or feed before they meet the app itself.

• In Vault → SEO, set the share title, description, and image, and check the per-platform previews. Design and branding covers this panel.
• Set a real app name and logo; they carry into the sign-in portal your users see.
• On a paid plan, connect your own domain. A custom domain is the strongest single trust signal a small app can buy.

4. Put a floor under the costs

If the app uses connectors that spend real money on your keys, AI features especially, set the owner spend quota before launch, not after the first surprise. Connector limits and scope explains the guardrails; AI features in your app has the cost walkthrough.

5. Say what you collect

Publish a privacy page. The privacy-policy starter gives you honest clauses for what a Vaulter app actually collects; delete what does not apply and link the page from your footer.

6. Turn the dials for being found

• SEO plumbing is automatic, but check that the app is set to be indexable if you want search traffic, and read the SEO content guide for the half only you can do.
• Google auto-indexing gets your sitemap submitted without waiting to be crawled.
• Know your baseline: open Analytics on launch day so week-one numbers have something to compare against. Analytics collects on paid plans.

7. Launch, then watch the first day

Share the link where your first users actually are. Then, the same day:

• Watch analytics for where visitors drop off; the first fix is usually the first screen.
• Try to break your own signup once more; launch traffic finds edge cases private testing missed.
• Keep the build workspace open. Small fixes publish in seconds, and shipping a fix an hour after a user hits a bug is a better first impression than never having bugs.

Frequently asked

Do I need everything on this list?

No. An app for five colleagues needs steps 1 and 2 and nothing else. The further down the list you go, the more it is about strangers at scale.

What about a "beta" period?

Invite-only registration is a built-in beta switch: launch with the allowlist on, invite your first users by email, and open registration when you trust the app. No code changes either way.

Something broke right after launch. What is the fastest path?

The troubleshooting triage tells you in 90 seconds whether it is the app, your change, or the platform, and undo gets you back to the last good version while you diagnose.