Performance Laravel Package

Product Decisions This Supports

• Build vs. buy for performance instrumentation. This package answers the cheapest version of "do we need an APM tool?" — it gives time, memory, and DB query measurement in web, console, and CLI contexts for the cost of a Composer dependency. That makes it a legitimate first rung on the ladder before committing budget to Datadog, New Relic, or a self-hosted stack.
• Whether to add performance budgets to CI. Because it exposes measurements programmatically, it supports the roadmap decision to gate merges on query counts or memory ceilings for hot paths (e.g., "no endpoint exceeds 40 queries"), rather than treating performance as a post-launch cleanup item.
• Where to invest optimization sprints. The DB query counter is the highest-signal output for typical Laravel apps — N+1 detection is where most real-world wins live. Use it to prioritize backlog items with evidence rather than intuition.
• Scope decisions on internal tooling. A concrete input to "do we build an internal perf dashboard?" — the answer is often no, if a lightweight analyzer plus existing logs covers the need.
• Feature-level tradeoffs. Comparing two implementations of a search endpoint, an export job, or a queue worker: run both under the analyzer in staging and decide on measured memory/time rather than code review opinions.
• Client-facing or stakeholder reporting for agency/consultancy work. Produces simple, defensible before/after numbers ("p95 query count down 62%") without a paid monitoring contract.

When to Consider This Package

Adopt it when most of these hold:

• You have a Laravel or plain Composer PHP codebase, and you want one tool that covers HTTP requests, artisan/CLI commands, and web-console invocations.
• You are working in development, staging, or CI — not high-traffic production. The measurement approach is request-scoped and output-oriented, not a sampling agent.
• You want zero infrastructure: no daemon, no external service, no database schema for metrics. This matters for small teams, on-prem/air-gapped deployments, and projects with restrictive vendor review.
• License compatibility is a constraint — Apache-2.0 is permissive and safe for commercial and redistributed work.
• You need something this sprint, not a three-week observability rollout.

Look elsewhere when:

• You need production APM at scale: distributed tracing, sampling, long-term retention, alerting, dashboards, anomaly detection. Laravel Telescope and Clockwork cover the dev-time debugging space more deeply; Sentry, Datadog, New Relic, or OpenTelemetry-backed stacks cover production.
• You need historical trend data across releases. This class of tool reports on the current run; it doesn't store history for you.
• Maintenance risk tolerance is low. 520 stars and a single-maintainer profile is a real signal. The low opportunity score (~1.6) reflects a crowded, well-served category — Telescope, Debugbar, Clockwork, and Blackfire all sit nearby. That's good for buyers (options exist) and bad for this package's long-term differentiation. Pin the version, wrap it behind your own interface, and assume you may swap it out.
• Overhead is non-negotiable, e.g., a latency-sensitive service where even dev-mode instrumentation changes behavior you're trying to measure.
• The team already standardized on an observability vendor. Adding a second, partial signal source creates more confusion than insight.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, low-risk trial of performance visibility. Apache-2.0 licensing removes legal friction, there's no vendor contract or infrastructure spend, and it can be evaluated in days. The realistic payoff is fewer slow-page incidents and better-targeted optimization work — not a replacement for production monitoring. Frame it as a one-sprint experiment with a defined exit criterion, not a platform commitment.

For engineering: Install via Composer, register the Laravel service provider, and you get time, memory, and query-count measurement across web requests, console commands, and CLI. The practical uses are N+1 detection in staging, memory profiling for queue workers and long-running commands, and CI assertions on query/memory budgets for critical endpoints. Caveats to state plainly: single-maintainer project in a saturated category, so isolate it behind an internal facade and pin the version; treat it as dev/staging tooling and keep it out of the hot path in production. If it proves useful, the natural upgrade path is Telescope/Clockwork for debugging depth and an OTel-compatible vendor for production.