Product Decisions This Supports
- Feature: record attribution ("who did this?"). Automatically stamps
created_by, updated_by, and deleted_by on Eloquent models, enabling admin-panel columns, customer-facing "last updated by" lines, and support workflows that answer "who changed this record and when" without custom code per model.
- Roadmap: audit-readiness and data governance. A cheap first step toward SOC 2 / GDPR accountability narratives and internal data-governance epics. It gives you actor attribution now without committing to full event-sourced auditing.
- Build vs. buy (really build vs. adopt). This package is a thin Eloquent trait, not a platform. The real decision is whether to take a dependency on an unmaintained 3-star package (last release Jan 2022, 0 dependents) versus vendoring ~100 lines into the codebase or writing it in-house in under a day. Either way, the capability is a rounding error in cost — the decision is about maintenance ownership, not license or price.
- Prioritization input. Attribution is far cheaper to add while models and schemas are still moving than to retrofit across dozens of tables later. Deciding now whether the product needs lightweight attribution or full field-level audit history (a meaningfully larger investment) shapes the compliance backlog and the admin-tooling roadmap.
- Use cases that justify it: multi-tenant SaaS with staff impersonation, support debugging ("who deleted this order?"), internal ops accountability, migration/backfill provenance, and audit-prep questionnaires that ask how you track changes to sensitive records.
When to Consider This Package
Consider it when:
- You run a standard Laravel app with Eloquent models and a conventional
users auth table.
- You need only who acted and when — not field-level diffs, not a full event history, not retention policies.
- The context is internal tooling, an MVP, or a prototype where speed beats supply-chain rigor.
- You are willing to fork or vendor the source (MIT, small surface area) and own it, rather than treat it as a maintained upstream dependency.
- Your regulatory bar is low and "attribution on records" satisfies the requirement.
Look elsewhere when:
- You need immutable, tamper-evident audit logs, field-level before/after diffs, or retention/export controls (SOX, HIPAA, PCI). Use
owen-it/laravel-auditing or spatie/laravel-activitylog instead.
- Your team has a policy against unmaintained dependencies — reasonable here given 3 stars, zero dependents, and a 2022 last release.
- You need deleted-record recovery: this package stamps who deleted, it does not preserve the row.
- Write volume is high or tables are performance-sensitive; verify the per-write overhead before adopting broadly.
- Actor resolution is non-trivial — soft deletes, multiple guards, API tokens, queued jobs and console commands without an authenticated user all need explicit handling and testing.
- You need this to be supported, patched, or versioned against future Laravel releases.
How to Pitch It (Stakeholders)
For executives: This is a low-cost capability that lets the product answer "who created, changed, or deleted this record?" everywhere, with no external services and no vendor contract. It directly supports audit and compliance conversations and cuts support time spent reconstructing history. The caveat is the upstream package itself: it is effectively abandoned (3 GitHub stars, no dependents, last release January 2022). My recommendation is to adopt the pattern, not the dependency — vendor the small trait into our codebase and own it. That gives us the feature, removes the supply-chain risk, and costs roughly one to two engineering days including tests and backfill.
For engineering: One trait, three nullable actor columns per model, hooked into Eloquent's created/updated/deleted events. MIT-licensed, no infrastructure, no runtime dependencies. Fork it, add coverage for soft deletes, multiple auth guards, token-based actors, and job/console contexts where no user is present, then decide per-model where attribution is worth the columns. Flag anything that needs true audit history — that's a different tool and a different scope.
The ask: Approve a small, time-boxed spike to vendor and harden the trait, and treat full audit logging as a separate roadmap item to be evaluated on its own merits.