Ti Ext User Laravel Package

Product Decisions This Supports

• Build vs. Buy Decision:

  • Buy: Eliminates 3–6 months of development time for core user management (authentication, registration, password resets, email verification). Justifies investment by reducing technical debt and accelerating MVP launch.
  • Customization Budget: Allocates dev resources to high-value differentiators (e.g., restaurant-specific features like table assignment, loyalty tiers) rather than reinventing auth wheels.

• Roadmap Prioritization:

  • Phase 1 (0–3 Months): Leverage pre-built auth to launch customer/staff portals with impersonation for support teams.
  • Phase 2 (3–6 Months): Extend with automation hooks (e.g., igniter.user.register → trigger welcome discounts) and integrate with ti-ext-orders.
  • Phase 3 (6–12 Months): Customize RBAC for franchise models or add SMS/OTP verification via extensions.

• Feature Expansion:

  • Loyalty Programs: Use igniter.user.register event to auto-enroll customers in tiers.
  • Multi-Tenant: Foundation for role-based access control (RBAC) if expanding to franchise chains.
  • Compliance: Built-in GDPR tools (email verification, data export) reduce legal risk.

• Use Cases:

  • B2C Restaurants: Customer accounts for reservations, orders, and loyalty.
  • B2B Catering: Staff portals for event planning teams with impersonation for client support.
  • Ghost Kitchens: Admin oversight of delivery driver accounts with performance tracking.

When to Consider This Package

Adopt If:

• Domain Alignment: Building a restaurant/food-service platform where user flows include:
  • Staff impersonation (e.g., admins resolving customer issues in real-time).
  • Hospitality-specific features (e.g., table assignments, shift scheduling).
• Time-to-Market: Need to launch authentication/registration in <4 weeks without hiring dedicated backend devs.
• Admin Workflows: Require impersonation tools to reduce support ticket resolution time (e.g., debugging customer account locks).
• Event-Driven Automation: Plan to use hooks (e.g., igniter.user.register) for post-auth actions (e.g., welcome emails, fraud alerts).
• TastyIgniter Ecosystem: Already using or evaluating TastyIgniter (e.g., ti-ext-orders, ti-ext-reservations) for a unified stack.

Look Elsewhere If:

• Generic SaaS: Need broader use cases (e.g., B2B, non-hospitality). Consider:
  • Laravel Breeze/Jetstream: For lightweight, customizable auth.
  • Fortify: For enterprise-grade security without UI.
• Complex RBAC: Require matrix permissions (e.g., role + resource + action). This package offers basic role-based access.
• High Scalability: Expecting millions of users—package lacks explicit horizontal scaling docs or caching strategies.
• Non-Email Verification: Need SMS/OTP as primary verification. Requires custom extension or third-party (e.g., Twilio).
• Budget for Customization: Willing to invest in dedicated dev resources to build tailored auth (e.g., social logins, magic links).
• Alternative Backends: Using Node.js, Python (Django/Flask), or Ruby on Rails. This is Laravel-specific.

How to Pitch It (Stakeholders)

For Executives (Business Case):

*"This package cuts 6–8 weeks of development time to launch secure customer and staff portals with restaurant-specific tools like admin impersonation—critical for resolving guest issues in real-time (e.g., wrong orders, account locks). It’s MIT-licensed, so no vendor lock-in, and includes automation hooks to trigger loyalty programs or support alerts without custom code. For a $5K–$10K investment in setup (vs. $50K+ for a custom build), we gain:

• Faster time-to-market for reservations, orders, and loyalty programs.
• 20–30% reduction in support costs via impersonation tools (e.g., admins fix issues without customer involvement).
• Compliance-ready GDPR tools (email verification, data export) to avoid legal risks.
• Scalable foundation for future features like franchise management or staff scheduling.

Risk Mitigation: 'If we outgrow this, we can replace it later—it’s modular and well-documented. The active GitHub repo (last release: May 2026) shows ongoing maintenance, and the MIT license ensures no hidden costs.'

ROI Example:

• Scenario: Launching a loyalty program for 10,000 customers.
  • Custom Build: 4 months, $75K, 3 devs.
  • This Package: 2 months, $8K, 1 dev + 1 QA.
  • Savings: $67K + 2 months of revenue from early launch."*

For Engineering (Technical Deep Dive):

*"This is a batteries-included Laravel package for restaurant user management with these key advantages:

1. Pre-Built Core Flows:

   • Authentication (customers/staff), registration (with email verification), password resets.
   • Impersonation: Admins can debug customer sessions via Auth::impersonate($customer)—critical for support workflows.
   • Admin Panel: Manage users/staff via UI (no manual SQL). Supports bulk actions, search, and permissions.

2. Extensible Architecture:

   • Events: Hook into igniter.user.register, igniter.user.login for custom logic (e.g., analytics, fraud detection). Example: Trigger a welcome discount when igniter.user.register fires.
   • Actions: Override or extend CustomerRegistrationAction, PasswordResetAction, etc.
   • Middleware: Built-in Authenticate, VerifyEmail, and Impersonate middleware.

3. Performance Optimizations:

   • Database indexes added in v4.1.0+ for query performance.
   • Eager loading in v4.0.18 to reduce N+1 queries.
   • Silent saves (saveQuietly()) to avoid UI feedback during bulk operations.

4. Maintenance:

   • MIT license, active repo (last commit: May 2026), and clear docs for customization.
   • Bug fixes for edge cases (e.g., v4.0.16 fixed null passwords after registration).

Trade-offs:

• TastyIgniter-Specific: Assumes TastyIgniter’s conventions (e.g., AdminAuth, igniter:up migrations). May need abstraction layers for vanilla Laravel.
• Limited Vanilla Support: Not designed for non-TastyIgniter Laravel apps (e.g., lacks make:auth compatibility).
• Feature Scope: Focuses on auth/admin—additional features (e.g., 2FA, social logins) require extensions.

Proposed Implementation Plan:

1. Week 1: Install (composer require tastyigniter/ti-ext-user), run php artisan igniter:up, configure admin settings (emails, permissions).
2. Week 2: Integrate with frontend (e.g., pass Auth::check() to Vue/React for UI state). Test impersonation workflows.
3. Week 3: Build custom hooks (e.g., igniter.user.register → send welcome SMS via Twilio).
4. Week 4: Load test with 1,000 concurrent users; optimize indexes if needed.

Alternatives Considered:

• Laravel Breeze: Lighter but lacks restaurant-specific features (e.g., impersonation).
• Custom Build: Higher cost/risk for auth edge cases (e.g., password reset race conditions).
• Third-Party Auth: Auth0/Cognito add complexity and cost for this use case.

Migration Path:

• If we need to leave TastyIgniter later, we can extract the auth logic into a standalone Laravel package with minimal refactoring (e.g., replace AdminAuth with Laravel’s Auth facade)."*

Call to Action: "Let’s prototype the auth flow in 2 weeks to validate fit. If it meets our needs, we’ll proceed with full integration; if not, we’ll pivot to [Laravel Breeze + custom impersonation middleware]."