Timestampable Bundle Laravel Package

Product Decisions This Supports

• Auditability and data-provenance commitments. "When was this record created or last modified?" underpins compliance evidence, dispute resolution, support triage, and incident forensics. Whether created_at/updated_at are populated consistently across every entity — not just the ones a careful developer touched — is a product-integrity decision, not just an engineering one.
• Reporting, lifecycle, and retention logic. Cohort analysis, staleness/decay reports, "untouched in 90 days" queries, data-retention enforcement, and SLA clocks all assume uniform timestamps. Inconsistent values silently corrupt downstream dashboards and customer-facing lifecycle states.
• Sync and ETL watermarks. Incremental export and cache invalidation keyed on updated_at only work if every write path — bulk operations, queued jobs, admin tools — updates the field. This is the strongest argument for a framework-level behavior over per-developer discipline.
• Build vs. buy vs. configure. The real decision is three-way: (a) adopt a third-party timestamp behavior, (b) write a small in-house trait + listener, or (c) use the ecosystem default. Note that this is a Symfony/Doctrine bundle, not a Laravel package — in Laravel, Eloquent already provides $table->timestamps() and automatic created_at/updated_at natively, so the problem this package solves largely does not exist on that stack. A PM should treat adoption of this package in a Laravel codebase as a non-decision.
• Roadmap input on "when" vs. "who." Timestampable is a natural stepping stone to blameable (created_by/updated_by). If per-user change attribution is on the roadmap, this decision should be made once with that in mind, not twice.

When to Consider This Package

Adopt only if all of the following hold:

• The target service runs Symfony + Doctrine ORM. It is not applicable to Laravel/Eloquent — for Eloquent, use native $timestamps() and $table->timestamps() and stop.
• You want the thinnest possible dependency — no Gedmo, no extension ecosystem — and your team has read the source and confirmed it covers your actual write paths (per-entity flushes, embeddables, inheritance, soft-delete semantics).
• You are prepared to own it: fork it, vendor it, or pin it. With 0 stars, 0 dependents, and a 0 score, there is no evidence of production use, no community to catch regressions, and no realistic expectation of upstream fixes. Treat it as a code sample, not a maintained dependency.

Look elsewhere — or build — when any of the following is true:

• You need created_by/updated_by, soft-delete timestamps, timezone-aware or immutable-only variants. Use Gedmo Timestampable/Blameable (via stof/doctrine-extensions-bundle), which carries a decade of edge cases and a real maintainer base.
• You are on Laravel — Eloquent already covers this, and adding the package is pure liability.
• Supply-chain policy requires maintainer activity, security response, or a minimum adoption signal. This package fails all three.
• Your team's time is the scarce resource: a trait plus prePersist/preUpdate listener is a few hours of work, fully testable and extensible to blameable later.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. Build in-house or use the ecosystem standard.

The underlying need is real and worth funding — every product team needs trustworthy created_at/updated_at to support audit, reporting, retention, and sync. But this specific package is not the right vehicle. It is a Symfony/Doctrine bundle (not Laravel), with zero stars, zero dependents, and no observable maintenance. Adopting it converts a small, well-understood problem into a supply-chain and bus-factor problem.

For executives: the capability is cheap; the dependency is expensive. We satisfy the requirement either with the mature Symfony standard (Gedmo, already broadly used) or with roughly a day of internal engineering. Either path carries less long-term risk than a single-maintainer package with no users. On a Laravel stack, the requirement is already met by the framework.

For engineering: treat incompass/timestampable-bundle as a reference implementation worth reading, not a dependency worth adding. If we go in-house, we own a ~40-line trait plus a Doctrine (or Eloquent observer) listener, with tests covering bulk updates and inheritance — and we can extend it to blameable later without churning our dependency choices.

Decisions to make now: (1) confirm the stack — if Laravel/Eloquent, this is a non-decision and we move on; (2) if Symfony/Doctrine, choose Gedmo vs. in-house; (3) decide whether blameable (created_by/updated_by) is in scope this quarter, since it changes the build estimate and may justify choosing Gedmo outright.