Modelo Bundle Laravel Package

Product Decisions This Supports

• Framework-fit gate before any build commitment. The dominant finding a PM needs is that lexik/modelo-bundle is a Symfony bundle built on Doctrine ORM, not a Laravel package — no service provider, no Eloquent integration, no package discovery. If the consuming product is Laravel-first, this is not a "low-scoring option to weigh," it is out of scope. The decision it supports is to close the evaluation as not-applicable and re-open the underlying requirement (dynamic/admin-managed schema, model scaffolding, request-shaping) against Laravel-native options. Spending roadmap time here is a sunk cost.
• Build vs. buy for model/domain plumbing — only if the stack is Symfony. The package offers base models, managers, and behaviors (timestamps, blameable) that reduce boilerplate between domain logic and persistence. That is a real, if modest, build-vs-buy line item for a Symfony service: adopt a thin community bundle from a known Symfony vendor (Lexik) versus writing and owning a small internal abstraction. Signals point toward "buy is cheap, but ownership risk is comparable to build": 1.0.x, 1 GitHub star, 0 dependents, single visible maintainer.
• Whether to treat dynamic model definition as a product capability or an implementation detail. Modelo's runtime model/field layer means schema lives in data rather than migrations. That is a product-level trade: it buys admin-configurable content and flexible onboarding, and it costs migration-review discipline, index control, and query-plan predictability. This decision should be made on product grounds (do we need user-configurable schemas?) — not as a side effect of picking a dependency.
• Dependency risk register entry. v1.0.2 (2025-06-02) is a single chore(deps): update to SF7 commit — a compatibility declaration, not investment. Correct read: "still alive, not thriving." Log as an accepted risk with a named owner and exit path if adopted; do not let it touch a core domain path.
• Roadmap impact: none. Nothing in this release changes user-facing capability. It should not move priorities; at most it changes the cost/risk of an internal plumbing choice inside a Symfony estate.
• Non-decision worth recording explicitly. "We evaluated this and it doesn't fit our stack" is a legitimate, cheap outcome that prevents the same package resurfacing in future technical spikes.

When to Consider This Package

Consider it when:

• The consuming service is already on Symfony 7 (PHP 8.2+) or is executing a 6.4 LTS → 7.x migration. v1.0.2 is precisely the release that removes the framework-version blocker, so any earlier "no" on compatibility should be re-evaluated — and any earlier "yes" was untested against SF7.
• You want convention-over-configuration model/entity plumbing sourced from an established Symfony shop rather than an internal one-off, and the integration surface is small and reversible (a few models, wrapped behind your own interface so a swap is contained).
• You can pin the version explicitly and absorb an upstream stall by forking or vendoring.

Look elsewhere when:

• The stack is Laravel. This is the primary exclusion. A bridge would have to reimplement DI wiring, Doctrine coupling, and the runtime model metadata layer — that is a build project wearing an integration's clothes. Route the requirement to Laravel-native patterns (config-driven schema packages, JSON-column designs, an admin/CRUD package) instead.
• You need active feature development, an LTS commitment, or a security-response SLA. Chore-only releases plus a single maintainer plus near-zero community adoption is a maintenance signal, not a support commitment.
• The package would become load-bearing for core domain logic. Low upstream velocity on a core path is the combination to avoid.
• Your workload demands strict schema governance, auditability, heavy reporting, or predictable query plans. Runtime model definitions trade all four for flexibility, and the cost shows up in production months later.
• You are not on Symfony 7 and have no 7.x plan — there is no other reason to take this release.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated a small open-source PHP library, lexik/modelo-bundle, as a possible way to reduce boilerplate in our data/model layer. The headline finding is a scope mismatch: it is a Symfony component built on Doctrine, and our product is Laravel-based. Adopting it would mean running two PHP frameworks side by side — a multi-week engineering cost to avoid a few weeks of routine scaffolding work. The library itself is fine but thin: version 1.0, one GitHub star, no downstream users, and its most recent release was a single dependency bump to declare Symfony 7 support. Recommendation: close this evaluation as not-applicable to our stack, and route the underlying need — flexible, admin-managed data models — into a Laravel-native solution. This costs us nothing now and prevents the same package resurfacing in future build-vs-buy discussions.

For engineering (short): v1.0.2 is a constraint-only change adding Symfony 7 support — no API changes, no features, no security content. Since we are Laravel-first, this is not adoptable without a bespoke bridge that reimplements DI wiring, Doctrine coupling, and the runtime model-metadata layer. Do not prototype it. If a Symfony service does exist in the estate, the correct sequencing is to land the constraint bump inside the same change window as the Symfony major, and to test the transitive dependency graph (PHP 8.2 floor, Doctrine ORM major) rather than the one-line diff — a constraint bump without a matching CI row is an untested claim. In either case, pin explicitly, keep any integration behind our own interface, and do not place it on a core domain path; at this version and activity level a six-month release gap is credible, so name an internal owner and a fork/replace exit path up front.

Ask: approve closing this evaluation (≈0 cost), and let us spend the reclaimed time scoping the Laravel-native alternative for dynamic/admin-configurable schema — that is where the actual product value sits.