Products Favorite Laravel Package

Product Decisions This Supports

• Feature triage: wishlist / "save for later" vs. other roadmap bets. The package makes the build cost of a baseline favorites feature small enough that the decision stops being "is this worth 3–4 sprints?" and becomes "is this worth a 1–2 day spike plus a fork risk?" That reframing is the main PM value here — it lets you put favorites on the table for a quarter where a custom build would never survive prioritization.
• Build vs. buy vs. fork. Three credible options, and this package clarifies the middle one:
  • Buy/adopt: composer require, wire to existing User/Product models.
  • Fork: MIT license, no vendor lock-in, so you can vendor it and own the code if the upstream goes quiet.
  • Build: still viable — favorites is a small domain (a join table, a toggle endpoint, a list query). Be honest that "build" may be 1–2 weeks, not 4. The PM decision is which of these three you're choosing before engineering starts, not after.
• Retention and intent-signal roadmap. Favorites are a leading indicator, not just a UI affordance. Once the data exists, it unlocks a sequenced backlog: back-in-stock alerts → price-drop notifications → "your saved items" email → recommendation inputs → collaborative/shared lists. Approving the module is really approving the first item in that chain, so scope the follow-on roadmap at the same time or you'll ship a dead-end.
• Use-case fit by product type.
  • E-commerce / D2C: save-for-later to soften cart abandonment; reduce re-search friction for repeat buyers.
  • B2B / wholesale: reorder lists and buyer shortlists — often higher value than consumer wishlists, and usually a simpler data model.
  • Marketplace: buyer shortlists, seller-side assortment tracking.
  • Content/SaaS: the same user↔object pattern for bookmarks, templates, or dashboards — but only if the domain object is a "product" in this package's sense; otherwise you're fighting the schema.
• Platform-upgrade coupling. The package requires PHP 8.4+. That is a product-level constraint, not a footnote: adopting it may pull forward an infrastructure upgrade, or block adoption if the upgrade isn't funded. Decide this explicitly rather than discovering it in sprint planning.
• Make-or-defer with a real exit. Because it's MIT and forkable, the downside case is bounded — worst case you inherit ~a small module's worth of code. That bounded downside is the argument for trying it on a secondary surface (e.g., a category page) before the primary purchase funnel.

When to Consider This Package

Reasonable to evaluate when:

• You're on Laravel with PHP 8.4+, and User and Product (or an equivalent) models already exist — the module assumes both and documents neither.
• The requirement is genuinely simple: one user, many saved products, add/remove/list. No sharing, no permissions, no real-time.
• You have engineering capacity to read the source, not just the README. The README is Russian-only and contains install and test commands but no schema, config, routes, or extension points. Discovery cost is real and should be budgeted as a spike, not assumed away.
• You're comfortable pinning a version and forking if necessary. Single-maintainer, 0 stars, 0 dependents, no issue activity — treat upstream as a starting point, not a dependency you can lean on for patches.
• The feature is non-critical path (browsing, discovery, account area) rather than something checkout or inventory depends on.
• Release notes are version-number-only (v7.4.8, v7.4.4), so treat each bump as opaque: pin exactly and review diffs before upgrading.

Look elsewhere or build when:

• You need team/shared lists, granular visibility, or multi-tenant scoping — these are the features people actually ask for six weeks after launch, and bolting them onto an opaque module is worse than owning the schema.
• You need real-time or push behavior, bulk operations, import/export, or an API contract you control.
• Frontend components are expected out of the box — this is backend-only by design; UI is 100% your cost, so budget design and build time accordingly.
• Your security/procurement review requires an actively maintained dependency with a support path. 0 dependents and no changelog detail will not pass a strict review, and you shouldn't try to argue it through.
• Your catalog and traffic profile is large and you have no benchmarks — favorites list queries on a big join table can degrade quietly; if you can't test at realistic scale, don't adopt blind.
• You're on PHP < 8.4 or non-Laravel PHP. No middleware shims; just don't.
• The real requirement is analytics (who saves what, funnel impact) — that's an event pipeline decision, not a CRUD module decision.

How to Pitch It (Stakeholders)

To executives — one paragraph: "We can test a 'save for later / wishlist' capability for roughly a 1–2 day engineering spike instead of a multi-week build, using an MIT-licensed open-source module that drops into our existing PHP stack. It's forkable, so there's no vendor lock-in and the worst case is that we own a small piece of code we'd have written anyway. The reason to do it is less the button and more the signal: saved items tell us what people want but didn't buy, which feeds back-in-stock alerts and lifecycle messaging. The honest caveat is that the project is small and unproven — no external adoption, no English documentation — so I'm recommending we evaluate it on a secondary surface first and hold the primary funnel until the spike clears. Ask: approve the spike and a scoped pilot, not a platform commitment."

To engineering — the short version:

• What it is: a Laravel module for user↔product favorites. composer require baks-dev/products-favorite, run migrations, bind to existing User/Product. Backend only; no UI, no routes we're obliged to keep.
• What we don't know: schema shape, index coverage, whether models/views/config are publishable, event hooks, and whether duplicates/soft-deletes/concurrency are handled. README doesn't say; the code will.
• Required first step: a time-boxed spike (1–2 days) — install in a throwaway branch, publish assets if supported, diff the generated migration, exercise add/remove/list against our models, run the package's own test group (php bin/phpunit --group=products-favorite) and note actual coverage.
• Posture: pin the exact version, vendor or fork it, and plan to own it. Don't build a hard dependency on upstream responsiveness; the release notes are version strings only, so every upgrade needs a diff review.
• Costs we're accepting: writing our own integration and edge-case tests, English documentation for the team, and all frontend work. If the spike shows the data model fights ours, we stop and build — that's a legitimate outcome, not a failure.
• Decision gate: spike output is a one-page writeup — schema fit, extension points, missing pieces, estimated remaining effort vs. a custom build. Then we commit or walk.