Bookmarkable Laravel Package

Product Decisions This Supports

• Build vs. buy: bookmarking/collections is a solved, generic problem. Adopting this package removes an estimated 2–4 weeks of design, build, and QA for a polymorphic save system, folders, cleanup, and events — engineering time better spent on differentiators.
• Feature scoping for a "save for later" MVP: the private default folder means you can ship a working save button on day one without designing a folder-management UI. Folders, sharing, and ordering become the phase-2 tier rather than a launch blocker.
• Roadmap for retention and personalization: saved items are a strong intent signal. This unlocks roadmap candidates like re-engagement digests ("5 things you saved"), personalized recommendations, and shared collections — and Bookmarked/Unbookmarked events mean you can measure adoption from day one rather than instrumenting later.
• Data model decisions: polymorphic contracts (CanBookmark / HasBookmarks) let you support multiple content types without a new join table per type, so the model decision stays reversible as the catalog grows.
• Operational/retention decisions: built-in cleanup on owner/item deletion plus scheduled pruning means retention policy and orphan-row hygiene are configuration, not a recurring engineering chore or a future data-quality incident.
• Performance decisions in list views: withBookmarkedBy() and isBookmarkedBy() solve the "show saved state on a list" problem in one query, which is usually the hidden cost that makes teams defer a bookmark feature.

When to Consider This Package

Adopt when:

• You're on Laravel with Eloquent models and users save more than one content type (articles, products, courses, docs).
• You want folders or collections, private-by-default, with optional sharing — the out-of-the-box default folder is exactly the low-friction pattern content products need.
• You need efficient per-row saved state on index pages (withBookmarkedBy) without hand-rolling eager-loading logic.
• You want lifecycle correctness (cascade cleanup, pruning) and analytics events without writing them.

Look elsewhere or build in-house when:

• You only need a single boolean "favorite" — a column is cheaper than a package.
• You need a social layer (public profiles of collections, followers, comments, likes on collections). This is storage and state, not a social graph; you'd be building that on top.
• Sharing requires granular per-user ACLs or roles. The shared flag appears binary, so team/enterprise permission models are yours to build.
• You need public share links with tokens, real-time collaborative folders, tagging, or search within collections — none are described here.
• You need bookmark counts rendered at scale on listing pages; no denormalized counters or caching are mentioned, so plan for that work.
• You require localization beyond Turkish/English, or compliance-driven audit trails on who saved what.
• You need non-Eloquent or cross-service bookmarking.

Maturity note: v1.0.0 is the first stable release. That's good news for API stability and means no migration risk, but it also means limited field history — worth a spike and a dependency-pinning review before it sits on a critical path.

How to Pitch It (Stakeholders)

To executives: This is a small, low-risk dependency that gives us a standard "save for later" and collections capability in weeks rather than a quarter. It's a proven retention pattern in content-driven products, it ships with the measurement hooks (events) we need to judge whether it's working, and it handles its own data cleanup so there's no ongoing maintenance tax. Cost is a package dependency plus a short integration effort; the alternative is bespoke code we'd own forever.

To engineering: Two contracts and two traits, applied to the saver and the saveable models. Polymorphic, ULID-keyed folders, positional and last-activity ordering, a private default folder created lazily, and bookmark()/unbookmark()/hasBookmarked() across default, specific, or all folders. The saved-state-for-a-list problem is handled by a scope and a predicate, so no N+1. Events dispatch after commit, so listeners are safe. Deletion cascades and model:prune is wired into the scheduler with configurable frequency and chunk size. Connections, tables, models, and the default folder name are all publishable config, and messages ship in TR/EN. Integration surface is small; the main things we'd own are UI, permission rules for shared folders, and any count aggregation.