Laqu Laravel Package

Product Decisions This Supports

• Build vs. buy for queue operations tooling. shimabox/laqu is a small, single-maintainer Laravel package that adds queue management/visibility on top of Laravel's native queue system. It supports the "buy/adopt" side of the decision only when the team's need is basic operational visibility and it is not worth building an internal dashboard or standing up a heavier platform.
• Roadmap sequencing for ops/observability work. Because this is a pre-1.0 package (v0.4.0) with a narrow scope, it is a candidate for a short, time-boxed evaluation spike rather than a committed platform investment. Treat it as a way to defer — not replace — a real observability roadmap item.
• Dependency and platform-lifecycle planning. v0.4.0 drops PHP 7.3 support. This is a hard signal that the package tracks upstream PHP EOL policy rather than legacy environments, and it forces an explicit answer to "what PHP version do our production and CI targets run?" before adoption.
• Feature-scope validation. The release contains no new capabilities — only a platform-support change. That tells us the package's feature surface is stabilizing at a small footprint, which is good for risk and bad for anyone hoping it will grow into a Horizon-class solution.
• Upgrade-cost estimation for already-interested teams. For anyone who spiked v0.3.x, this is a contained, mechanical upgrade (bump PHP floor, re-run suite), not a migration project.

When to Consider This Package

Adopt it for evaluation when:

• The application is on PHP 7.4+ (effectively 8.x for any new work), on a currently supported Laravel release, and uses standard Laravel queues.
• The unmet need is operational visibility and basic queue management, not throughput tuning, autoscaling, or multi-tenant queue orchestration.
• The team accepts a pre-1.0 dependency: no SemVer stability guarantee, breaking changes possible in minor versions (this release is itself an example — a PHP floor bump shipped as a minor).
• The alternative is "do nothing" or "build a small internal tool," and a low-cost, low-commitment layer is genuinely useful.

Look elsewhere when:

• You are on PHP 7.3 or older, or pinned to an older Laravel version — you are now locked out of v0.4.0 and future releases.
• You need production-grade queue observability with a support contract, SLA, or vendor accountability (evaluate Horizon or a managed/APM product instead).
• You require long-term maintenance guarantees. Single-maintainer, pre-1.0 packages are a bus-factor and continuity risk that should be weighed explicitly, not assumed away.
• Queue management is on a critical path where an unannounced breaking change would be costly.

How to Pitch It (Stakeholders)

For executives: This is a small, free, open-source add-on for our Laravel backend that gives engineers better visibility into background job processing — work that currently consumes manual debugging time. It is not a platform commitment: it is pre-1.0, maintained by a single contributor, and carries no support contract. Recommendation is a limited, time-boxed trial scoped to non-critical environments, with a documented fallback to Laravel's built-in tooling.

For engineering: v0.4.0 is a maintenance release that raises the minimum PHP version by dropping 7.3. There are no new features and no deprecations. Practically, that means: confirm our PHP and Laravel targets before evaluating; expect a pre-1.0 dependency where minor version bumps can break compatibility; and budget a bounded spike (not a migration) to assess fit. If our need is deep queue observability, this is not the tool — flag it early rather than growing scope onto it.

Decision requested: approve a time-boxed evaluation, or defer. Do not treat this package as a strategic dependency.