Dom1ng0s SaaS / Multi-User App Audit
This skill turns an existing codebase into a prioritized, evidence-based action plan. It looks at two things side by side, because in a multi-tenant SaaS they're tightly coupled — a missing rate limiter is both a security hole and a scalability gap, a missing tenant-scoping check is both a breach risk and a feature gap:
- Security & architecture breaches — things that are actively dangerous or will break under real usage
- Missing features for a scalable multi-user product — things a mature SaaS needs that this codebase doesn't have yet
Producing a good report here depends on grounding every claim in something you actually found in the code — file paths, function names, config values. A generic "add rate limiting" bullet is nearly useless to a developer; "no rate limiting found on /api/* routes in src/routes/api.ts — any endpoint can be hit unbounded" is actionable. Resist the temptation to pattern-match from experience with "typical SaaS problems" without verifying against this specific codebase.
Workflow
Step 1: Map the codebase before judging it
Don't start checking boxes against a checklist immediately — first understand what you're looking at:
- Identify the stack (language, framework, ORM/database, auth library, deployment target). Look at
package.json/requirements.txt/Gemfile/etc., config files, and the top-level directory structure. - Identify how "tenant"/"user" boundaries are modeled — is this single-tenant-per-deploy, row-level multi-tenancy (a
tenant_id/org_idcolumn), or schema-per-tenant? This shapes almost every finding downstream, since a missing-isolation bug looks different in each model. - Note the app's apparent maturity/stage (early prototype vs. has paying users) if it's discoverable from the code (migrations history, test coverage, CI config, changelog). This affects how you prioritize — an early prototype forgives things a live product can't.
If the codebase is large, don't try to read every file. Prioritize: auth/session code, API route definitions, database models/migrations, middleware, and anything under admin/, billing/, or webhooks/. These are where multi-tenant bugs concentrate.
Step 2: Run the security & architecture pass
Read references/security-checklist.md and go through it against what you found in Step 1. For each item, record either a finding (with file/line evidence) or confirm it's handled (briefly note how). Don't skip items just because they seem unlikely — tenant isolation bugs in particular are usually invisible until you check the actual query code.
Step 3: Run the feature-completeness pass
Read references/saas-feature-checklist.md and assess what's present vs. missing for a scalable multi-user product. Same rule: cite what you found (or didn't find) rather than assuming based on the framework's defaults.
Step 4: Synthesize into the action plan
Read references/report-template.md for the exact structure to follow. Key principles for a good synthesis:
- Severity and effort, not just a flat list. A developer reading this needs to know what to do Monday morning vs. what can wait a quarter.
- Merge overlapping findings. If "no rate limiting" shows up in both the security pass and the scalability section of the feature pass, it's one finding with two angles, not two line items.
- Be honest about what you couldn't verify. If you didn't have visibility into the deployment/infra config, say so rather than guessing at how it behaves in production.
- Keep the executive summary short enough that someone would actually read it — 3-5 sentences, not a restatement of every finding.
Write the final report as a Markdown file (not just inline chat text — this is a deliverable the user will want to keep, share with a team, or turn into tickets). Save it to the outputs directory and present it to the user.
When the codebase isn't available
If the user describes their app but hasn't shared code (no files uploaded, no repo access), don't fabricate findings. Say so, and offer either to do a lighter-weight conceptual review based on what they describe, or ask them to share the codebase/repo for a grounded audit. A findings list built on assumption instead of evidence undermines the whole point of this skill.