Subscribe Laravel Package

Product Decisions This Supports

• Build vs. buy on the "follow / subscribe" primitive. Every product surface that lets a user track something — a creator, a channel, a thread, a category, a saved search, a product — needs the same underlying mechanic: a durable, queryable, on/off relationship between a subscriber and a subscribable. This package supplies that substrate as a polymorphic pivot with subscribe(), unsubscribe(), toggleSubscribe(), and isSubscribedTo(). What we'd otherwise fund is a week or two of schema design, unique-constraint handling, trait wiring, and the edge cases (double-clicks, deleted targets, eager-loading) that only surface after launch. What stays in-house either way is the differentiated part: what a subscription triggers, digest cadence, preference granularity, and the UX around it.

• Roadmap sequencing and reuse. Shipping the substrate once unblocks a family of adjacent roadmap items cheaply: notification opt-ins, follower feeds, "new from people you follow," watch-this-thread, re-engagement campaigns aimed at subscribers of dormant channels. The second and third features reuse the same table instead of introducing yet another bespoke pivot. That compounding reuse, not the first feature, is where the value sits.

• Consistency and product analytics. Standardizing on one subscription model makes questions we currently hand-wave answerable: how many users follow more than one channel, what the median subscription lifetime is, how often people toggle off after a digest, which acquisition source produces subscribers who stay. Those numbers decide whether to invest next in preference UX or in content quality — and they're only tractable if subscriptions live in one place.

• Release 1.4.0 is a pinning decision, not a feature decision. The bump from 1.3.0 to 1.4.0 shipped with only an auto-generated compare link and no changelog body. Semver says no breaking changes and nothing signals a deprecation, but there is no documented evidence either way. Treat 1.4.0 as unverified rather than safe: pin the exact version, read the commit diff before upgrading, and confirm the trait signatures and migration stubs we depend on are unchanged. This doesn't change the adoption calculus, but it does inform how tightly we pin and how much we wrap.

• Maturity is a first-class input here. 8 stars, zero dependents, a single maintainer, and a last release in February 2022 put this firmly in "small community package" territory. That's acceptable for undifferentiated plumbing behind an internal interface; it is not acceptable as a load-bearing dependency with no exit.

When to Consider This Package

Adopt when most of these hold:

• The application is Laravel and already leans on Eloquent relationships rather than a separate domain service — this package is trait- and Eloquent-centric by construction.
• The requirement is genuinely polymorphic: subscribers and subscribables are both arbitrary models (User follows Creator, Team follows Category, User follows User).
• The scope is state storage and retrieval, not delivery. We plan to handle dispatch, digests, and fan-out through Laravel's own queue, mail, and notification systems.
• We want the capability in days, not sprints, and the team is small enough that a scoped community package beats an internally owned module.
• Subscription semantics are simple: on/off, possibly typed per category. No approval workflows, no time-boxed subscriptions, no billing.
• We can afford the one-hour insurance policy: wrap the traits behind a thin internal service or repository so the package can be swapped or absorbed without a cross-cutting refactor.

Look elsewhere — or build — when:

• Delivery is the requirement, not storage. Digest batching, cross-channel deduplication, retry/backoff, quiet hours, and per-channel preference matrices are an orchestration problem this package does not attempt. Build or buy a notification-preference layer above it.
• Fan-out scale dominates. A pivot table reads fine, but a channel with millions of subscribers writing to a feed on every publish needs fan-out-on-write outside this package's scope.
• Compliance drives the requirement. GDPR-grade consent records, immutable subscription history, and unsubscribe provenance for CAN-SPAM are audit concerns. An on/off pivot row that gets updated in place is not a consent ledger; we'd need an append-only event log alongside it regardless.
• Multi-tenancy or strict data isolation is architectural rather than incidental, and we need tenancy-aware scoping the package doesn't provide.
• We require an SLA, security review, or LTS commitment. The release-notes gap alone means changelog-driven upgrade planning is impossible; if the org mandates documented change review for every dependency, we are signing up to read diffs ourselves forever.
• Subscription logic is a core differentiator — tiered memberships, proration, trials, entitlements. Own that model; the package will constrain it.

Operational caveats to budget for if we adopt: verify the published migration actually carries a unique index across the full morph quartet, because duplicate subscriptions from a double-click are a race condition, not just a UI glitch; purge subscriptions when a subscribable is deleted, since morph relations have no cascading foreign key; treat isSubscribedTo() as a query and pre-load the user's subscription set rather than calling it inside a loop; and enforce a morph map before launch, because renaming a model class afterward silently orphans rows.

How to Pitch It (Stakeholders)

For executives — one paragraph. Subscription and "follow" mechanics are a recurring product primitive, and we currently rebuild the underlying data model every time a new feature needs one. This package supplies that model off the shelf in our existing framework, removing roughly a week of engineering plus its testing and maintenance from each feature that touches it. The strategic value isn't the code we skip writing once — it's that a single, consistent subscription substrate lets us ship notification opt-ins, follower feeds, and "new from people you follow" as a sequence of small features rather than a series of mini-projects, and it finally gives us one place to measure subscriber behavior. The trade-off is real but bounded: this is a small, single-maintainer package last released in 2022, so we adopt it pinned to an exact version, behind a thin internal interface, with a documented exit path. That costs about an hour of engineering and converts a dependency risk into a contained swap.

For engineering — the practical summary. Laravel-native, MIT, trait-based, one polymorphic subscriptions table serving every subscriber/subscribable pair. Install via Composer, publish config and migrations, migrate. Add the subscriber trait to User and the subscribable trait to Channel, Newsletter, Topic, and so on. Three extension points matter and we should stick to them rather than overriding trait methods: the package's state-change events (listen for SubscriptionCreated and branch on resulting state for toggles, which fire in both directions), the config's model/table mappings (pointing it at a custom model means extending theirs, not a plain Model), and the relation on the subscriber trait. Two things to verify on day one rather than after launch: that the published migration has the full unique index, and that our morph map and key types (UUID vs. bigint) match on both sides. Pin to 1.4.0, since its release body is only a diff link — diff the config and migration stubs against ours on any upgrade and run migrate:fresh in CI. Wrap all of it in an internal repository so the day we outgrow it, we replace an interface instead of chasing traits through the codebase.