Product Decisions This Supports
- Build vs. buy on authorization logic. The recurring question "do we hand-roll a rules engine or buy one?" gets a concrete, low-cost answer here. The package is a small, single-purpose evaluator: you hand it a nested array like
['AND', ['edit-post'], ['OR', ['is-owner'], ['is-admin']]] and it resolves true/false against a permission set. That is roughly the entire product surface, which makes the buy-side cheap and the build-side estimate honest (days, not sprints).
- Whether authorization rules should be data or code. This is the real product decision the package forces. If permission combinations must be admin-editable, per-tenant overridable, or changed without a deploy, you need rules stored as data — and this package is one way to evaluate them. If rules can live in PHP, Laravel's Gate/Policy already composes AND/OR natively and this package adds nothing.
- Roadmap scoping for RBAC/entitlements work. Use it as a reference implementation when sizing an "advanced permissions" epic. Reading its source tells you the true complexity of nested logic evaluation before you commit engineering to a custom solution.
- Feature gating for plan tiers and workflow approvals. The AND/OR nesting maps cleanly to real product language: "publish if owner AND 2FA enabled," "approve if manager OR (finance AND amount < threshold)." Useful for pricing-tier entitlements, multi-tenant role overrides, and approval chains where the condition set changes per customer.
- Deferring platform-level authorization. If the team is heading toward ABAC/policy-as-code later, adopting a tiny evaluator now (wrapped behind an interface) buys time without locking the architecture.
When to Consider This Package
Adopt only if several of these hold:
- You have permission rules that must be stored in the database or configured per tenant and edited by non-engineers. This is the package's only durable differentiator over Laravel's native Gate.
- You need arbitrary nesting depth (AND inside OR inside AND) and want to avoid writing and testing a recursive evaluator yourself.
- Your team is comfortable reading and owning the source. With 4 stars and zero dependents, there is no community, no ecosystem of answers, and effectively a single-maintainer bus factor. Treat it as vendored code, not a supported dependency.
- The integration cost is acceptable: this is a framework-agnostic PHP library, not a Laravel package. Expect to write your own service provider binding and a
Gate::extend/custom-rule adapter. Budget that work explicitly — it is not zero.
- You can pin a version and wrap it behind an internal
PermissionEvaluator interface so a swap is a one-file change.
Look elsewhere when:
- You just need role/permission checks in Laravel.
spatie/laravel-permission plus Gate policies covers the overwhelming majority of cases with a large community and battle-tested edge-case handling.
- You need a mature expression language (comparisons, arithmetic, custom functions, safe parsing of user-supplied strings). Use
symfony/expression-language — it is maintained, widely deployed, and solves a superset of this problem.
- Compliance or procurement requires vendor viability. A 4-star, 0-dependent package will not survive a security review as a critical-path dependency. Plan to fork or vendor it.
- You are heading toward policy-as-code at scale (cross-service, auditable decisions). Evaluate Casbin, OPA, or AWS Cedar instead of a PHP array evaluator.
- Before deciding at all: verify last commit date, test coverage, and supported PHP versions. Stale PHP support is a near-term upgrade tax.
How to Pitch It (Stakeholders)
To executives (one paragraph): We are evaluating a small open-source component that lets us express permission rules as data — combinations like "owner AND editor, OR admin" — instead of hard-coding each one. The business value is speed of change: authorization rules could be updated through configuration rather than a release, which matters for enterprise customers who want custom roles and approval chains. The component itself is tiny and free (MIT), but it is unproven — four GitHub stars and no downstream users — so the recommendation is a short spike, not a commitment. Worst case we spend a few days and reuse the design; best case we avoid building a rules engine ourselves.
To engineering (the honest version): This solves expression evaluation and nothing else. No Laravel integration, no persistence, no caching, no UI — you own all of that. It is a few hundred lines of recursive array walking, so the real question is whether we want to own that logic or write it. Recommend: timeboxed spike, wrap it behind an internal interface, pin the version, and write our own test suite around the behaviors we depend on rather than trusting upstream coverage. If the spike shows the adapter work exceeds the evaluator work, we build it in-house or adopt symfony/expression-language.
Positioning to avoid: do not present this as "a permissions system." It is a boolean expression evaluator for arrays. Framing it as a system sets expectations it cannot meet and invites a comparison with spatie/laravel-permission that it will lose.