Tenancy Laravel Package

Product Decisions This Supports

• Multi-Tenant SaaS Architecture: Enables rapid development of SaaS platforms with isolated tenant data (e.g., subdomains like client1.app, client2.app) without custom middleware or model traits.
• Build vs. Buy: Eliminates the need to build a custom multi-tenancy solution, reducing dev time and maintenance overhead. Opportunity cost: ~6–12 months of engineering effort saved for a team of 3–5 engineers.
• Roadmap Priorities:
  • Phase 1: Launch MVP with tenant isolation (host-based routing, database separation).
  • Phase 2: Scale with features like tenant-specific assets (Vite support), impersonation, and queue tenancy.
  • Phase 3: Optimize for performance (e.g., caching, resolver tuning) and compliance (e.g., GDPR data deletion).
• Use Cases:
  • B2B Platforms: Isolate customer portals (e.g., acme.client1.app).
  • Marketplaces: Separate vendor data (e.g., seller123.shopify.com).
  • Internal Tools: Departmental apps (e.g., hr.company.com, finance.company.com).
  • Legacy Migration: Retrofit multi-tenancy to existing Laravel apps without rewriting core logic.

When to Consider This Package

Adopt This Package If:

• Your Laravel app requires multi-tenancy with subdomains/host-based routing (e.g., tenant1.yourapp.com).
• You need database isolation per tenant (separate schemas/databases) with minimal code changes.
• Your team lacks expertise in custom middleware or connection switching (e.g., no need to modify Cache, Storage, or Eloquent models).
• You’re using Laravel 10–13 and PHP 8+ (active support for modern stacks).
• You prioritize developer velocity over fine-grained control (e.g., no need for tenant-specific configurations beyond hostnames).
• Your use case involves queue jobs, Vite assets, or impersonation (built-in support reduces integration risk).

Look Elsewhere If:

• You need path-based tenancy (e.g., /tenant1/dashboard) instead of host-based (requires custom resolver).
• Your tenants require shared databases with row-level security (e.g., PostgreSQL RLS) instead of isolation.
• You’re using Laravel <10 or PHP <8 (package drops legacy support).
• You need advanced tenant switching logic (e.g., dynamic subdomain rewrites via Nginx/Apache).
• Your app relies on custom tenant identification (e.g., API keys, JWT claims) beyond hostnames.
• You require tenant-specific configurations (e.g., per-tenant queues, caches) that aren’t covered by the package’s defaults.

How to Pitch It (Stakeholders)

For Executives:

*"This package lets us launch a multi-tenant SaaS product without building a custom tenancy system—saving 6–12 months of dev time and reducing technical debt. It handles:

• Automatic tenant isolation (databases/schemas per tenant) via subdomains (e.g., client1.yourapp.com).
• Zero code changes to our existing Laravel app—no middleware, traits, or connection overrides.
• Built-in support for queues, Vite assets, and admin impersonation, which are critical for our roadmap.
• Active maintenance with Laravel 13 support and a thriving community (4.3K stars, 300+ contributors).

Risk: Minimal—MIT license, battle-tested in production, and backed by a solo maintainer with a strong track record. We can pilot with 2–3 tenants in 2 weeks."*

For Engineering:

*"This is a drop-in solution for multi-tenancy that:

• Eliminates boilerplate: No custom middleware, model traits, or connection switching logic.
• Works out of the box: Host-based routing (e.g., tenant1.app), database isolation, and tenant resolution via hostname.
• Supports our stack: Laravel 10–13, PHP 8+, with optimizations for queues (e.g., queue:retry), Vite, and caching.
• Reduces integration risk: Built-in fixes for edge cases (e.g., queue workers, asset paths, Redis clusters).

Trade-offs:

• Limited to host-based tenancy (no path-based or API-key-based routing).
• Default configurations may require tweaks for advanced use cases (e.g., tenant-specific queues).

Proposal:

1. Pilot: Test with 2–3 tenants in staging (1 week).
2. Validate: Confirm performance with load tests (e.g., 100+ tenants).
3. Iterate: Customize resolvers/configs for edge cases (e.g., wildcard subdomains).

Alternatives considered:

• Custom solution: 6–12 months of dev time, higher maintenance.
• Other packages: Less mature (e.g., older tenancy packages) or overkill (e.g., full SaaS frameworks like Filament)."*