Laravel Subscribe Laravel Package

Product Decisions This Supports

• Ships a "follow / subscribe / notify me" primitive without a build. User→user, user→team, user→tag or topic relationships, plus the inverse counts, come from a trait and a polymorphic pivot instead of a 1–2 week schema-plus-guard-clauses sprint.
• Unblocks specific roadmap items: follower counts as social proof, "notify me when this author posts," personalized or following-based feeds, weekly digest recipients, back-in-stock and restock alerts, marketplace seller follows, changelog/release subscriptions, and comment-subscription toggles.
• Build vs buy, framed honestly: the buy side is one Composer dependency with no license cost; the build side is ~1–2 weeks of engineering plus permanent ownership of uniqueness constraints, self-subscribe guards, counter caches, and cascade cleanup. The package wins when the feature is a means to an end, not a differentiator.
• Scoping signal for the roadmap conversation: if the request is "paid subscription, plans, trials, invoices," this is the wrong tool — route to Cashier/Stripe/Paddle. If the request is "who follows whom, and tell me when they post," this is the right tool. Getting that distinction into the backlog early prevents a very expensive naming collision.
• Release 1.4.0 is itself a decision point. The published notes contain only a 1.3.0...1.4.0 diff link and no changelog entries. With an empty data set behind this assessment, treat 1.4.0 as a no-information release: pin 1.3.0, have an engineer read the diff, and only then decide whether to bump.

When to Consider This Package

Adopt when:

• You are on a supported Laravel version with an Eloquent-centric domain model (verify framework support against your version before committing — the 1.4.0 notes do not state compatibility changes either way).
• You need subscribe relationships across more than one model type; that polymorphism is where the package earns its keep over a hand-rolled pivot.
• You want idempotent subscribe/unsubscribe, duplicate prevention, and eager-loadable counts as table stakes rather than as your team's problem.
• The team would rather own product features than relationship infrastructure, and a thin integration test around the package is an acceptable maintenance cost.

Look elsewhere or reconsider when:

• You need recurring billing, plans, trials, proration, or invoices. Different problem, different vendor.
• You need notification fan-out at scale, materialized timelines, or feed ranking. The package stores edges; the delivery pipeline and ranking model remain yours to build and operate.
• Write volume is very high (millions of follows per day) — scrutinize index strategy and whether counter caches on a hot column will contend under your load.
• You require an audited, immutable history of follow/unfollow events, or event-sourced semantics.
• A single plain pivot table with one direction and one model type is genuinely all you need; the package then adds surface area for little return.
• Maintenance signal is weak. Packages living under a large sibling namespace with a single maintainer warrant a bus-factor check and a pinning strategy, regardless of how clean the API is.

How to Pitch It (Stakeholders)

Executives: One Composer dependency gives us the follow/subscribe building block that three roadmap items depend on, instead of a one-to-two-week build plus permanent maintenance. There is no license fee, no vendor contract, and no data leaving our infrastructure — it is an additive table we can remove if it disappoints. Risk is low and contained. One caveat: the current 1.4.0 release ships an empty changelog, so we stay on 1.3.0, have an engineer review the diff, and only then upgrade.

Engineering: It provides polymorphic subscriber/subscribable relations, idempotent subscribe/unsubscribe, and query scopes for counts and lookups. We still own notification dispatch, feed assembly, rate limiting, and cleanup on model deletion. Pin the version explicitly, review the 1.3.0→1.4.0 diff before bumping, and wrap the integration in a thin test so a future breaking change cannot reach production silently. Treat 1.4.0 as unvetted until that diff has been read.