Laravel Tenancy Scout Laravel Package

Product Decisions This Supports

• Laravel 11 upgrade planning. The 0.4.0 release is a compatibility release: the package now runs on Laravel 11. That makes it a candidate to carry forward through a framework upgrade instead of being replaced. For a PM, this is the deciding input on whether the package stays on the "migrate" list or moves to the "replace during upgrade" list — it removes a forced rip-and-replace during the Laravel 11 window.
• Build vs. buy (buy/borrow, in this case). A pre-1.0 open-source dependency is cheap to adopt and cheap to drop, which argues for adopting it behind a seam rather than building equivalent behavior in-house. It does not argue for building product surface directly on its API — see the stability caveat below.
• Roadmap sequencing. Because compatibility work is still landing at 0.4.x, the package is in active maintenance but not API-stable. Sequence dependent roadmap items after a 1.0 signal, or budget for a migration spike when 1.0 arrives.
• Scoping pilots and internal use cases. Best first use is internal tooling, admin/ops surfaces, and non-customer-facing paths where a breaking change is a sprint task rather than an incident. Customer-facing or contract-bound surfaces should wait for a stability commitment.

Stability caveat to carry into every decision: at 0.x, semver permits breaking changes in minor releases. The 0.4.0 notes show only additive changes, which is a good signal, but it is not a guarantee. Treat the public API as provisional until 1.0.

When to Consider This Package

Consider adoption when:

• You are on, or actively migrating to, Laravel 11 — this release is the gate, and it is now open.
• The capability is genuinely peripheral to your differentiation. If it is core to the product, a 0.x dependency is the wrong risk profile regardless of quality.
• You can place it behind a thin adapter or interface (one or two files) so an API change in a 0.x minor is a contained edit, not a refactor.
• You have verified the package's actual scope, test coverage, license, and maintainer activity — none of which the release note speaks to, so this is a required diligence step before, not after, adoption.
• The alternative is writing and maintaining equivalent behavior yourself, and that cost exceeds the cost of tracking a fast-moving dependency.

Look elsewhere when:

• You are pinned to Laravel 10 or earlier and cannot upgrade. Compatibility work here is forward-looking only; there is no indication of a backport policy, and 0.4.0 gives no reason to assume one.
• You need API stability as a procurement or architecture requirement. Pre-1.0 with a single maintainer-shaped release cadence is a poor fit for regulated, security-critical, or multi-year-support commitments.
• The package would sit on a critical path with no fallback. A 0.x dependency on the hot path means an upstream minor release can become your incident.
• You cannot get comfortable with maintenance signals during diligence — release frequency, issue responsiveness, and whether 0.4.0's Laravel 11 support arrived before or after Laravel 11's own support window closed. Arriving late is a mild negative signal about cadence.

How to Pitch It (Stakeholders)

For executives (30 seconds): We are evaluating a small open-source Laravel component at version 0.4.0. Its latest release adds Laravel 11 support, which keeps it viable through our framework upgrade rather than forcing a replacement. Cost is zero and commitment is zero — it is MIT-style open source with no contract. The trade-off is maturity: pre-1.0 software can change its interface between minor versions. Recommendation: approve it for internal and non-customer-facing use behind a thin wrapper, and defer any decision to standardize on it until it reaches 1.0 or until we have run it in production for a quarter without upstream surprises.

For engineering: The 0.4.0 change is additive — Laravel 11 compatibility, no breaking changes, no deprecations announced. That is the only thing this release tells us; it does not speak to test coverage, security posture, or the maintenance roadmap. Two asks before we adopt: (1) pin the exact version and let the lockfile carry it, and (2) wrap the public API behind a single adapter class so a 0.x minor bump is a one-file change. Add a CI job that runs against Laravel 11 so we find the next compatibility break before a customer does. If either ask is a poor fit for the codebase, that is itself the answer — we should not adopt.