Tenancy Bundle Laravel Package

Product Decisions This Supports

• Multi-Tenancy Architecture: Enables a shared-nothing or shared-database SaaS model with minimal code changes, reducing technical debt compared to custom implementations.
• Roadmap Prioritization: Justifies investing in a Symfony-based SaaS platform over Laravel alternatives (e.g., stancl/tenancy) if the stack is already Symfony.
• Build vs. Buy: Buy—avoids reinventing tenancy for Doctrine, cache, Mailer, Messenger, and CLI isolation. Saves 3–6 months of dev effort.
• Use Cases:
  • B2B SaaS: Isolate customer data (e.g., acme.com, globex.com) via subdomains or headers.
  • Marketplaces: Shared DB with tenant-scoped entities (e.g., #[TenantAware] User).
  • Internal Tools: Multi-tenant dashboards (e.g., ?tenant=team_x query params).
  • Legacy Migration: Gradually adopt tenancy without rewriting existing queries.

When to Consider This Package

• Adopt if:

  • Your app is Symfony 7.4+ (PHP 8.2+) and uses Doctrine ORM (optional but recommended).
  • You need zero-boilerplate tenancy for database, cache, Mailer, Messenger, and CLI.
  • Security is critical: Strict mode blocks data leaks by default (unlike manual implementations).
  • You want SPA-friendly resolvers (e.g., Origin header for React/Vue frontends).
  • Testing is a priority: Built-in InteractsWithTenancy trait for PHPUnit.

• Look elsewhere if:

  • You’re on Laravel (use stancl/tenancy instead).
  • Your tenancy needs are simple (e.g., single-table inheritance with a tenant_id column—manual SQL filters may suffice).
  • You require postgreSQL schemas or advanced sharding (this bundle focuses on DB-per-tenant or shared-DB with filters).
  • Your team lacks Symfony/DI experience (steep learning curve for custom bootstrappers).
  • You need high tenant concurrency (DB-per-tenant may hit connection limits; consider a connection pool like pgsql:pool).

How to Pitch It (Stakeholders)

For Executives:

*"This package lets us launch a multi-tenant SaaS product in weeks, not months. By automating tenant isolation for databases, caches, emails, and queues—without manual code changes—we reduce risk and accelerate time-to-market. For example:

• Acme Corp and Globex Inc. can share the same codebase but have isolated data.
• No data leaks: Strict mode blocks cross-tenant queries by default (unlike custom solutions).
• Future-proof: Works with our existing Symfony stack and scales as we add features like tenant-specific branding or pricing tiers. Cost? Zero—it’s open-source (MIT license). ROI? 3–6 months of dev time saved."*

For Engineering:

*"This is a first-class tenancy solution for Symfony, addressing gaps in existing bundles (e.g., RamyHakam lacks Messenger/Mailer integration). Key wins:

• Zero leaks: Tenant context propagates to Doctrine, Cache, Mailer, and Messenger automatically.
• Flexible resolvers: Use subdomains (acme.app), headers (X-Tenant-ID), or query params (?tenant=123).
• Shared-DB mode: Mark entities with #[TenantAware]—no manual WHERE tenant_id = ? in queries.
• CLI support: Run migrations or commands per tenant (./bin/console tenancy:run migrate --tenant=acme).
• Profiler integration: Debug tenant context via Symfony’s Web Debug Toolbar. Trade-offs:
• Not for Laravel (use stancl/tenancy instead).
• DB-per-tenant requires connection management (may need tuning for high concurrency). Recommendation: Pilot this in our next SaaS feature (e.g., tenant portals) and compare to a manual implementation. If it saves >20% dev time, adopt it."*

Call to Action: *"Let’s prototype this with the three-tenant demo (Dockerized, 5-minute setup) and measure:

1. Dev time saved (vs. custom tenancy).
2. Data isolation (smoke test with bin/smoke.sh).
3. Performance impact (load test with 100+ tenants). If it meets our needs, we’ll integrate it into the Q3 roadmap for the SaaS platform."*