Sudo Su Laravel Package

Product Decisions This Supports

• Support & back-office tooling: Impersonation ("login as user") is a high-leverage feature for reducing time-to-resolution on customer tickets — support agents can reproduce the customer's exact view without screen-shares or credential sharing.
• QA and pre-release validation: Enables fast switching between roles/accounts to verify permission boundaries, empty states, and multi-persona flows before launch.
• Build vs. buy: This package is a cheap way to ship the "view as user" capability versus building auth-switching, session handling, and UI in-house. The real build cost isn't the switch itself — it's the audit trail, authorization guardrails, and compliance review, which this package does not provide.
• Roadmap input: If impersonation is customer-facing or support-critical, treat a lightweight package as a prototype decision, not a long-term commitment. Plan for a hardened, audited implementation if the capability becomes part of a supported workflow or falls under compliance scope.
• Release 1.1.0 changes the integration contract: The package no longer injects its user-selector markup and assets into every request. Consumers must explicitly @include('sudosu::user-selector') in their layout (the release note recommends wrapping it in @if (env('APP_DEBUG'))). This is a breaking change for any app relying on auto-injection: the feature will silently disappear after upgrade unless the layout is updated.

When to Consider This Package

Consider it when:

• The app is Laravel/PHP and the team wants impersonation quickly for internal support, QA, or demo environments.
• Debug-only or internal-only exposure is acceptable — the documented pattern gates the UI behind APP_DEBUG.
• You can accept that audit logging, per-role authorization, and "who impersonated whom" reporting are your responsibility, not the package's.
• The team is comfortable owning a small third-party dependency and tracking its release notes (as 1.1.0 demonstrates, changes can break your layout).

Look elsewhere (or build in-house) when:

• Impersonation is a production support workflow requiring immutable audit trails, approval flows, or session-scoped consent — compliance regimes (SOC 2, HIPAA, PCI) will demand controls this package does not ship.
• You need granular authorization (who may impersonate whom, under what conditions) rather than a debug toggle.
• You cannot absorb manual layout changes and upgrade verification across environments — the 1.1.0 shift from auto-injection to explicit include means an upgrade can quietly remove a tool your support team depends on (a silent regression, not a loud failure).
• You require active maintenance guarantees, security disclosures, or vendor support.

Adoption checklist for 1.1.0: pin the version, add the partial to every relevant layout, confirm APP_DEBUG is false in production so the selector never renders, and verify post-deploy that the selector still appears where support expects it. Decide deliberately between upgrading now (cleaner, less global injection) and staying on 1.0.x (auto-injection, but you inherit the old behavior and drift from upstream).

How to Pitch It (Stakeholders)

For executives: This is a low-cost internal productivity capability — letting support and QA see the product exactly as a customer does. It shortens troubleshooting and reduces risky workarounds like shared credentials. It is a small open-source dependency, not a platform investment; treat it as a tactical tool with a known limitation: it does not provide the audit trail or access controls we would need if impersonation becomes a formal, compliance-relevant support process.

For engineering: Version 1.1.0 removes automatic injection of the user-selector markup and assets. Integration is now an explicit @include('sudosu::user-selector') in the layout, ideally wrapped in @if (env('APP_DEBUG')). Treat this as a breaking change: upgrading requires a layout edit in every consuming app, and missing it silently removes the feature rather than erroring. Upside is reduced global surface area and no production markup by default. Recommend pinning the dependency, adding the include behind the debug guard, and validating in staging before rollout. Flag that authorization and audit logging remain our responsibility.