Your first week with PreFlight
Set up an app, run the right audit, connect the real customer path, and create a release baseline.
PreFlight is an operating system for the moments that decide whether a SaaS is safe to ship: the release, the customer journey, the payment, and the production hours that follow. This tutorial gives you a practical first week, not a tour of settings. You will begin with an outside-in audit, connect only the services on your real customer path, then create evidence you can act on.
Create an app around a real customer path
From Apps, add the production URL and name the application as your customers know it. Choose one critical path to protect first: signup, checkout, an authenticated dashboard request, or another action that must work every day. A focused path makes your first audit useful; you can add more services and journeys later.
Do not start by pasting every credential you own. PreFlight lets you connect providers progressively, so the evidence stays tied to the behavior you actually want to verify.
Run the full audit
Open Audit and run a full scan against the public app. It evaluates the web surface, performance, accessibility, security, domain and email signals, then ranks findings by impact. Treat the first result as a baseline, not a grade you must immediately perfect.
Open the highest-impact finding first. The audit gives you the evidence, a recommended correction, and a copy-ready fix prompt that can move directly into your coding workflow.
Connect the services that make the path work
Use Connections for Stripe, Supabase, Vercel, authentication, email, alert channels, and the rest of the stack. Each provider has a purpose-built health check rather than a generic ping. Credentials are stored server-side and used only to verify the configured path.
After connecting a provider, run its probe once. A green result means PreFlight reached the expected service and captured evidence; it does not replace your own permissions review.
Turn the baseline into a release ritual
Before a meaningful deployment, revisit Audit and then move to Deploy. Add GitHub checks for pull-request evidence, create a Journey Canary for the path a user actually takes, and configure monitoring after release. The dashboard will retain the sequence—scan, change, deploy, verification—so you can prove why a release was accepted.