Verbs Laravel Package

Product Decisions This Supports

• Audit and compliance by default. Event sourcing makes "who changed what, when, and why" a first-class data model rather than a bolted-on activity_log table. This directly supports decisions in regulated or disputed domains: billing, payments, ledgers, inventory, approvals, KYC, claims, and anything where a customer or auditor asks "how did we get to this state?"
• Temporal / point-in-time answers as a feature. Because state is reconstructed from events, "show me this account as of 14 March" or "why was this order rejected?" becomes a product capability instead of a data-engineering ticket. The package's historical now() during replay and its "Wormhole" time-travel testing support make this cheap to demo and cheap to ship.
• Domain modeling decisions. The "think in Verbs, not nouns" framing pushes teams toward explicitly named business operations (PlaceOrder, RefundPayment) rather than CRUD writes. That is a modelling and product-language decision — it typically yields clearer naming in the UI, analytics, and docs.
• Roadmap sequencing of read models. Choosing this package commits you to a projection strategy. Treat read models/dashboards as separate deliverables from write-side features — that is a scoping decision, not an implementation detail.
• Build vs. buy. A hand-rolled event store (append-only schema, serialization, concurrency guards, replay, snapshotting, test helpers) is weeks of undifferentiated work. MIT-licensed and framework-native, this removes that line item from the roadmap.
• Feature-level use cases worth scoping into the backlog: event metadata (actor, request ID, source) for support tooling; isAllowed() / isValid() affordances for permission-aware UI (show/hide actions pre-submit rather than after a failed request); Livewire deferred commit to avoid partial writes when a render fails; outside listeners for integrations and notifications without polluting the domain.
• Sequencing risk decision: whether the team can absorb event sourcing now, or whether to start with a single bounded context (e.g. billing) behind a normal service interface and expand later.

When to Consider This Package

Adopt when most of these hold:

• The domain has real invariants and history that matter — money movement, entitlements, stock, approvals — not just CRUD over content.
• You are Laravel/PHP-native and want an event store that behaves like the rest of the framework (Eloquent-adjacent config, artisan generators, test helpers, factory support) rather than a separate service.
• You already run MySQL or Postgres and do not want to operate EventStoreDB/Kafka for the write side. Both are supported, including MySQL JSON ordering fixes and Postgres support.
• Your framework version is current — Laravel 11/12/13 compatibility is actively tracked.
• You can accept pre-1.0 API drift and will pin versions, read changelogs, and budget for small upgrade cycles (v0.6 → v0.9 shows real, non-trivial refactors: phases, dispatchers, state reconstruction).
• You will own projections and event versioning as an ongoing responsibility, not a one-off.
• Livewire/Alpine-driven admin or ops surfaces are in scope — the just-before-render commit hook is a genuine correctness win.

Look elsewhere when:

• The product is genuinely simple CRUD and the audit requirement can be met with a lightweight activity log or database triggers.
• You need a vendor SLA, paid support, or a 1.x stability guarantee, or your org requires a security review of a commercially backed dependency.
• Write throughput or cross-language consumers demand a dedicated event streaming platform (Kurrent/EventStoreDB, Kafka) shared beyond PHP.
• No one on the team has DDD/event-sourcing experience and there is no slack to learn it — the failure mode is an event table that is really just a slow audit log.
• You need batteries-included projection management, snapshots-at-scale, or a large plugin ecosystem. Note the zero recorded dependents: strong for a self-contained tool, but it means no crowd-sourced patterns to copy from.

How to Pitch It (Stakeholders)

For executives (one slide):

Verbs is an MIT-licensed, Laravel-native event sourcing library. It gives us a complete, queryable history of every business decision by default — the audit trail compliance asks for, the "what happened to my order?" answer support asks for, and the "replay it to debug" capability engineering asks for — without building an event store ourselves. Cost is a Composer dependency. Risk is maturity: it is pre-1.0 with a small maintainer group, so we mitigate by pinning versions, isolating it to one bounded context first, and keeping a documented exit path. Decision requested: approve a bounded pilot (billing/entitlements) with a two-sprint timebox.

For engineering:

• Removes the boilerplate that normally kills event sourcing in PHP: generators, state reconstruction, serialization, concurrency guards, factories, testing affordances.
• Works on the databases we already run (MySQL and Postgres), on current Laravel.
• Correct-by-default details we would otherwise get wrong: fire() is a no-op during replay, historical now() during reconstruction, Livewire commits deferred until just before render, event metadata on every event, outside listeners for side effects.
• Explicit ask: budget for event schema evolution and read-model projections. Do not treat this as a drop-in ORM swap.

For product/design:

• Enables affordance-driven UX — actions can be validated and permission-checked before the user clicks, not after.
• Enables "as of" views and safe replay for support tooling.
• Ask: agree up front which read models ship alongside each write-side feature.