Saas Scaffolder
Choose a multi-tenancy and SaaS architecture pattern before you commit schema, billing, and infra costs.
Overview
SaaS Scaffolder is an agent skill most often used in Validate (also Build, Validate pricing) that compares multi-tenancy and SaaS architecture patterns with explicit trade-offs.
Install
npx skills add https://github.com/alirezarezvani/claude-skills --skill saas-scaffolderWhat is this skill?
- Documents three multi-tenancy models: shared database (tenant_id), schema-per-tenant, and database-per-tenant
- Each pattern lists pros, cons, and decision criteria for early-stage versus enterprise isolation needs
- Covers noisy-neighbor risk, data residency, migration complexity, and operational cost
- Positions shared schema for SMB and speed; stronger isolation models for mid-market and regulated tenants
- Reference-oriented architecture guidance rather than a single codegen template
- 3 multi-tenancy models documented (shared DB, schema-per-tenant, database-per-tenant)
Adoption & trust: 534 installs on skills.sh; 17.5k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are building a SaaS but do not know whether shared tables, schemas, or separate databases fit your customers, budget, and compliance needs.
Who is it for?
First SaaS backends where tenant isolation, migration strategy, and infra cost must be decided before schema and auth models harden.
Skip if: Single-tenant internal tools with no multi-customer data boundary, or teams that already have a fixed enterprise isolation standard documented.
When should I use this skill?
When defining SaaS architecture, tenancy isolation, or early backend structure for a multi-customer product.
What do I get? / Deliverables
You leave with a defensible tenancy and architecture choice aligned to stage, isolation, and ops complexity before implementation deepens.
- Recommended multi-tenancy model with trade-off rationale
- Notes on migration, backup, and operational implications per pattern
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Tenancy and isolation decisions are canonical on Validate scope because they lock cost, compliance, and roadmap before heavy Build work. Scope is where you compare shared-schema, schema-per-tenant, and database-per-tenant trade-offs against customer segment and team size.
Where it fits
Compare shared-schema tenancy versus schema-per-tenant before writing the first production migrations.
Align connection pooling and migration jobs with the chosen tenancy model during API and auth design.
Map enterprise tier promises (dedicated DB, residency) to database-per-tenant or stronger isolation patterns.
How it compares
Architecture decision reference for tenancy models—not a full-stack repo generator or infrastructure provisioning skill.
Common Questions / FAQ
Who is saas-scaffolder for?
Solo builders and small teams designing B2B SaaS who need a clear multi-tenancy comparison before backend and billing work.
When should I use saas-scaffolder?
In Validate scope when picking an MVP tenancy model, in Build backend when refining schema and connections, and when pricing tier design implies different isolation levels.
Is saas-scaffolder safe to install?
Treat it as editorial architecture guidance; review the Security Audits panel on this page and do not treat pattern text as legal or compliance advice without your own review.
SKILL.md
READMESKILL.md - Saas Scaffolder
# SaaS Architecture Patterns ## Overview This reference covers the key architectural decisions when building SaaS applications. Each pattern includes trade-offs and decision criteria to help teams make informed choices early in the development process. ## Multi-Tenancy Models ### 1. Shared Database (Shared Schema) All tenants share the same database and tables, distinguished by a `tenant_id` column. **Pros:** - Lowest infrastructure cost - Simplest deployment and maintenance - Easy cross-tenant analytics - Fastest time to market **Cons:** - Risk of data leakage between tenants - Noisy neighbor performance issues - Complex data isolation enforcement - Harder to meet data residency requirements **Best for:** Early-stage products, SMB customers, cost-sensitive deployments ### 2. Schema-Per-Tenant Each tenant gets their own database schema within a shared database instance. **Pros:** - Better data isolation than shared schema - Easier per-tenant backup and restore - Moderate infrastructure efficiency - Can customize schema per tenant if needed **Cons:** - Schema migration complexity at scale (N migrations per update) - Connection pooling challenges - Database instance limits on schema count - Moderate operational complexity **Best for:** Mid-market products, moderate tenant count (100-1,000) ### 3. Database-Per-Tenant Each tenant gets a completely separate database instance. **Pros:** - Maximum data isolation and security - Per-tenant performance tuning - Easy data residency compliance - Simple per-tenant backup/restore - No noisy neighbor issues **Cons:** - Highest infrastructure cost - Complex deployment automation required - Cross-tenant queries/analytics challenging - Connection management overhead **Best for:** Enterprise products, regulated industries (healthcare, finance), high-value customers ### Decision Matrix | Factor | Shared DB | Schema-Per-Tenant | DB-Per-Tenant | |--------|-----------|-------------------|---------------| | Cost | Low | Medium | High | | Isolation | Low | Medium | High | | Scale (tenants) | 10,000+ | 100-1,000 | 10-100 | | Compliance | Basic | Moderate | Full | | Complexity | Low | Medium | High | | Performance | Shared | Moderate | Dedicated | ## API-First Design ### Principles 1. **API before UI** - Design the API contract before building any frontend 2. **Versioning from day one** - Use URL versioning (`/v1/`) or header-based 3. **Consistent conventions** - RESTful resources, standard HTTP methods, consistent error format 4. **Documentation as code** - OpenAPI/Swagger specification maintained alongside code ### REST API Standards - Use nouns for resources (`/users`, `/projects`) - Use HTTP methods semantically (GET=read, POST=create, PUT=update, DELETE=remove) - Return appropriate status codes (200, 201, 400, 401, 403, 404, 429, 500) - Implement pagination (cursor-based for large datasets, offset for small) - Support filtering, sorting, and field selection - Rate limiting with clear headers (X-RateLimit-Limit, X-RateLimit-Remaining) ### API Design Checklist - [ ] OpenAPI 3.0+ specification created - [ ] Authentication (API keys, OAuth2, JWT) documented - [ ] Error response format standardized - [ ] Rate limiting implemented and documented - [ ] Pagination strategy defined - [ ] Webhook support for async events - [ ] SDKs planned for primary languages ## Event-Driven Architecture ### When to Use - Decoupling services that evolve independently - Handling asynchronous workflows (notifications, integrations) - Building audit trails and activity feeds - Enabling real-time features (live updates, collaboration) ### Event Patterns - **Event Notification**: Lightweight event triggers consumer to fetch data - **Event-Carried State Transfer**: Event contains all needed data - **Event Sourcing**: Store state as sequence of events, derive current state ### Implementation Options - **Message Queues**: RabbitMQ, Amazon SQS (point-to-point) - **Event Streams**: Apache Kafka, Amazon Ki