Easy Model Laravel Package

Product Decisions This Supports

• Build vs. buy for query-layer ergonomics: v2.1.0 moves this package from "small helper" to a plausible query-layer standard for Laravel apps, so the decision is now a real comparison against alternatives (Spatie's laravel-query-builder, hand-rolled scopes, repository layers) rather than against nothing. Still a developer-productivity decision, not a strategic platform bet.
• Roadmap acceleration for internal tools: The release substantially widens the covered backlog for admin panels, internal dashboards, CRUD screens, and MVPs — request-driven filtering/sorting/includes/search, eager loading, selections, all three pagination styles, soft-delete lifecycle, and mass writes. This is the strongest roadmap argument the package has had.
• API contract and standards decisions: fromRequest() plus allowedFilters()/allowedSorts()/allowedIncludes()/allowedSearch() means query parameters become a public interface. The PM decision is whether that interface is internal-only or exposed to customers, and whether allowlists are mandatory by policy.
• Risk tiering of the write path: restore(), forceDelete(), performInsert(), performUpsert(), and usingModelEvents() touch destructive and observer-sensitive behavior. Treat read-path adoption and write-path adoption as separate decisions; the read path is far easier to reverse.
• Security and abuse-surface scoping: User-driven query shape introduces cost and data-exposure questions (expensive relation includes, sorting on unindexed columns, unfiltered search). The PM decision is whether the package's allowlist model is sufficient governance or whether the team needs an additional policy layer.
• Dependency governance: The new Orchestra Testbench/PHPUnit suite materially improves the diligence picture and directly addresses a prior objection. It does not resolve the small-community concern (11 stars, 0 dependents), so adoption remains a monitored, pinned, wrapped dependency.
• Upgrade cost: v2.1.0 reads as purely additive with no listed breaking changes, so a team already piloting can upgrade cheaply — useful when arguing for a time-boxed pilot over a full commitment.

When to Consider This Package

Consider it when:

• The product is a Laravel-only application with repetitive query-management code, and this package demonstrably replaces more boilerplate than it adds.
• The near-term work is internal tools, admin panels, prototypes, or MVPs where the new request-driven querying, pagination, and soft-delete support map directly onto the backlog.
• You need standardized, whitelisted filtering/sorting/includes and prefer an integrated package over assembling one — but validate it against Spatie's query builder on maturity, documentation, and community support before choosing.
• Engineering can time-box a spike, now with the benefit of a real test suite to read, and measure against plain Eloquent/query-builder baselines.
• Adoption is wrapped behind an internal interface, with write-path features (performUpsert, forceDelete, usingModelEvents) explicitly out of scope for the first phase.
• The team can pin a version, monitor maintenance, and document a removal path; a pinned minor upgrade is low-risk given the additive changelog.

Look elsewhere when:

• The work is production-critical, security-sensitive, compliance-related, or performance-sensitive, or involves complex reporting, analytics, multi-database support, or long-lived domain logic.
• The query surface would be exposed to untrusted clients without a team-owned allowlist policy on top of allowedFilters()/allowedIncludes() — relation includes and keyword search are easy to abuse.
• You need established community support, long-term maintenance guarantees, or hiring-friendly patterns. The test suite helps; 11 stars and 0 dependents still mean bus factor risk.
• Another query-layer package is already standardized — switching costs likely exceed the marginal gain.
• Release metadata still cannot be verified. The previously flagged release date (2026-09-11) remains an open diligence item until confirmed against the repository; treat the changelog link as the source of truth to check.

How to Pitch It (Stakeholders)

For executives: This is a small Laravel developer utility that has matured into a credible convenience layer for internal tools and admin panels — it now covers filtering, sorting, pagination, soft deletes, and bulk writes, which are common sources of repetitive code and delivery drag. It remains a low-adoption dependency and is not a strategic platform investment. Recommendation: fund a short, low-cost engineering evaluation on one internal feature, read-path only, and adopt only if it shows measurable delivery gain with acceptable maintenance and security risk.

For engineering: The v2.1.0 release is additive, so upgrade cost is low, and the addition of an Orchestra Testbench/PHPUnit suite removes the "no tests" objection. Scope the spike to the read path: fromRequest() with explicit allowlists, eager loading and pagination, and toSql() for query inspection. Keep performUpsert(), forceDelete(), restore(), and usingModelEvents() out of the pilot until the write path has been reviewed separately. Success criteria: reduced boilerplate versus plain Eloquent, no debugging or observability regressions, verified Laravel/PHP compatibility, a mandatory-allowlist pattern documented for any request-driven endpoint, clean licensing, and a removal path behind an internal interface. Report the outcome as adopt / wrap-and-monitor / keep internal conventions.