Pangolin.symfony Laravel Package

Product Decisions This Supports

• Build vs. buy for admin/CRUD surface area. This bundle is glue between Geeks Ltd's Pangolin framework and Symfony — the kind of thing that exists to auto-expose entity management (list/detail/create/update plus API endpoints) rather than to be a general-purpose library. If the decision on the table is "do we hand-write our back-office CRUD and REST layer, or adopt a framework that generates it from the model," this is a candidate in that evaluation — not a candidate for anything else.
• Framework-standardisation decisions. Relevant if the org is weighing a single house convention for entity modelling + API exposure across .NET and PHP stacks. Pangolin's lineage is a multi-language enterprise framework, so the bundle is really an argument about vendor/framework alignment, not about a discrete feature.
• Roadmap de-risking for internal tooling. The realistic use case is internal admin panels, data-maintenance screens, and thin back-office APIs for a Symfony app that already owns a Pangolin-shaped domain model. It shortens time-to-first-screen; it does not shorten time-to-production-hardening.
• Not a fit for: public-facing product surfaces, anything needing a supported upgrade path, or a Laravel codebase. Note the mismatch explicitly — this package targets Symfony, not Laravel. If the brief was "Laravel/PHP package," the evaluation is already off-target; treat that as a signal about how precisely the candidate was scoped.

When to Consider This Package

Consider it only when all of the following hold:

• You are already a Pangolin shop — the domain layer, entity conventions, and (likely) the vendor relationship exist independently of this bundle. The bundle's value is almost entirely derivative of that prior commitment.
• The application is Symfony, on a version this bundle's 2022-era constraints still permit. Verify the composer.json Symfony constraint against your target LTS before anything else; a 2022 freeze likely predates your framework version.
• The scope is internal or low-blast-radius (back office, ops tooling, partner-facing thin API), where you can accept maintaining glue code yourself.
• Someone on the team can read the bundle's source and own it, because that is what you will be doing.

Look elsewhere — and expect to — when any of these are true:

• Adoption signal is the deciding factor. Zero stars, zero dependents, no release since October 2022. That is not "early"; that is "unmaintained and unvalidated." There is no community to catch regressions, no third-party tutorials, no Stack Overflow corpus, and no evidence anyone outside the originating organisation has shipped it.
• You need a support contract or security-response commitment. A single-vendor artefact with a two-year-plus release gap cannot offer one, and the vendor has no incentive to prioritise your bug.
• The team is not already on Pangolin. The onboarding cost is the framework, not the bundle; the bundle compounds it without offsetting it.
• You are on Laravel. Different framework, wrong tool. Evaluate the equivalent in your actual stack (API Platform, EasyAdmin, Filament, Nova, Craftable) — those carry the adoption, docs, and maintenance this does not.
• Succession risk matters. If the vendor pivots, the bundle is orphaned and your CRUD layer is now bespoke code you didn't plan to write.

How to Pitch It (Stakeholders)

To executives: This is a narrow integration package from a UK software consultancy that bridges their Pangolin framework to Symfony. We should not adopt it as a standalone dependency. The public signals — no release in over two years, no external adopters, no community — mean that if we build on it, we own it, including security patches and framework upgrades. The only defensible case is if we are already committed to Pangolin commercially, in which case the bundle is a cheap accelerant for internal back-office screens, and its cost should be folded into that existing vendor decision rather than presented as a new one. Recommendation: do not adopt; treat it as a data point in a broader framework-standardisation conversation.

To engineering: It's an unmaintained Symfony bundle that generates entity-facing CRUD/API from a Pangolin domain model. Before spending any time on it: confirm it installs against our Symfony version, confirm there is a maintainer we can escalate to, and confirm we're willing to fork it. If the answer to any of those is no, stop and use a maintained alternative — API Platform or EasyAdmin if we're on Symfony, Filament or Nova if we're on Laravel. The realistic worst case is that we inherit an integration layer with no upgrade path and a single author's assumptions baked into our entity conventions, which is expensive to unwind later.

Framing for the decision meeting: the question is not "is this package good?" it is "are we already a Pangolin organisation?" If yes, pilot it behind internal-only surfaces with a documented fork plan. If no, this is a no, and the useful output of the evaluation is the list of maintained alternatives we compared it against.