Laravel Tracker Laravel Package

Product Decisions This Supports

• Audit trail / "who changed what, when" as a platform capability: satisfies compliance evidence needs (SOX, HIPAA, ISO 27001, GDPR accountability), customer support forensics ("why did this record change?"), and internal admin accountability without bespoke work per team.
• Change history as a user-facing feature: version history, before/after diffs, and restore flows in admin panels and customer-facing portals — a common enterprise-tier differentiator and a frequent RFP checkbox.
• Incident response and debugging: reconstruct the state of a row at a point in time during post-mortems; complements request-level logs and APM, which don't capture row-level state.
• Build vs. buy vs. OSS-adopt for observability: gives a concrete candidate to benchmark against spatie/laravel-activitylog and owen-it/laravel-auditing on features, maintenance, and total cost of ownership.
• Roadmap sequencing: if an audit capability is a compliance gate for a launch or enterprise deal, this forces it from "nice-to-have" into a dated deliverable; if it's only for debugging, existing logs/Telescope may cover most of the need at zero cost.
• Packaging and pricing: retention windows, export, and per-tenant audit views are natural paid-tier levers.

When to Consider This Package

Consider it when:

• You are on Laravel 8 / PHP 7.4–8.0 (its 2021 vintage) or are willing to fork and maintain it yourself.
• You need a minimal, trait-based tracker for a handful of low-risk internal models and want something working in a day.
• You are prototyping and explicitly accept the migration cost later.

Look elsewhere (or build) when:

• Compliance or legal exposure is real. One maintainer, ~12 stars, and no release since January 2021 is no evidence of CVE response, Laravel 10/11 compatibility, or a security policy. Unmaintained code on an audit path is a finding waiting to happen.
• You need field-level diffs with actor, IP, user agent, request context, tenant isolation, queued writes, retention/partitioning, PII redaction, or a query UI. spatie/laravel-activitylog and owen-it/laravel-auditing cover these and are actively maintained.
• You need tamper-evidence (append-only, hash-chained). No OSS Eloquent package gives you this; that's event sourcing or a dedicated audit service.
• Volume is high (roughly >10M rows/year) — you want CDC, temporal tables, or a warehouse sink, not an Eloquent observer writing to the primary database.

Adoption checklist before committing: verify the Laravel/PHP support matrix, read the generated migration, confirm behavior on bulk query()->update(), soft deletes, and transactions (observers miss these), decide sync vs. queued writes, and model storage growth and retention.

How to Pitch It (Stakeholders)

For executives: This is a small open-source audit-log package for Laravel. It would let us answer "who changed this record, and what did it look like before?" — useful for compliance evidence, support forensics, and enterprise security questionnaires. The upside is roughly a day of integration versus weeks of building. The risk is that it is effectively unmaintained: last release January 2021, ~12 stars, a single maintainer, no visible security process. It should therefore not sit on a compliance-critical path. Recommendation: fund a short spike (3–5 days) to validate it against our Laravel version; default to a maintained alternative or a small in-house observer if the spike shows friction. Either way, budget ongoing ownership and cap retention to control storage cost.

For engineering: The value proposition is a trait plus a migration that records model events — low integration cost, small API surface, easy to fork. Before adopting, verify compatibility with our Laravel/PHP versions, confirm it captures actor and request context (or plan to add it), and check behavior on bulk updates, soft deletes, and transactional writes. Treat it as a starting point we may own, not a long-term dependency.