Laravel Tenants Laravel Package

Product Decisions This Supports

• Multi-Tenancy Architecture: Enables a single-database multi-tenancy model, reducing infrastructure costs and simplifying deployments compared to multi-database or SaaS-specific solutions (e.g., SaaS Starter Kits). Ideal for B2B platforms, marketplaces, or white-label SaaS where tenant isolation is critical but shared infrastructure is preferred.
• Build vs. Buy: Avoids reinventing multi-tenancy logic (e.g., custom middleware, query scopes, or database-level isolation), saving 6–12 months of dev effort while maintaining flexibility. Comparable to commercial solutions like Stripe Billing or Chargebee but for data isolation, not just billing.
• Roadmap Acceleration:
  • Phase 1: Launch a tenant-aware MVP (e.g., a marketplace with isolated vendor data) without over-engineering.
  • Phase 2: Gradually introduce shared vs. isolated data (e.g., shared pricing tables vs. tenant-specific dashboards).
  • Phase 3: Scale to polymorphic tenancy (e.g., tenants with sub-tenants, like a franchise system).
• Use Cases:
  • Isolated Data: HIPAA/GDPR-compliant tenant data (e.g., healthcare platforms).
  • Shared Infrastructure: Centralized auth, reporting, or analytics across tenants.
  • Cost Optimization: Replace multi-database setups (e.g., PostgreSQL schemas) with a unified Laravel schema.

When to Consider This Package

• Adopt When:
  • Your primary tenancy requirement is data isolation (not just billing/subscriptions).
  • You’re using Laravel and want to avoid vendor lock-in (MIT license).
  • You need granular control over shared vs. isolated data (e.g., "All users are shared, but orders are tenant-scoped").
  • Your team has moderate Laravel experience (polymorphic tenancy requires understanding of Laravel’s query builder and middleware).
  • You’re not building a highly dynamic tenancy system (e.g., tenants that can be created/deleted at runtime with zero downtime; this package favors predefined tenants).
• Look Elsewhere If:
  • You need multi-database tenancy (e.g., for strict compliance or performance).
  • Your tenancy model is extremely complex (e.g., nested sub-tenants with dynamic permissions; consider Spatie’s Tenancy or custom solutions).
  • You require built-in billing/subscription management (pair with Spatie’s Laravel Cashier or Stripe).
  • Your team lacks Laravel middleware/query scope experience (steep learning curve for advanced use cases).
  • You need real-time tenant provisioning (e.g., auto-creating databases on tenant signup; this package is not a PaaS).

How to Pitch It (Stakeholders)

For Executives (1 Slide)

Problem:

"We’re building [Product X], a [B2B/marketplace/SaaS] platform where [tenants/clients] need isolated data but shared infrastructure. Today, we’d need to either:

• Build custom tenancy logic (6–12 months, high risk), or
• Pay for a proprietary SaaS tenancy solution (recurring costs, vendor lock-in)."

Solution:

"Rinvex Tenants lets us launch a single-database multi-tenancy system in 2 weeks using Laravel—isolating sensitive data (e.g., tenant-specific dashboards) while sharing centralized features (e.g., analytics, support).

• Cost: ~$0 (MIT license) vs. $50K+ for custom dev or SaaS tools.
• Speed: Ship MVP 3x faster than building from scratch.
• Flexibility: Control what data is shared vs. isolated (e.g., GDPR-compliant tenant data).
• Scalability: Supports future needs like franchises or sub-tenants."*

Risk Mitigation:

"We’ll pilot with [Tenant Type A] and validate isolation before scaling. If gaps emerge, we’ll invest in custom extensions (low risk due to open-source)."

For Engineering (Deep Dive)

Why This Package?

"Rinvex Tenants solves 90% of our multi-tenancy needs with Laravel’s native tools (no external dependencies). Key advantages:

• Single-DB Efficiency: No schema replication or connection management overhead.
• Polymorphic Tenancy: Supports shared tables (e.g., users, roles) and tenant-scoped tables (e.g., tenant_orders) via query scopes and middleware.
• Laravel Native: Integrates with Eloquent, migrations, and caching (e.g., tenant() helper for context-aware queries).
• Extensible: We can override defaults (e.g., custom tenant resolution logic) without forking the package."*

Implementation Plan:

1. Week 1: Set up package, configure tenants table, and define shared vs. isolated models.
2. Week 2: Build tenant-aware middleware (e.g., TenantMiddleware to auto-resolve tenants from subdomains/IDs).
3. Week 3: Test data isolation (e.g., TenantA can’t see TenantB’s orders) and shared data (e.g., all tenants see the same pricing).
4. Ongoing: Use polymorphic tenancy for advanced cases (e.g., tenant hierarchies).

Alternatives Considered:

Open Questions for the Team:

• How will we handle tenant onboarding (e.g., auto-creating initial data)?
• Do we need tenant-specific caching (e.g., Redis namespaces)?
• Should we add audit logs for tenant data access? (Could extend the package.)