User Follow Bundle Laravel Package

Product Decisions This Supports

• Social graph scoping. user-follow-bundle targets the follow/unfollow primitive (follower relationships between users). That primitive underpins a cluster of roadmap items: profile follower counts, "who to follow" suggestions, activity feeds filtered by follow graph, and notification fan-out on new posts. If the graph model is on the roadmap, this is the cheapest possible probe of whether you need a dedicated abstraction or can treat it as a plain pivot table.
• Build vs. buy for a commodity domain. Follow relationships are a well-understood data model — a follows table with a composite unique index, plus counter caches. The build side of this decision is measured in days, not sprints. This package's value is therefore almost entirely in integration (framework wiring, migration conventions, query scopes) rather than in novel logic. That reframes the buy case: you buy to save glue work, not to acquire capability.
• Roadmap gating for social features. Adopting a 0.0.1 dependency is an implicit commitment to absorb API churn. That is a real cost against a roadmap that assumes stability. Treating this as a spike (timeboxed, throwaway) rather than an adoption decision keeps the social-feature roadmap unblocked without inheriting vendor risk.
• Feed architecture direction. Whether follows drive fan-out-on-write (precomputed feeds) or fan-out-on-read (query-time joins) is a major architectural fork. Evaluating an implementation that ships only the relationship model tells you the model is not the hard part — the hard part is feed materialization, which this package does not appear to address. Useful negative evidence for sequencing.
• Vendor and maintenance posture. tourze/* packages are a large family of single-maintainer, narrowly scoped bundles, generally Symfony-oriented despite the Laravel framing. A 0.0.1 release with an empty changelog body is a signal about release hygiene, not about code quality — but it is the only signal available, and it should be weighted as such in any buy decision.

When to Consider This Package

Adopt or seriously evaluate only when all of the following hold:

• You are on a PHP framework it actually supports. The -bundle suffix strongly implies Symfony Bundle conventions (DI extension classes, Resources/config). Verify it registers correctly in Laravel via a service provider, or confirm you are on Symfony. Do not assume Laravel compatibility from the brief.
• ORM alignment. Confirm whether it ships Doctrine entities, Eloquent models, or framework-agnostic repositories. A Doctrine-based relationship model in an Eloquent codebase is a rewrite, not an integration.
• Migrations and schema ownership. You need to know if it publishes migrations, owns its tables, and whether the schema includes the things that actually matter in production: unique constraint on (follower_id, followee_id), index on followee_id for follower lookups, soft-delete or timestamped unfollow for auditability, and block/mute semantics.
• You need only the primitive. If your requirement is genuinely "record that A follows B, answer counts and lists," a small package can be reasonable. If you need accepted-request flows (private accounts), mutual-follow semantics, or block-aware filtering, expect to build those yourself regardless.
• You can pin and fork. With a 0.0.1 release and no documented API stability, adoption is only defensible if you can pin the exact version, vendor the code, or fork without friction.

Look elsewhere — realistically, build in-house — when:

• The follow graph is core to your product and will accrete product-specific rules (blocks, mute, private accounts, follow requests, spam heuristics). These rules are exactly where generic packages stop and you start.
• You need feed generation, ranking, or fan-out. This package's scope ends before the interesting problems begin.
• Your team has no capacity to own a forked dependency. A 0.0.1 single-maintainer package is a long-term liability if no one is willing to adopt it.
• Compliance, licensing, or security review requires demonstrated maintenance history — an empty changelog at 0.0.1 does not clear that bar.

How to Pitch It (Stakeholders)

For executives: A small open-source PHP component for user follow relationships has appeared at an early version. We are not adopting it. Follow relationships are a simple data model we can own outright in a few days of engineering, and the package is at 0.0.1 with no release notes, no visible maintenance track record, and unclear framework fit for our stack. Buying it would trade a small amount of glue code for ongoing dependency risk on product-critical social features.

For engineering: Treat this as a short evaluation spike, not a dependency. In a two-to-four hour timebox, confirm three things: (1) does it target Laravel/Eloquent or Symfony/Doctrine; (2) does its schema include the unique constraint and reverse-lookup index, plus room for blocks and private-account requests; (3) does it do anything beyond CRUD on a pivot table. If any answer is "no," the recommendation is a first-party follows table with counter caches — roughly a day of work, no vendor exposure, and full freedom on block/mute and feed semantics, which is where the actual product differentiation lives.

Recommendation: Do not add to the dependency manifest. Reference the package's schema choices during design review, log the build-vs-buy decision as resolved toward build, and revisit only if a stable 1.x appears with substantive docs and Doctrine/Eloquent clarity.