Peep Laravel Package

Product Decisions This Supports

• Build vs. buy for local developer observability. Peep covers a large slice of what teams currently assemble from Laravel Telescope, Clockwork, Ray, Mailtrap/MailHog, Twilio/Mailgun test credentials, and ad-hoc dd()/var_dump() — as a single self-hosted, opt-in toolkit. The decision is no longer "should we build a debug tool" but "which one do we standardise on."
• Spend on third-party dev services. Local mail catching (SMTP 23525, Laravel peep mailer, Mailgun-compatible API) and SMS catching (Twilio/Vonage-compatible APIs that answer like the real ones) plus a webhook simulator with provider-valid signatures directly replace paid sandbox accounts for a meaningful share of test workflows — a procurement and compliance decision, not just an engineering one.
• Roadmap input for internal platform/DX tooling. The Laravel adapter's support window (5.5 → 13), the multi-framework bridges (PSR-3, Monolog, VarDumper, plain PHP/Symfony/Slim/WordPress) and the global auto_prepend_file install let you scope "do we build a house debug standard, or adopt one?" across a mixed-version estate — including legacy PHP 7.1 services for the client side.
• Engineering policy and CI gates. The PHPStan rule plus peep-clean / peep:clean turn "don't leave debug calls in the codebase" from a code-review convention into an enforceable gate — a policy decision you can actually put in a PR checklist today instead of writing it yourself.
• Environment and security posture decisions. Production-disabled by default, loopback-first binding, token auth (PEEP_TOKEN / X-Peep-Token) for Docker and remote machines, Host/Origin checks, CSP and sandboxed HTML frames — this is enough to make a deliberate call on whether a debug endpoint is acceptable in staging and shared dev environments.
• Onboarding and support cost. The published wiki, per-framework setup guides, protocol spec and screenshots reduce the "internal wiki page that rots" maintenance burden and shorten ramp-up for new hires and contractors.
• Feature-level decisions it informs: whether to invest in webhook/notification QA coverage (the simulator with delivery log, retries, timed steps and Test button is a testable artefact), how to handle bug reproduction in distributed/Docker/VM setups (path mapping, request ids per job/command, desktop notifications), and whether to standardise team tooling on a desktop app versus browser viewer.

When to Consider This Package

Consider it when:

• You run Laravel (5.5–13) and want zero-config, auto-discovered instrumentation of queries, events, jobs, cache, HTTP client, views, logs, exceptions, mail and dumps without wiring each one.
• Your debugging and integration-testing workflow currently depends on paid SaaS sandboxes (mail/SMS/webhook) and you want that locally, offline, with no payloads leaving the machine.
• You have mixed estates — legacy PHP 7.1 services alongside modern Laravel, or Symfony/Slim/WordPress apps — and want one tool rather than three.
• Developers work in Docker, VMs or against remote hosts, where remote-to-local path mapping and token auth matter.
• You want a guardrail against leftover debug calls (PHPStan rule + cleanup command), not just a nicer dd().
• A pilot team can absorb a v0.x beta with dev-only blast radius and production disabled by default.

Look elsewhere when:

• You need production observability, alerting, retention or SLO reporting — Peep is explicitly disabled in production by default and is not an APM. Pair it with Sentry/OpenTelemetry, don't replace them.
• You require vendor SLAs, support contracts, security review artefacts or a stable 1.x API contract. This is 0.1.0-beta.1; expect churn, especially in the protocol and config surface.
• The viewer's PHP 8.5 requirement is a blocker for your team's machines and CI, and you can't rely on the bundled PHAR/desktop app to sidestep it.
• Your team is already productive on Ray/Clockwork/Telescope with established muscle memory and you have no mail/SMS/webhook sandbox pain — the switching cost likely exceeds the gain.
• Your bottlenecks are front-end/JS or infrastructure-level, where PHP-side cards add little.
• You need a hosted, multi-developer shared view of activity (team dashboards, cross-machine aggregation) — this is a local, per-machine tool.

How to Pitch It (Stakeholders)

To executives (one paragraph): Peep is a free, self-hosted developer debugging tool for PHP and Laravel that replaces a handful of paid sandbox and debugging subscriptions — mail, SMS and webhook testing in particular — while keeping all data on the developer's machine. It reduces the time between "a bug is reported" and "an engineer can see exactly what happened," and it ships with a lint rule that prevents debug code from reaching production. Cost of adoption is low: it's opt-in, off by default outside development, and can be piloted by one squad in a single sprint with no production exposure. The trade-off is maturity: it is a first beta, so we treat it as a developer-productivity experiment, not infrastructure we depend on.

To engineering leadership: Auto-discovered Laravel integration across 5.5–13, broad framework bridges for the rest of the estate, and near-zero overhead when the viewer isn't running (closed viewer skipped for 30s, ~3 ms per 100 calls). The differentiators versus Telescope/Clockwork are the mail/SMS/webhook catching and simulation, the ability to flip query-debugging switches live in a running app, and the leftover-call linting — the last being the thing that usually kills internal adoption of debug tooling.

To the pilot team / sceptics: Everything is opt-in and development-only, the viewer binds to loopback and requires a token before it listens beyond it, and there's a documented protocol and setup guides so it isn't a black box. If it doesn't earn its place in one sprint, removal is a config change.

The ask: one squad, one sprint, three success measures — time-to-reproduce on reported bugs, reduction in third-party sandbox/test-credential usage, and elimination of leftover debug calls in diffs. Revisit at 1.0 or when the PHP 8.5 viewer requirement is no longer an outlier.