Lara Bug Laravel Package

Product Decisions This Supports

• Build vs. buy for error monitoring. LaraBug is a tactical answer to "do we build our own exception dashboard, or pay for Sentry/Flare?" It is an MIT-licensed Laravel client that ships exceptions to a LaraBug-hosted or self-hosted dashboard — so it turns a build-vs-buy debate into a host-vs-buy debate. That is a meaningfully cheaper decision to make and reverse.
• Observability maturity roadmap. It establishes the first rung of an error-tracking ladder (capture → group → triage → alert → trace) without committing the team to a full APM platform. Useful as the "Phase 1" item on a reliability roadmap, with a deliberate re-evaluation trigger before Phase 2.
• Data residency and self-hosting posture. For products sold into regulated, public-sector, or on-prem customers, a self-hostable error sink is a procurement unblocker. This package lets you answer "where does error data live?" without re-architecting.
• Launch readiness and MTTR. Gives the team visibility into production exceptions on day one — a prerequisite for any go-live gate, on-call rotation, or post-incident review process. Reduces mean time to detection for a small engineering org at near-zero cost.
• Spend allocation. A credible free/cheap alternative to per-seat or per-event SaaS pricing. Material for pre-revenue or margin-sensitive products, and a useful negotiating lever in vendor renewals even if you don't adopt it.
• Use cases it fits: Laravel-only MVPs, internal tools, agency/client builds where a lightweight hosted dashboard is bundled into handover, and staging/pre-production environments where full APM pricing isn't justified.

When to Consider This Package

Adopt or pilot when all of the following hold:

• The stack is Laravel/PHP and expected to stay that way; you don't need a polyglot agent.
• You have no dedicated SRE/observability owner, and a 30-minute composer-install integration is the realistic bandwidth.
• You need error grouping and triage, not tracing, metrics, profiling, or log aggregation.
• Self-hosting or data residency is a requirement, or SaaS error-tool pricing is a hard blocker.
• You're comfortable treating it as a bounded, swappable component — not a platform bet.

Look elsewhere when:

• You need more than exceptions. Distributed tracing, performance monitoring, release health, session replay, and log correlation are Sentry/Datadog territory. Buying a first-party Laravel SDK with a large support surface is the lower-risk call.
• Ecosystem validation matters. ~297 stars and 0 dependents is thin evidence of production hardening at scale. That is not disqualifying for a small package, but it means you are the QA function. Weigh this against Sentry's first-party Laravel integration.
• You have compliance or SLA obligations. No evidence here of SOC 2, HIPAA, penetration testing, uptime SLAs, or a security disclosure process. If your customers ask those questions, this is not the answer.
• You need vendor durability. Assess maintainer concentration (bus factor), release cadence against new Laravel majors, and whether the hosted service's roadmap is independent of the client package. Verify these before standardizing.
• High event volume. Confirm sampling, rate limiting, and payload-scrubbing behavior — exception payloads routinely capture request parameters and user context, which is a PII exposure you must control.
• You need mature alert routing. PagerDuty/Opsgenie-grade escalation, deduplication, and ownership rules are out of scope for a package this size.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, low-commitment way to stop finding out about production errors from customers. It plugs into our existing Laravel codebase in under an hour, gives us a dashboard of what's breaking and how often, and can be self-hosted so error data — which can contain customer information — never leaves infrastructure we control. It is not a replacement for a full monitoring platform, and we shouldn't position it as one. Recommendation: a four-to-six week pilot on one production service, with an explicit decision point comparing it against a paid tool on cost, coverage, and operational burden.

For engineering: One composer dependency and a config publish; exceptions flow to a dashboard with grouping, stack traces, and request/user context. MIT-licensed, so forkable if we need to patch. The real engineering work isn't integration — it's (a) scrubbing sensitive fields before they leave the app, and (b) deciding who owns the self-hosted instance if we go that route (backups, upgrades, TLS). Treat it as an interface we can swap: keep the reporting call behind a thin abstraction so replacing it with Sentry later is a config change, not a refactor.

Framing to hold us honest: adopt as a tactical, reversible choice that buys visibility now. The re-evaluation trigger is explicit — either we outgrow exception-only monitoring, or the maintenance and self-hosting overhead exceeds the subscription we avoided.