Launch checklist
Use this before you invite real customers or point a custom domain at a project.Product shape
- Core jobs work as screens and forms, not only as chat
- Navigation matches each role (groups, breadcrumbs, no dead links)
- Seed data is demo-only; you are ready for real project data
- Important decisions are captured under App Blueprint → Documentation when they matter later
- Near-term outcomes you have committed to sit on Roadmap in the sidebar (not only on Signals)
Access and safety
- Roles exist for every audience; owner/admin are not your only customer roles
- App Blueprint → Access findings reviewed for each customer role
- Preview as each role on the critical paths
- Sensitive actions require the right roles (and approval if needed)
- Secrets live in Environment Variables, not chat history
- Outbound network allowlist set if you need a tight egress policy
Automations and integrations
- Scheduled automations tested; check project Executions
- Follow-ups after events are safe to retry
- OAuth connections reconnect after scope changes
- Inbound routes use a bearer token or signed webhook (no open secrets)
- Notifications go to the right channel and link to the right page
Customers and portal
- Invite or registration path chosen (Project vs App Registration)
- Portal copy and branding acceptable under App Settings (and Project Settings → Branding if a project needs its own logo or colors)
- Custom domain verified if you need one (Custom domains)
- For regulated health data, HIPAA/BAA path confirmed with support first
Quality and rollback
- Critical chat flows covered by Evals if the agent is load-bearing
- You know how to open Versions and roll back the blueprint
- Someone on the team can read Signals after launch
- After the first real week, someone looks at project Usage (not Credit Usage) to see which screens and jobs were actually used
Credits
- You have looked at Credit Usage for Build vs Chat on this app
- Build Rules discourage expensive rebuild loops (Controlling credits)