The seven pillars

The seven pillars are the founder-facing rollup of every check PulseLight runs. Internally, the scanner has rule packs and scanner sources; externally, every finding rolls into one of these seven pillars. The pillars are the only mental model a founder needs.

Each pillar exists in one of five states on a given scan: Ready (no actionable findings), Needs work (warnings only), Blocked (at least one launch blocker), Not applicable (your project profile says this doesn’t apply — e.g. Billable on a non-charging app), or Not checked (no scan, or new pillar pre-rollout).

• Secure

  Is customer and product data protected?

  Auth checks, secrets, tenant isolation, exposed routes, unsafe config.

• Stable

  Will the app survive real users?

  Health endpoints, error monitoring, rollback, deploy safety, env separation.

• Billable

  Can we safely charge customers?

  Stripe webhook verification, server-side entitlements, cancellation, refunds.

• Measurable

  Can we see what users are doing?

  Analytics installed, signup, activation, conversion events, attribution.

• Usable

  Can users reach value quickly?

  Onboarding, empty states, demo data, support route, lifecycle email.

• Scalable

  Can usage grow without breaking cost or performance?

  CVEs, lockfile, rate limits, AI token spend, DB hotspots, bundle size.

• Trustworthy

  Does the product look legitimate and safe to customers?

  Privacy policy, terms, account / data deletion, AI disclosure, contact.

Stage relevance

Some pillars matter more at different launch stages. Scalable checks — CVE risk, AI token spend, DB hotspots — are only foregrounded once you have users. Pre-launch projects see Scalable issues in the “Later” bucket, not as blockers. The full stage-aware logic lives in the readiness registry; surface-level: PulseLight hides what doesn’t matter yet.