Admin Crud Laravel Package

Product Decisions This Supports

• Framework/vendor fit check — the first decision this surfaces: despite being filed under a Laravel/PHP scan, MWSimple/AdminCrudBundle is a Symfony bundle, not a Laravel package. Any roadmap item that assumed "we can drop this into our Laravel app" is invalid. That alone is a decision-grade finding.
• Build vs. buy for admin back-office: the package represents the "build" end of the spectrum — it generates a thin CRUD controller that extends a shared base ("Super Genial") controller. Useful as a pattern reference when deciding whether to standardize admin controllers on an in-house base class versus adopting a full admin panel.
• Scaffolding velocity / internal-tooling roadmap: for a small Symfony 3/4-era app, a generator like this can compress "entity → list/create/edit/delete screens" from days to hours. That's a real line item in an internal-tooling budget, but a small one.
• Maintenance and dependency-risk register: 20 stars, 0 dependents, last release 2019-04-26. This is a decision input for risk, not for capability — it should be logged as an unsupported dependency if anyone proposes it.
• Feature scoping for a modern equivalent: the high opportunity score (5.32) reflects a genuine, persistent need — boilerplate CRUD/admin generation. In our actual stacks that need is already served (Laravel: Filament, Nova, Backpack, Orchid, make: generators; Symfony: EasyAdmin, SonataAdmin, make:crud). So the opportunity is real; this package is not the vehicle.

When to Consider This Package

Consider it only if all of the following hold:

• The target app is Symfony (not Laravel), on a legacy branch (roughly Symfony 3/4) where the bundle's API still fits.
• The admin surface is internal, low-traffic, low-risk — no PII at scale, no compliance audit trail requirements, no external users.
• You want a throwaway or short-lived scaffold: a prototype, a migration bridge, or a one-off internal tool with a defined sunset.
• The team is comfortable reading Spanish-language docs and vendoring/patching an unmaintained dependency.
• You are explicitly treating it as a reference implementation to copy the base-controller pattern from, rather than as a runtime dependency.

Look elsewhere if any of the following hold — and for most teams, at least one will:

• Any new Laravel project. This is not a Laravel package; there is no service provider, no artisan integration. Use Filament, Nova, Backpack, or plain resource controllers + policies.
• Modern Symfony (5/6/7). Use make:crud from MakerBundle for scaffolding, and EasyAdmin or SonataAdmin for the admin surface. Both are actively maintained and cover auth, permissions, filters, and audit better than a 2019 generator.
• You need maintenance guarantees. Last release 2019, zero dependents, no visible maintenance cadence — no CVE response, no PHP 8.x compatibility commitment, no upgrade path. That's a hard stop for anything customer-facing or long-lived.
• You need authorization, tenancy, audit logging, or workflow. A "very basic controller" is the explicit scope here; none of that is in the box, and you'd be building it on an unsupported foundation.
• You need hiring/onboarding leverage. A 20-star, unmaintained bundle is a bus-factor of one and a knowledge-transfer tax on every new engineer.

How to Pitch It (Stakeholders)

Bottom line for executives: we evaluated this and recommend not adopting it as a dependency. It is a 2019-era Symfony bundle with 20 stars and zero downstream dependents — meaning no one in the ecosystem is betting on it — and it does not target Laravel at all. The underlying need (fast admin CRUD generation) is real and worth funding, but it is already well served by maintained, widely adopted tools in both our Laravel and Symfony stacks. Adopting this would trade a few hours of scaffolding savings for an unmaintained dependency carrying security-response and upgrade risk.

For engineering: the only durable value here is the pattern — a base admin controller that generated per-entity controllers extend, keeping listing/form/delete behavior consistent. That's a design worth copying into an internal base class behind our own tests, on top of a maintained panel (Filament or EasyAdmin) rather than in place of one. If anyone wants to spike it, scope it as a time-boxed read of the source, not a composer require — and keep it out of any branch that ships to production.

Recommended decision: reject for adoption, log as "evaluated — unsupported," and route the underlying admin-scaffolding need into the standard panel selection we already have underway.