Product Decisions This Supports
- Whether "progress transparency" becomes a product feature or stays a support ticket. Long-running batch work — bulk CSV imports, catalog exports, invoice/payroll runs, media transcoding, data migrations, mass emails — is where users currently see a spinner, refresh the page, and email support. This package makes the decision "do we surface per-batch progress in the UI?" a one-sprint question instead of a platform project.
- Build vs. buy for the last mile of
Bus::batch. Laravel already ships batch progress ($batch->progress(), then/catch/finally callbacks). The genuine gap is the broadcast layer. Framing the decision correctly matters: you are not buying a batching engine, you are buying plumbing between batch callbacks and a Pusher channel. That is typically 60–150 lines of in-house code — so this is a "buy to skip a sprint," not a "buy to avoid building a subsystem."
- Realtime infrastructure selection. The package's harder commitment is Pusher, not the code. This decision should be paired with the one about whether the org standardizes on Pusher, Laravel Reverb, or Soketi/self-hosted. Getting progress bars cheap is irrelevant if it drags a paid third-party dependency into a cost-sensitive product.
- Support-cost and CSAT hypotheses. A concrete, testable bet: "realtime batch progress reduces 'is it stuck?' tickets by X% and abandonment on bulk-import flows by Y%." This package is cheap enough to run that experiment and instrument it before committing to a longer roadmap item.
- Prioritization within a release. Because integration cost is low, this is a good "delight" filler for a release that is otherwise all reliability work — provided the team already has broadcasting configured.
- Not a decision it supports: queue observability for engineering (that is Laravel Horizon's job), retry/backoff strategy, or per-item status for partial failures. Scope discipline here prevents scope creep.
When to Consider This Package
Reasonable fit when:
- The app is Laravel 8+ (verify the maintained branch against your PHP/Laravel matrix), already uses queued jobs and
Bus::batch, and already has broadcasting configured — ideally already on Pusher.
- You need a visible progress indicator for one or two user-facing batch flows and want it shipped in the current sprint rather than the next quarter.
- The audience is internal tools, admin panels, or an MVP where a progress bar is a UX nice-to-have with no SLA attached.
- You accept single-maintainer risk consciously: 24 stars, zero dependents, and a thin score signal mean no downstream validation. Read the source before adopting; it is small enough to audit in under an hour, and that audit is the actual due diligence. Check last commit date, test coverage, CI, and whether issues get answered.
- No procurement friction is needed — MIT means legal review is near-zero.
Look elsewhere (or build in-house) when:
- You need durable progress history, audit trails, per-item status, or resumable batches. This broadcasts state; it does not persist a job ledger. That is Horizon, a
job_batches-backed custom table, or a dedicated monitoring tool.
- You are on Laravel 11+ and standardizing on Reverb. Free, first-party, self-hosted realtime undercuts the Pusher-specific value proposition — the package's reusable asset becomes the pattern, not the code.
- Multi-tenant isolation, authorization on channels, or compliance review applies. Private-channel authorization and tenant scoping are your responsibility, and a 24-star dependency will not survive a security questionnaire without you owning the review.
- You need vendor support, an SLA, or a deprecation policy. There is none.
- Scale is large enough that broadcast volume becomes a cost line — a 10,000-item batch firing per-item events is a Pusher bill, not a feature. Throttle to percentage milestones first.
- The team has no broadcasting experience. The install is trivial; the failure modes (channel auth, driver config, Echo setup, SSR/queue-worker context) are not, and they are the same failure modes you would hit building it yourself.
How to Pitch It (Stakeholders)
For executives (one paragraph): Users currently cannot tell whether a long-running bulk operation is working or hung, which drives support load and abandoned flows. This package lets us add a live progress indicator to those flows in roughly a sprint, at effectively zero licensing cost, on infrastructure we may already pay for. The strategic risk is deliberately bounded: it is a small, MIT-licensed, single-maintainer library with no meaningful adoption, so we should treat it as a tactical accelerator, not a platform commitment. Exit cost is near zero — the integration surface is narrow and replaceable in-house — and the decision to revisit is triggered by one of three events: the maintainer going quiet, a Laravel/Pusher upgrade breaking it, or broadcast costs exceeding the support savings. Approved as a scoped experiment with a measurement plan, not as architecture.
For engineering (framing the ask): We are not asking you to adopt a batching library — Bus::batch already does the work. We are asking whether wiring batch callbacks to a broadcast event is worth borrowing versus writing. Please (1) spend an hour reviewing the source and its test coverage, (2) confirm it supports our Laravel and PHP versions, (3) tell us the in-house line count for the equivalent — if it is under ~150 lines and we already have broadcasting, building it may be the better long-term call and the honest recommendation, and (4) confirm whether the Pusher coupling is swappable to Reverb/Soketi without forking. Whatever we choose, we should own the event contract and channel-authorization logic ourselves so a future swap is a config change, not a rewrite.
Success criteria to agree before build: median time-to-complete visible to the user, support tickets tagged "stuck import," and abandonment rate on the instrumented flow — measured against the pre-launch baseline for one release cycle.