Larke Auth Laravel Package

Product Decisions This Supports

• Authorization model selection (ACL vs RBAC vs ABAC). The package's core value is offering one API across three access-control models, which maps directly to a real product decision: do we gate features by role (RBAC), by resource ownership/ACL, or by runtime attributes and context (ABAC — plan tier, region, time, data classification)? Choosing wrong is expensive to reverse; a library that lets you start with roles and graduate to attribute policies without rewriting call sites de-risks that sequencing.
• Build vs buy for the permissions layer. This is a candidate on the "buy/borrow" side of the ledger for a capability that is (a) universally needed, (b) easy to under-engineer, and (c) security-sensitive. The build alternative — Laravel's native Gate/Policy plus a role package — is credible, so this is a genuine comparison, not a default.
• Enterprise and monetization roadmap. Fine-grained authorization is the technical prerequisite for the tiers that carry pricing power: team/org roles, per-seat admin, custom roles, SSO/SCIM mapping, delegated administration, and audit trails. If we intend to sell "advanced permissions" as an upgrade, the authorization substrate becomes a roadmap dependency rather than an implementation detail.
• Multi-tenant and compliance readiness. ABAC-style policies are the mechanism for tenant isolation and for expressing obligations like data residency or classification-based access. That affects whether we can pursue deals with procurement/security review, and how much bespoke code each such deal requires.
• Feature entitlement and gating mechanics. Whether plan entitlements are expressed as roles, attributes, or hardcoded checks determines how fast product and sales can ship packaging changes without engineering.
• Use cases worth validating in a spike: internal admin/back-office tooling with coarse roles; B2B SaaS org-and-team hierarchies where a user's permissions derive from membership; resource-level sharing (ACL) for documents/projects; policy-driven access to sensitive records (ABAC) where role alone is insufficient.
• A note on signal quality: 1 star and 0 dependents means there is no adoption evidence to inform a decision. Treat the package as a design reference for how to model multi-paradigm authorization — a source of patterns and vocabulary — rather than as a dependency whose behavior the market has already vetted.

When to Consider This Package

Consider it when:

• You need to support more than one access-control paradigm in the same product (e.g., org roles and per-document sharing and context-sensitive rules), and you want a single abstraction instead of three inconsistent homegrown ones.
• You are early in the authorization design and want a worked implementation to evaluate against, or you are prototyping to learn what your policy model should be before committing.
• You have engineering capacity to vendor, fork, and own the code — read it end to end, add tests, pin a version, and keep it behind an internal adapter/interface so the underlying implementation is swappable.
• Apache-2.0 licensing fits your distribution and IP posture (permissive, commercially usable, no copyleft contamination).
• The scope is internal or low-blast-radius — admin tooling, prototypes, internal services — where a defect in the permission check is inconvenient rather than a breach.

Look elsewhere when:

• Authorization is production- and security-critical with customer-facing exposure. At 1 star and 0 dependents there is no community review, no independent security scrutiny, and effectively a single-maintainer bus factor. You would be the only party validating the security behavior of code that decides who can see what.
• You require support commitments, SLAs, CVE responsiveness, or a maintenance roadmap — none of which a package with zero dependents can credibly offer.
• Your platform strategy is to standardize on the framework's idioms: Laravel's native Gate/Policy plus a mature role/permission package gives you documentation, hiring familiarity, ecosystem integration, and an order of magnitude more production exposure.
• You need policy externalization — decisions evaluated by a dedicated engine (OPA/Rego, Cedar, or a hosted authorization service) so policy can be versioned and audited independently of application deploys, or so multiple services share one decision point.
• You are buying for the long term and need an ecosystem signal — integrations, tutorials, community answers, a track record of Laravel major-version upgrades. Sparse stars and recent-but-isolated releases don't establish that.

Adoption gate (non-negotiable if we proceed): confirm supported Laravel/PHP versions, inspect test coverage and CI, run a dependency and license audit, perform a focused security review of the decision path and any caching, and document a fallback plan to native Gate/Policy. Without those, this is a spike input, not a dependency.

How to Pitch It (Stakeholders)

To executives: Fine-grained authorization — roles, sharing, and context-aware rules — is the gate on our enterprise roadmap and on deals that pass security review. We evaluated an open-source library that models all three paradigms in one place. The capability is exactly aligned with where we're going; the package is not yet a safe dependency — it has essentially no adoption (1 star, 0 dependents) and a single maintainer, and authorization is security-critical code where we'd be the only reviewers. Recommendation: fund a short, time-boxed spike to extract the design patterns and pressure-test our own policy model, and build the production layer on Laravel's native authorization primitives behind an internal interface. This captures the learning at low cost, avoids a maintenance and security liability, and keeps the door open to adopt a dedicated engine later if requirements grow.

To engineering: Treat this as a reference implementation, not a dependency. Two-day spike: implement one real scenario (org roles plus per-resource sharing) both ways — this library and native Gate/Policy — and compare policy expressiveness, testability, query performance for "list what I can see" cases, and migration cost from our current checks. If we ever do adopt it, it gets vendored and forked, wrapped behind an AuthorizationService interface with our own test suite, and pinned — never called directly from controllers. Report back with a recommendation and a documented exit path.

Ask: Approve the spike and the adapter-first architecture. Defer any build-vs-buy commitment until we have the comparison data, and treat "advanced permissions" as a roadmap item gated on that decision rather than on this package.