Counter Bundle Laravel Package

Product Decisions This Supports

• Feature scope: synthetic/social-proof counters. The v1.1 change ("fake count functionality") indicates the package maintains a display count composed of a real tally plus a controllable fake offset, rather than mutating the real count in place. That is the right shape for a product feature — the offset can be tuned, zeroed, or removed without corrupting the underlying metric.
• Build vs buy. The core logic is small (a column/delta plus arithmetic on read), so buying only makes sense if you value the ORM integration and edge-case handling over a ~1-day in-house implementation. This release does not change that calculus; it widens the integration surface rather than deepening the core feature.
• Platform/architecture roadmap. prePersist/preUpdate hooks are Doctrine ORM lifecycle callbacks, not Eloquent events. This signals the package is intentionally multi-ORM — relevant if you have Doctrine entities in a legacy or Symfony-derived service that must stay consistent with Laravel-side counters, or if you are planning a shared persistence layer.
• Use cases to evaluate against: launch/waitlist pages, marketplace listing activity indicators, "X people viewing" widgets, seeded review or download counts. Prioritise these only where the fake offset is disclosed or where a compliance review has cleared it.
• Not supported by this release: analytics-grade accuracy, event deduplication, real-time streaming counts. Treat it as a presentation-layer counter, not a metrics system.

When to Consider This Package

• You already persist a real counter and want the fake delta stored separately so it is auditable, reversible, and can be set to zero instantly (incident response, regulator request, A/B test rollback).
• You run Doctrine ORM entities alongside or inside the Laravel app and need the offset applied automatically on write. For a pure-Eloquent codebase, the headline of v1.1 delivers nothing — evaluate the package on its pre-v1.1 feature set instead.
• You need per-entity configuration of the offset rather than a global multiplier.
• Look elsewhere if:
  • You need event-level idempotency or concurrency-safe increments (nothing in this changelog addresses race conditions on preUpdate; two concurrent updates may both read-modify-write).
  • You are Eloquent-only — the release adds no value and the Doctrine dependency may still be pulled in.
  • You operate in a jurisdiction or category with disclosure rules for inflated engagement metrics (consumer protection, advertising standards, app-store policy). Fake counts are a legal exposure, not just a technical one.
  • You need a maintained package with a documented support window. The evidence here is a single changelog line; versioning discipline, test coverage, and maintainer responsiveness are unverified.

Open questions before adoption: Is the fake offset applied on prePersist only at creation, or re-applied on every preUpdate (which would compound and inflate silently)? Is the offset idempotent under retries? Does the Doctrine integration require Doctrine as a hard dependency for Eloquent users?

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, low-cost conversion lever for listing, launch, and marketplace surfaces — it lets us present a higher activity number than the true count while keeping the real number intact and the difference separately stored, so it can be switched off in minutes if legal, trust-and-safety, or partner teams object. The v1.1 release is additive and non-breaking; it extends support to Doctrine-based services, which mainly matters if we consolidate counters across our Laravel and legacy stacks. The strategic cost is not engineering time, it is disclosure and brand risk, so I would recommend a compliance review in parallel with a scoped pilot on one low-stakes surface rather than a platform-wide rollout.

For engineering (summary): v1.1 adds fake-count support wired into Doctrine prePersist/preUpdate. It is an additive feature release with no signalled breaking changes or deprecations, so upgrading from the prior line is low risk. Before we commit, I need three answers: (1) whether the offset is written once at persist or recomputed on every update — the latter risks compounding; (2) how concurrent updates are handled, since read-modify-write in a lifecycle callback is not atomic; and (3) whether Doctrine becomes a required dependency or stays optional for Eloquent-only consumers. If those check out, the integration work is a single column plus a read-path accessor, and the whole feature is behind a flag we can zero out without a migration.