Laravel Followers Laravel Package

Product Decisions This Supports

• Build vs. buy for the social graph primitive. This package is a thin, MIT-licensed layer over a polymorphic pivot table plus CanFollow / CanBeFollowed traits. It decides the schema question (one generic followers table keyed by follower/followable morph pairs) so the team doesn't reinvent it, and defers everything above it to us.
• Time-to-market on follow-style relationships. The real saving is not the model code — realistically 1–3 engineering days including tests — but the schema convention and the edge-case methods (follow, unfollow, toggleFollow, isFollowing, followers, following) that a PM would otherwise have to spec, review, and QA.
• Feature reuse across surfaces. One relationship primitive can back several roadmap items that look unrelated to users: follow/feed, subscribe-to-updates, watch-this-entity, assign-to-team, "interested in" interest graphs, and notification targeting audiences. Each additional consumer of the same table raises the ROI of standardizing early.
• Scoping honesty on adjacent features. Because the package stops at the graph edge, it forces an explicit roadmap split: relationships (this package), audience resolution and fan-out (our job), feed storage/ranking (our job), notifications (Laravel's job), moderation surfaces — block, mute, private/approval-required follows — which are not modeled here and must be budgeted separately if the product needs them.
• Vendor-risk posture. 12 GitHub stars, one maintainer, last release Feb 2023, low health score. That's a vendoring decision, not a dependency decision — it argues for treating the package as copy-adaptable source with a named internal owner rather than a supported third-party contract.

When to Consider This Package

Adopt when most of these hold:

• Laravel 9/10-era app on a single relational database, standard Eloquent models on both sides of the relationship.
• Requirements are the plain-vanilla semantics: follow, unfollow, check, list. No approval workflow, no rate limits, no blocks/mutes, no mutuals or recommendations.
• Early-stage or internal product where a fork is acceptable and the codebase is small enough that a maintainer can read the whole package in an afternoon.
• You want the schema decided now and are willing to own migrations, indexes, and counter/caching strategy yourself.
• Modest scale: follower counts read from count() or a nightly rollup are acceptable; no timeline-fan-out at write time.

Look elsewhere (or build in-house) when:

• You need private accounts, follow requests, blocks, mutes, or per-relationship metadata (roles, notification preferences, affinity scores) — the base table has no room for these without a schema fork anyway.
• You need high-volume social proof — follower counters on every profile render, fan-out on write, or graph traversals (mutuals, "followed by X"). That's a caching/queue problem, and a package won't help; consider a dedicated cache layer or graph store.
• You need vendor support, security patching, or an LTS commitment; the maintenance signal here is weak.
• You are not on Eloquent polymorphic relations, are multi-database, or need the graph shared across services.
• Active maintenance matters and alternatives are better supported — evaluate cybercog/laravel-love (follow + like + subscribe in one) or overtrue/laravel-follow before committing, and note none of them solve approvals or blocks either.

How to Pitch It (Stakeholders)

To executives: A free, MIT-licensed building block that gives us the standard "who follows what" capability — the foundation for feeds, subscriptions, and audience targeting — without a build cycle or license cost. It removes a few days of undifferentiated work and, more importantly, settles a data-model decision we'd otherwise revisit on every adjacent feature. The trade-off is support: it's a small open-source project with a single maintainer and no release since early 2023, so we should treat it as code we adopt and own rather than a vendor we rely on. Ask: fund a named internal owner and a fork, not a support contract.

To engineering: Small surface area — a migration, a polymorphic pivot, two traits, and a handful of query helpers. Read it fully before adoption; it's forkable in a day. Three things to validate in a spike: (1) index and unique-constraint choices on the pivot for our read patterns, (2) how we want counters cached — the package won't do it, (3) Laravel version compatibility and whether we pin or vendor. Deliberately out of scope: follow approvals, blocks/mutes, feed generation, notifications. Keep the trait calls behind a thin domain service so replacing the package later is a swap, not a migration — the durable decision is the schema, not the library.

Recommendation: Adopt for MVP with a small spike and an internal fork; revisit if we add private accounts or high-traffic counters, either of which outgrows the package.