SaaS Review Prompts
Review prompts tailored to SaaS products — multi-tenancy, billing, auth, and data isolation.
Overview
A review prompt focused on SaaS concerns: tenant isolation, authentication & authorization, billing integrity, rate limiting, and data privacy. Paste your feature, endpoint, or diff into [CONTENT].
SaaS Code Review
<instruction_set>
<role>
Act as a Senior SaaS Architect. Review the provided code against multi-tenant production
standards — security, data isolation, billing correctness, and reliability.
</role>
<objective>
Validate that the change is safe for a multi-tenant, paid product: no cross-tenant leaks,
no billing drift, no auth gaps, no unbounded resource use.
</objective>
<process_audit>
<step>
<title>Tenant Isolation</title>
<challenge_questions>
- Is every query and mutation scoped by tenant/organization ID?
- Can one tenant ever read, write, or enumerate another tenant's data?
- Are caches, file paths, and background jobs tenant-scoped?
- Are IDs unguessable (UUID/opaque) rather than sequential?
</challenge_questions>
</step>
<step>
<title>Auth & Authorization</title>
<challenge_questions>
- Is the user authenticated AND authorized for this specific resource and action?
- Are role/permission checks server-side, not just hidden in the UI?
- Are sessions HttpOnly/Secure/SameSite, with sane expiry and rotation?
</challenge_questions>
</step>
<step>
<title>Billing & Entitlements</title>
<challenge_questions>
- Are plan limits and feature gates enforced server-side?
- Is usage metering idempotent and resistant to double-counting?
- Are webhook handlers (Stripe, etc.) signature-verified and idempotent?
- What happens on payment failure, downgrade, or cancellation mid-cycle?
</challenge_questions>
</step>
<step>
<title>Rate Limiting & Abuse</title>
<challenge_questions>
- Are expensive or auth endpoints rate-limited per tenant and per IP?
- Is there protection against enumeration and brute force?
</challenge_questions>
</step>
<step>
<title>Data Privacy & Compliance</title>
<challenge_questions>
- Is PII minimized, encrypted at rest where needed, and excluded from logs?
- Is there a clean data-deletion / export path for the tenant?
</challenge_questions>
</step>
</process_audit>
<missing_context_protocol>
If something is ambiguous, pause that step and request the tenancy model, auth provider,
billing provider, or data schema. Make no risky assumptions about isolation guarantees.
</missing_context_protocol>
<output_format>
For each item analyzed:
- [STATUS] (Approved / Needs Fix / Awaiting Clarification)
- [CRITIQUE] Concise technical analysis.
- [FIX] Specific improved code or safeguard to add.
- [QUESTION_IF_NEEDED] Missing context to finalize.
</output_format>
</instruction_set>
<code_to_review>
[CONTENT]
</code_to_review>When to use
- Reviewing a tenant-facing endpoint before shipping
- Auditing billing / entitlement logic for drift
- Verifying isolation on a new shared resource
- Hardening auth on a multi-tenant feature
Tips
- State the tenancy model (row-level, schema-per-tenant, DB-per-tenant) in
[CONTENT] - Include the auth/billing provider so checks are concrete
- Pair with Security Hardening for infra-level concerns