Lurkerlite Laravel Package

Product Decisions This Supports

• Instrumentation build-vs-buy. Lurker is a lightweight resource/event recorder for PHP: you sprinkle record calls around expensive or interesting operations (DB queries, HTTP calls, file I/O, cache hits) and later inspect or aggregate what happened. That makes it a cheap way to answer "do we buy an APM vendor, or build/thin-wrap our own instrumentation?" before committing budget.
• Performance roadmap prioritization. Because it gives per-request accounting of resource usage, it supports decisions like "which of these three candidate features is worth optimizing first" and "does this endpoint's cost come from queries or from serialization?" — evidence for sequencing performance work rather than guessing.
• Support and escalation workflow. A recorded trace attached to a bug report ("here are the 40 queries this page ran") turns vague customer complaints into reproducible diagnostics. This can justify investment in a first-class "attach diagnostics" button in admin/support tooling.
• CI quality gates. Recording events in tests enables assertions like "this page must not exceed N queries" — a product decision about performance budgets and regression prevention rather than a tooling decision.
• Feature-level cost accounting. When gating or pricing features, recorded resource usage gives a defensible estimate of marginal infrastructure cost per feature, useful for packaging and margin conversations.
• Architecture spikes, not platform commitments. Given 2 stars and 0 dependents, the realistic PM decision is "time-box a spike / vendor the code," not "make this a load-bearing dependency." MIT licensing makes vendoring or forking a legitimate option, so the decision is about maintenance ownership, not legal risk.

When to Consider This Package

Consider it when:

• You run a PHP application (it fits most naturally in the CiviCRM/Drupal-adjacent world it came from) and want resource accounting without standing up an external observability stack.
• You need development- or test-time instrumentation — profiling a slow admin page, generating diagnostics for a support ticket, or asserting query counts in CI — rather than always-on production tracing.
• You want a small, readable, permissively licensed library you can fork or vendor; the codebase is small enough that a senior engineer can audit it in an afternoon.
• You are evaluating designs for an in-house instrumentation layer and want a working reference for the record/aggregate/report model.

Look elsewhere when:

• You need production-grade, always-on APM with sampling, distributed traces, alerting, and dashboards — OpenTelemetry, Sentry, Blackfire, or Tideways are the appropriate comparison set.
• You need vendor support, SLAs, or an active maintainer community. Two stars and zero dependents (outside its parent ecosystem) is a weak health signal; assume you own any bugs you hit.
• Your stack is polyglot and you need one consistent telemetry model across services.
• You need UI/reporting out of the box; expect to build the analysis and presentation layer yourself.
• Your team has no appetite for owning a fork — if nobody will maintain it, the total cost of ownership exceeds a paid SaaS tool.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed PHP library for measuring what a request actually consumes — queries, calls, I/O. It is not a monitoring product and it will not replace an APM vendor. Its value to us is twofold: it lets us answer "where is this page slow" and "what does this feature cost us to run" without a procurement cycle, and it serves as a low-cost reference design if we later build our own instrumentation. Risk is low (permissive license, small codebase, easy to remove) but so is external validation — minimal adoption and effectively a single maintainer. Recommendation: fund a short, bounded spike in a non-critical path, with a clear decision point on whether to vendor it or buy a commercial tool.

For engineering: LurkerLite is a record-and-analyze layer, not a logger. Expect to add explicit record calls at the boundaries you care about, then write your own aggregation and reporting. That is the trade-off: minimal dependencies and full control, in exchange for no batteries included. Because the license permits it, plan for vendoring or a thin internal wrapper so upgrades are our choice rather than an external dependency. If the spike succeeds, the natural next step is a CI assertion ("no page exceeds N queries") and a diagnostics attachment for support tickets — both cheap, both visible.