Quick start
Set up a workspace, connect launch-critical providers, and run the first real pre-flight check.
Getting started
Quick start
Ship a real launch baseline in under fifteen minutes. This guide walks from an empty workspace to a stored check run, active watchdogs, and an optional deploy gate — using the same flows your production stack will depend on.
PreFlight is most valuable when it checks the same credentials, callback URLs, and health endpoints your launch will use. Use staging keys first, then repeat with production credentials before you open signups.
Before you begin
- A deployable SaaS app with a public health or webhook URL
- Admin access to the providers that can block launch (Stripe, auth, email, deployment)
- A workspace owner account on PreFlight
Step-by-step
Create a workspace and project. Sign up, create a workspace, then add a project for the app you are launching. One project equals one deployable surface with its own URL and credentials.
Save your public URLs. Add the health endpoint and webhook route your production stack exposes. The readiness scanner only probes the URL saved on the project — never unrelated domains.
Connect launch-critical providers. Start with Stripe, Supabase (or Clerk/Firebase), and one delivery channel (Resend, Postmark, SendGrid, Twilio, Slack, or Discord). See the integration references for required fields per provider.
Run your first full check. Open Checks → Run pre-flight. Review pass, warning, and failed probes separately. Disconnected providers appear as skipped so the run is easy to explain to the team.
Fix blockers with runbooks. Failed probes link to deterministic runbooks with verification steps. Warnings deserve a human review before launch even when the deploy gate is in relaxed mode.
Enable watchdogs for the release window. Turn on 24-hour Monitoring for launch week, Sentinel for always-on sampling, Vercel Watch if you deploy on Vercel, and Revenue Watch when Stripe checkout must match Supabase side effects.
Arm a deploy gate. When CI or Vercel should block unhealthy releases, configure Deploy Gates and wire
GET /api/v1/projects/:id/deploy-gateinto your pipeline.
What PreFlight stores
| Category | Examples | Never stored |
|---|---|---|
| Project metadata | Name, health URL, webhook URL, environment labels | Customer PII from your app |
| Credentials | Encrypted provider bundles per integration | Raw keys after save (only hashes + prefixes for API keys) |
| Evidence | Check runs, Sentinel samples, incidents, activity log | Full webhook payloads with secrets |
| Automation | Deploy-gate policies, Sentinel cadence, alert routing | Fabricated or demo telemetry |
Empty states stay honest
Exports, Trust Center pages, and dashboard charts reflect stored rows only. If a module has no data yet, the UI stays empty instead of showing placeholder metrics.
Recommended first-run stack
For most indie SaaS launches, connect these providers before your first check:
| Priority | Provider | Why |
|---|---|---|
| 1 | Stripe | Payments, webhooks, and checkout side effects fail silently at launch. |
| 2 | Supabase or Clerk | Auth callbacks and database guardrails block signups. |
| 3 | Resend or Postmark | Transactional email proves alert routing works. |
| 4 | Vercel | Deployment and domain drift surface after the first promote. |
| 5 | Sentry | Error reporting confirms observability is wired. |
After the baseline
- Run a Stripe shadow checkout to validate the full money path.
- Publish a Trust Center report when customers or investors ask for evidence.
- Create an API key and connect the MCP server so agents can re-run checks from your IDE.