Tyro Laravel Package

Product Decisions This Supports

• Build vs. buy for authorization. Tyro covers RBAC/ACL, role and privilege management, suspensions, permission caching, audit logging, middleware, Blade directives, and Artisan tooling on top of Laravel Sanctum. Adopting it turns a multi-sprint internal project (schema, resolution pipeline, caching, admin commands, audit trail) into an integration task — typically days, not quarters.
• Feature prioritization on the roadmap. Because authorization is a platform concern rather than a differentiator, Tyro frees the roadmap to invest in customer-facing features instead of plumbing. It also unlocks adjacent roadmap items cheaply: admin user/permission management screens, "who can see/do what" self-service, and tenant-scoped access for multi-tenant plans.
• Enterprise/B2B tier readiness. Privileges, suspensions, tenant isolation, and immutable audit trails are the exact capabilities sales asks for in security questionnaires and SOC 2 / ISO conversations. This package can justify or accelerate an enterprise pricing tier and shorten security review cycles.
• Monetization and packaging. Role quotas, privilege tiers, and suspend/reactivate flows map directly to plan gating and seat/role-based pricing models — decisions that are cheap to implement once the authorization layer exists.
• Operational leverage for a small team. The CLI-first design (tyro:{entity}-{action} commands, seeded roles/permissions, configurable tables and models) means a PM can spec admin workflows that engineers implement as one-liners instead of custom UI + endpoints.
• Risk register inputs. Community-maintained, MIT, ~684 stars, single-vendor risk, and a hard dependency on Laravel 12/13 and Sanctum are all decisions the roadmap must absorb (upgrade cadence, version pinning, exit plan).

When to Consider This Package

Consider adopting when:

• The product is a Laravel 12/13 application using (or willing to use) Sanctum for API auth, and needs roles and granular permissions/privileges beyond simple gates.
• You need more than spatie/laravel-permission-style basics: suspensions, system-level break-glass privileges, inheritance, wildcard middleware, permission caching, and audit logging out of the box.
• You are building a B2B / multi-tenant SaaS and want tenant-scoped permissions without designing isolation semantics yourself.
• Compliance or customer trust requires an immutable authorization audit trail (role changes, privilege grants, suspensions) — a common security-questionnaire requirement.
• Your team is small and speed-constrained, and authorization is not a competitive differentiator.
• You want CLI-driven administration for ops/support (grant, revoke, suspend, audit) rather than building an internal admin tool first.
• You value extensibility: configurable table names, model classes, custom providers/drivers/resolvers — reducing the risk of a hard lock-in.

Look elsewhere when:

• The stack is not Laravel 12/13, or you rely on a different auth guard/token system than Sanctum.
• You already have a mature authorization layer (Spatie, Bouncer, custom policies) and the migration cost exceeds the gain.
• You require vendor-backed SLAs, indemnification, or dedicated support — this is a community package, and procurement/security teams may reject it outright.
• You need enterprise identity features (SAML/SSO, SCIM provisioning, OIDC federation) — those live outside Tyro's scope and must be sourced separately.
• Your authorization model is ABAC/relationship-based (ReBAC) with complex attribute or graph rules; Tyro's role/permission/privilege model may not express it cleanly.
• You have no appetite for a third-party critical-path dependency or lack the engineering bandwidth to track upstream releases and Laravel major upgrades.
• Very high scale with strict latency budgets and no tolerance for cache-warming/invalidation tuning on someone else's code.

Adoption criteria (gating checklist): Laravel 12/13 confirmed → Sanctum in place → audit/compliance need present → security review of dependency and maintainer risk accepted → upgrade owner named → migration/exit plan documented → acceptance tests written against your own role matrix.

How to Pitch It (Stakeholders)

For executives (one paragraph): Authorization — who can see and do what — is required for every customer, is not a differentiator, and is expensive to build and maintain safely. Tyro is an MIT-licensed, Laravel-native package that delivers roles, granular privileges, suspensions, tenant isolation, permission caching, and a tamper-evident audit trail, administered through built-in command-line tooling. Adopting it converts a multi-sprint internal build into a short integration, de-risks enterprise security reviews, and lets the team spend the quarter on revenue features. The trade-off is a community-maintained dependency on our critical path, which we mitigate with version pinning, an upgrade owner, and a documented fallback to in-house or alternative libraries.

For engineering leads: This is a framework, not a black box — explicit contracts for permissions, roles, privileges, inheritance, resolution pipelines, caching, events, middleware, Blade directives, and extensibility (configurable tables/models, custom drivers). It enforces secure defaults and privilege-escalation guardrails, and the documented conventions mean contributions and extensions stay consistent. Cost is integration plus diligence: pin the version, exercise the full Pest suite in CI, track Laravel major releases, and keep our authorization logic behind our own service boundary so swapping implementations stays feasible.

For security/compliance: We gain structured audit logging of authorization changes, explicit suspension semantics, tenant scoping, and centralized policy integration — all things we would otherwise hand-roll inconsistently. Recommended conditions for approval: pin to a reviewed version, review the audit-log immutability guarantees ourselves, validate the privilege-resolution and cache-invalidation paths with our own test suite, and document the supply-chain posture (single maintainer, MIT, dependency tree).

For sales/solutions: We can answer "can you restrict access by role, tenant, and individual privilege, and can you prove who changed what and when?" with yes — earlier than a from-scratch build would allow.