Followable Laravel Package

Product Decisions This Supports

• Feature scoping: Enables follow/unfollow, follower lists, following lists, follow requests, approvals, and mutual-follow states without designing the relationship model from scratch. Useful for creator profiles, private accounts, subscriptions, community connections, and “follow back” UX.
• Build vs. buy: If the follow graph is table stakes rather than a core differentiator, this package reduces custom schema, query, event, and cleanup work. Teams can spend PM/engineering time on feed ranking, notifications, onboarding, or other differentiated surface area.
• Roadmap acceleration: Supports phased releases: basic follows first, then private-account approval flows, mutual-follow indicators, efficient list-state queries, and operational cleanup/pruning.
• Privacy and access decisions: RequiresFollowApproval, request acceptance/rejection, and hasFollowRequestFrom() make it practical to support private profiles or gated communities without building separate request state machines.
• Social UX decisions: Mutual follows, withFollowsBack(), and withFollowedBy() enable list badges, “follows you” states, and connection indicators with fewer custom queries.
• Integration decisions: Domain events for followed, unfollowed, requested, accepted, rejected, and cancelled support notifications, analytics, moderation, and activity feeds without coupling those systems into the follow model.
• Operational decisions: Automatic cleanup and scheduled pruning reduce stale relationship risk when users or followed models are deleted, lowering long-term data-hygiene work.

When to Consider This Package

Consider adoption when:

• The product needs a Laravel-native follow/subscription/connection primitive and the team wants to avoid custom polymorphic relationship plumbing.
• You need both sides of the relationship: models that follow and models that can be followed, including models that use both.
• Private accounts or approval-based follows are on the roadmap, not just instant follows.
• Mutual-follow indicators, follower/following counts, or efficient “does the current user follow this list item?” queries are required.
• You need lifecycle events for notifications or analytics and want them dispatched after commit.
• You want configurable connection/table/model integration and scheduled cleanup without writing a maintenance job.

Look elsewhere or plan to extend when:

• The product needs a full social graph suite: blocking, muting, close friends, recommendations, feed generation, ranking, anti-spam, or complex moderation workflows. This package is a relationship primitive, not an end-to-end social platform.
• The core differentiator is the graph itself, including specialized storage, massive-scale fan-out, graph analytics, or non-Eloquent access patterns. In that case, owning the model may be strategically necessary.
• The team cannot tolerate early-stage dependency risk. v1.0.0 is a stable signal, but first-major-version packages should still be pinned, integration-tested, and reviewed for maintenance cadence.
• You need rich UI components, notification templates, or feed delivery out of the box. This package provides domain behavior and events, not the full product experience.

How to Pitch It (Stakeholders)

For executives: This package gives us a tested Laravel foundation for follow relationships, including private-account approvals and mutual-follow logic, so we can ship social and subscription-style features faster and with less custom risk. It is a focused domain primitive, not a complete social network, so it accelerates the plumbing while we focus product effort on the experience and differentiation.

For engineering: Adopt it as the follow-graph layer: polymorphic followers, followable contracts, approval workflows, mutual-follow queries, list-state scopes, post-commit events, and automatic pruning. It is configurable and integrates with existing models, but v1.0.0 should be pinned and covered by integration tests. It intentionally does not solve feeds, blocking, notifications, or moderation, so those remain separate product and architecture decisions.