Laravel Plans Laravel Package

Technical Evaluation

Architecture Fit

• SaaS Subscription Core: The package excels as a subscription management layer for SaaS applications, decoupling plan/feature logic from billing/payment systems. It aligns well with Laravel’s Eloquent ecosystem and leverages traits for modular integration.
• Feature-First Design: Supports both countable (e.g., tokens, credits) and uncountable (e.g., access flags) features, with configurable reset intervals. This is ideal for tiered SaaS models (e.g., "Basic + 1000 API calls").
• Event-Driven Extensibility: Emits events (SubscriptionCreated, SubscriptionRenewed) for seamless integration with external billing systems (Stripe, custom, etc.). This avoids vendor lock-in.
• Localization Support: Uses spatie/laravel-translatable for multilingual plans/features, reducing frontend duplication.

Integration Feasibility

• Laravel Native: Built for Laravel (v10+), with zero configuration for core functionality. Uses Eloquent models, migrations, and service providers.
• Billing Agnostic: Explicitly does not handle payments/invoices, forcing a clean separation. Requires a separate billing system (e.g., Stripe, custom) to listen to events and generate invoices.
• Migration Path:
  • Greenfield: Install via Composer, run migrations, and implement HasSubscriptions trait.
  • Brownfield: Requires mapping existing subscriptions/plans to the new schema (e.g., via data migrations or seeders).
• Dependencies:
  • Core: Laravel, PHP 8.1+, Eloquent.
  • Optional: spatie/eloquent-sortable (for ordering), spatie/laravel-translatable (for localization).
  • No heavy libraries (e.g., no queues, caching, or complex state machines).

Technical Risk

Key Questions for TPM

1. Billing System Compatibility:

   • How will we integrate with [Stripe/PayPal/custom]? Are there existing event listeners or will we build them?
   • Do we need to support prorated billing for partial periods (e.g., mid-month upgrades)?

2. Feature Usage Tracking:

   • How will we audit feature consumption (e.g., API calls, storage)? Does the package’s FeatureUsage model suffice?
   • What’s the strategy for overage charges (e.g., if a user exceeds their token limit)?

3. Plan Management Workflow:

   • How will we handle plan updates (e.g., price changes, feature additions)? Will we use the package’s renew() or a custom migration?
   • Do we need versioning for plans (e.g., to grandfather existing users into old pricing)?

4. Scaling Considerations:

   • How many plans/features/subscriptions will we support at launch? (Affects database indexing.)
   • Will we need to cache plan lists (e.g., for checkout pages) to reduce query load?

5. Localization Needs:

   • Do we need multilingual plans/features? If not, can we disable the translatable dependency?
   • How will we handle currency localization (e.g., € vs. $) for prices?

6. Testing Strategy:

   • How will we test feature consumption (e.g., token limits) and subscription transitions (e.g., downgrades)?
   • Do we need to mock the billing system during tests?

7. Monitoring/Alerts:

   • What metrics will we track (e.g., failed subscriptions, feature overuse)?
   • How will we alert on expiring subscriptions or low feature balances?

Integration Approach

Stack Fit

Migration Path

1. Assessment Phase:

   • Audit existing subscription logic (e.g., custom tables, business rules).
   • Map current plans/features to the package’s schema (e.g., Plan, Feature, Subscription).

2. Setup:

   composer require lacodix/laravel-plans
   php artisan vendor:publish --provider="Lacodix\LaravelPlans\LaravelPlansServiceProvider"
   php artisan migrate
   

   • Configure .env (e.g., PLANS_PRICE_PRECISION=2).

3. Data Migration:

   • Option A: Write a seeder to import existing plans/subscriptions.
   • Option B: Use a data migration to transform old schema to new (e.g., users_subscriptions → subscriptions).

4. Trait Implementation:

   // app/Models/User.php
   use Lacodix\LaravelPlans\Models\Traits\HasSubscriptions;
   class User extends Authenticatable {
       use HasSubscriptions;
   }
   

5. Billing Integration:

   • Register event listeners for SubscriptionCreated, SubscriptionRenewed:

     // app/Listeners/CreateStripeSubscription.php
     public function handle(SubscriptionCreated $event) {
         Stripe::createSubscription($event->subscription);
     }
     

6. Feature Consumption:

   • Implement logic to track usage (e.g., middleware for API routes):

     $user->consumeFeature('tokens', 10);
     

7. Testing:

   • Write feature tests for:
     • Plan subscription/renewal/cancellation.
     • Feature consumption limits.
     • Billing event triggers.

Compatibility

Sequencing

1. Phase 1: Core Setup (2–3 sprints)

   • Install package, run migrations, implement HasSubscriptions.
   • Migrate existing plans/features to new schema.
   • Build basic subscription flows (subscribe/renew/cancel).

2. Phase 2: Billing Integration (1–2 sprints)

   • Implement event listeners for Stripe/PayPal/custom billing.
   • Test prorated billing for partial periods.

3. Phase 3: Feature Management (1–2 sprints)