Tomato Roles Module Laravel Package

Product Decisions This Supports

• Build vs. buy for RBAC (role-based access control): This package is a pre-built roles/permissions layer for Laravel + Filament admin panels, bundling the role/permission model, admin CRUD screens, and user-role assignment UI. The core product decision it informs is whether access control is a differentiator worth engineering time or a commodity capability to adopt off the shelf.
• Feature scoping — permissions and roles: Supports go/no-go on shipping granular role management (roles, permissions, role-permission mapping, user assignment) in an internal tool, back-office, or admin panel without a custom sprint. This directly affects roadmap sequencing for any milestone gated on "admin can control who sees what."
• Multi-tenant / enterprise readiness: Role and permission management is a common procurement checkbox for B2B and enterprise tiers. Adopting this accelerates the path to a sellable "admin & access management" capability, which shapes pricing-tier and packaging decisions.
• Time-to-market for admin surfaces: Because it plugs into the Filament/TomatoPHP ecosystem, it reduces the surface area of custom admin UI work — a lever for release-date commitments on internal tooling and back-office milestones.
• Ecosystem lock-in trade-off: Choosing this commits the team to the TomatoPHP/Filament conventions for access-control UI. That is a product-level architectural decision (vendor/ecosystem alignment), not just a developer preference, and should be weighed against long-term maintainability and hiring.
• Release cadence signal: v1.0.3 is a patch release whose changelog contains only a diff link with no described breaking changes, features, or deprecations. It is low-signal: it does not change the adoption case, but it does confirm the package is being maintained at the patch level. Do not treat it as evidence of active feature investment.

When to Consider This Package

Consider adoption when:

• The product runs on Laravel and the admin surface is (or will be) Filament-based; the package's value is concentrated in its pre-built Filament resources for roles and permissions.
• Access control is commodity, not differentiating — you need standard roles, permission sets, and user assignment, not a novel authorization model.
• You are time-constrained on an internal tool, back-office, or MVP and can accept ecosystem conventions in exchange for weeks of saved build time.
• The team is already inside the TomatoPHP plugin ecosystem and consistency across modules outweighs the cost of a less-mainstream dependency.
• You need a working admin UI for RBAC quickly and are comfortable extending or overriding it later.

Look elsewhere when:

• The authorization model is non-standard (attribute-based, policy-heavy, hierarchical/organizational-scoped permissions, row-level security) — a generic roles module will fight you.
• The stack is not Filament, or the admin panel is custom/Inertia/Livewire without Filament — most of the value evaporates and you are left with a thin wrapper you could replicate.
• Long-term maintenance and vendor risk are high priorities: a single-maintainer, ecosystem-specific package should be covered by your own tests and a fork/exit plan before it becomes load-bearing.
• You already use Spatie's permission package directly with a bespoke UI — adopting this may duplicate rather than replace.
• Compliance/audit requirements demand documented provenance, security review, or an actively maintained security posture. The v1.0.3 changelog provides no auditable detail and cannot be used as change-management evidence.

How to Pitch It (Stakeholders)

For executives: This is a buy-not-build decision on a standard admin capability. Access control — who can see and do what — is a requirement in nearly every B2B deal and internal tool, but it is not a differentiator. This package gives us working role and permission management inside our Laravel admin panel, including the screens our operations team uses to assign access, without a custom build. The trade-off is ecosystem dependency: it fits our stack today and lowers near-term cost and time-to-market, and we should budget a small amount of engineering ownership (tests, a fork path) so it never becomes a single point of failure. The latest release, v1.0.3, is a routine patch with no breaking changes or new capabilities, so it does not alter this recommendation.

For engineering: Treat this as an accelerant for standard RBAC in Filament admin panels, not a foundation for complex authorization. It saves the CRUD and assignment UI work; it does not remove the need for a clear permission taxonomy, seeders, policy design, or tests around privileged actions. Pin the version, review the diff before upgrading (v1.0.3 ships only a compare link, so read the actual changes rather than the notes), and keep authorization logic behind our own service boundaries so swapping or forking the package stays cheap. If our requirements drift toward attribute-based or scoped permissions, plan to replace it rather than extend it.

Recommendation: Adopt for Filament-based admin panels where roles/permissions are commodity. Do not adopt as a strategic dependency for a differentiated or complex authorization model. Re-assess on the next minor release — v1.0.3 alone is not a decision-changing event.