Brandenburg Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-side RBAC. The core decision this package informs is whether to ship a permission management console in the Nova admin panel or hand-roll CRUD screens around Spatie's roles/permissions tables. Brandenburg is a thin UI layer over Spatie Laravel Permission, so the real question is "do we spend engineering days building role/permission screens, or adopt a pre-built one?" The package's value is almost entirely the saved UI work, not new authorization capability.
• Who owns access control operationally. By centralizing role creation, permission assignment, and user-to-role mapping in Nova, it enables a product/support/ops decision: can non-engineers manage entitlements without a deploy? If your roadmap assumes "customer success can grant a beta feature to a customer," this package is a direct enabler; if all role changes must go through code review and seeders, it is not needed.
• Scope of the authorization model. It supports the decision to standardize on Spatie's role/permission primitives (roles as bundles, permissions as atomic capabilities) rather than bespoke is_admin flags or policy-only authorization. That has downstream roadmap consequences: how you express feature gating, plan tiers, and per-tenant roles.
• Roadmap sequencing for multi-role and team features. If near-term roadmap includes team/workspace roles or plan-based entitlements, adopting the Spatie model now (with a UI on top) keeps the door open. Note that Brandenburg covers global roles/permissions; per-tenant or team-scoped permission models typically require Spatie's teams feature and additional work — a decision this package does not solve for you.
• Internal tooling vs. customer-facing surface. It is well suited to back-office/admin use cases where the audience is a handful of internal operators. It is not a decision-support tool for customer-facing permission self-service, delegated administration, or approval workflows.
• Audit and compliance posture. A decision the package does not support: it manages assignments but does not provide an audit trail, approval flow, or change history. If SOC 2 / access-review requirements are on the roadmap, budget for separate logging regardless of whether you adopt this.
• Maintenance vs. replacement calculus. With 94 stars, MIT license, and a last release of September 2020, adoption is effectively a decision to accept an unmaintained (or minimally maintained) dependency and plan for a fork or replacement. That is a legitimate call for internal tooling with a short horizon and a questionable one for a long-lived commercial product.

When to Consider This Package

Consider it when most of the following hold:

• You are already running Laravel Nova (a paid first-party dependency) and are not planning to leave it — the package has no value outside Nova.
• You are already on Spatie Laravel Permission or have decided to adopt it; Brandenburg is additive UI, not an alternative authorization engine.
• Your Nova and Laravel versions are compatible with a 2020-era package — verify this first with a short integration spike, since Nova 4/5 and PHP 8.1+ compatibility is not evidenced by the release history.
• The consumers are internal operators, and the permission model is global roles and permissions rather than per-tenant, per-team, or hierarchical.
• You need something working in days, not weeks, and the alternative is building CRUD screens plus an assignment matrix yourself.
• You are comfortable owning the code if needed — MIT license and a small codebase make forking viable, and you have a named owner for that fork.
• The project horizon is bounded or the risk is reversible — internal admin tooling, an MVP, a migration off a legacy admin.

Look elsewhere (or build) when:

• You are on Nova 4/5 or a modern PHP/Laravel stack and cannot confirm compatibility; a stale Nova tool can break on upgrade and block your framework upgrades, which is a worse outcome than writing the screens.
• You need audit logs, access reviews, approval workflows, or time-bound grants — this is UI over assignments, not a governance product.
• You need multi-tenant/team-scoped permissions, delegated admin, or customer-facing permission management — the model and UI won't carry that weight.
• Abandonment risk is unacceptable — regulated environments, enterprise procurement, or a multi-year product where a 2020 last-release date and single-maintainer profile will fail dependency review.
• You are not on Nova. Adopting a paid admin framework in order to use a free 94-star plugin is a decision that inverts the cost logic; evaluate Nova on its own merits first.
• You expect active support, security patching, or documented upgrade paths — none of that is evidenced here.

How to Pitch It (Stakeholders)

For executives (one paragraph): Brandenburg is a small, free (MIT) add-on that puts a roles-and-permissions screen inside our existing Laravel admin panel, on top of an established open-source permission library. It converts a build task — "give ops a way to grant and revoke access without a deploy" — into a configuration task, plausibly saving several engineering days. The trade-off is maturity: last release in 2020, ~94 GitHub stars, and a small maintainer footprint, so we should treat it as adopt-with-a-fork-plan rather than adopt-and-forget. It manages who has which permission; it does not give us audit logs, approval workflows, or customer-facing access management, so any compliance or self-service roadmap still needs separate investment.

For engineering (the practical case): We're already paying for Nova and already using Spatie's permission tables; this is a UI over data we own, so the blast radius is small and the exit is cheap — the underlying role/permission records stay valid if we drop the UI. Effort is a timeboxed spike: install, confirm compatibility against our Nova/PHP version, and verify the assignment flows cover our model. If the spike passes, we get the screens for near-zero cost and keep the option to fork, since it's MIT and small. If it fails on version compatibility, we write the two or three Nova resources ourselves — that's the fallback, and it's bounded work. Either way, we should not let this package become the reason we can't upgrade Nova or PHP, so we pin it, isolate it behind our own admin tooling boundary, and set a review trigger on the next framework upgrade.