Laravel Follow Laravel Package

Product Decisions This Supports

• Build vs. buy for social-graph primitives. Follow/unfollow, follower and following lists, and "is X following Y?" checks are commodity features. This package converts a schema-design + relationship-plumbing task into a composer dependency, so the decision shifts from "how do we model this?" to "is this package's maintenance profile acceptable?" That is a much cheaper question to answer.
• Roadmap scoping for follow-based features. It unblocks a specific, repeatable pattern: marketplaces ("follow this seller"), communities and forums ("follow this topic"), LMS ("follow this instructor"), creator/newsletter tools ("follow this author"), and internal tools ("watch this project"). If a roadmap item depends on any of these, this is a candidate enabler rather than a bespoke build.
• Core vs. adjacent classification. If the social graph is the product (ranked timeline, recommendations, fan-out at scale), this package is too thin and you should invest in a real graph/feed architecture. If follow is a supporting feature that drives notifications and re-engagement, buying here is the right call and frees the team for the differentiating work.
• Data-model and analytics implications. Whatever you adopt defines your follows table shape, which in turn constrains follower-count reporting, cohort/engagement analysis, and segmentation queries. Worth a deliberate decision now rather than a migration later.
• Scope boundaries that become separate epics. This package stores relationships; it does not produce feeds, notifications, or ranking. Getting stakeholders to see that explicitly prevents "we installed the follow package, why isn't there a feed?" scope creep in planning.

When to Consider This Package

Adopt when most of these are true:

• You are on Laravel and your entities are Eloquent models, including cases where multiple model types need to be followable (users follow users and tags and posts).
• You need simple, one-directional follows with counts and existence checks, not a social platform.
• Your team is small or time-constrained and you'd rather own a thin dependency than design and test the pivot/polymorphic schema.
• The BSD-3-Clause license is acceptable to legal (it is permissive and business-friendly) and you are comfortable vendoring or forking the code if upstream stalls.
• Expected volumes are modest, or you are prepared to add indexes and review query patterns for follower counts and list endpoints.

Look elsewhere or plan to build/own when:

• Maintenance risk is disqualifying. Last release was July 2023 and the project has ~49 stars. Validate Laravel and PHP version support against your target framework version before committing; if it lags, budget a fork and an owner rather than assuming upstream fixes.
• You need feed generation, ranking, fan-out, or notification delivery. None of that is in scope here; those are separate systems and should be separate epics.
• You need private accounts, follow requests, blocking, or muting. These are product-level rules this package does not model.
• You are operating at high scale. Polymorphic follow tables plus count queries need careful indexing and possibly denormalized counters; at large volumes a dedicated graph store or event-driven approach may be cheaper long term.
• You want a broader social toolkit. Likes, bookmarks, and reactions are separate concerns; check whether the vendor's sibling packages or a larger suite better match your intended surface area.

How to Pitch It (Stakeholders)

For executives: This is a small, permissively licensed component that removes an estimated few developer-days of undifferentiated schema and relationship work from any follow-based feature on our Laravel stack. The license carries no commercial friction. The tradeoff is momentum: the project is small and has not shipped since mid-2023, so we would effectively own the code if it falls behind. Because the surface area is tiny, the downside is bounded and reversible. Recommendation: approve as a timeboxed evaluation for the next follow-dependent feature, not as a standing platform commitment.

For engineering: Trait-based API over Eloquent, polymorphic so several model types can be followed, and small enough to read end to end in an afternoon. Before adopting: pin the version, confirm framework and PHP compatibility against our target, review the migration for indexes on the polymorphic columns, and wrap it in integration tests so a future fork or swap is a contained change. Assign an internal owner and record a fork-and-maintain fallback in the decision log.