Product Decisions This Supports
- Build vs. buy for visual review tooling. This package covers the core of a paid visual-feedback product (Markup.io, BugHerd, Pastel, Feedbucket): pinned annotations, screenshots, threaded comments, @mentions, resolve/reopen. Adopting it is effectively an "assemble" decision — native to the CMS, no new vendor, no separate reviewer accounts to provision. Evaluate against per-seat SaaS pricing across the number of client sites you run.
- Consolidating the client-review workflow into the CMS. Feedback lives next to the content it refers to (entry linking, feedback count column, current-page scope toggle). That supports a product bet that review context belongs with the artifact, not in a separate inbox — and removes a handoff step ("screenshot it and paste it into Slack").
- Agency / multi-site delivery model. Multi-site support via origin entry IDs, plus a configurable widget and granular permissions, makes this a candidate for a standardized "client review tier" in your offering — a repeatable deliverable rather than bespoke per-client setup.
- Roadmap input quality. Pins attached to CSS selectors and entries, plus mentions and read-tracking, produce feedback that is localized and attributable. That is materially more actionable for prioritization than free-text tickets, and it gives you a defensible source of demand signal per page/entry.
- Content-ops QA loop. Read tracking, unread badges, tabbed views (All / Unread / Mentions / Mine / Resolved) and toast notifications map directly onto an editorial sign-off workflow — useful for UAT on staging and for pre-publish review.
- Operational posture decision. Flat-file YAML storage means no database, no migrations, no schema review. This lowers the cost of a pilot and lowers the barrier to reversal, which supports trying it before committing.
When to Consider This Package
Consider it when most of the following hold:
- You are on Statamic (the Antlers tag, Control Panel integration, collections/entries, and preferences system all assume it). This is not a framework-agnostic Laravel package — if you are on plain Laravel or another CMS, it does not apply.
- Reviewers are authenticated CP users (client logins, editors, stakeholders). Granular permissions exist, but there is no indication of tokenized/anonymous public review links — confirm before assuming you can hand a link to an external client without an account.
- Volume is moderate: dozens to low hundreds of feedback items per site. YAML flat-file storage is excellent for portability and terrible for querying at scale — expect no reporting layer, no aggregation, no bulk analytics, and growing file counts in the storage path. Ask explicitly about search, filtering, and archival at 1,000+ items.
- The value is visual, page-anchored feedback. CSS-selector pinning is the differentiator; if your feedback is mostly process or backlog discussion, a normal issue tracker wins.
- You need no deep integrations in v1. There is no mention of Jira/Linear/GitHub/Slack webhooks or an API. If feedback must flow into an engineering backlog automatically, budget for custom work or treat this as a review-only layer.
- Browser-native capture is acceptable. Screenshot capture uses the browser's screen capture API, which requires a user gesture and has real limits on mobile and some embedded contexts. Confirm your reviewers' devices and browsers before committing.
- You accept v1.0.0 risk. Initial release, single-maintainer-profile risk, no published track record, unknown breaking-change and support policy. Pilot on one or two non-critical sites and read the upgrade path before wider rollout.
Look elsewhere when: you are not on Statamic; you need anonymous external review, structured reporting/SLA, high-volume feedback, Jira-class integrations, screenshot redaction/compliance controls, or a vendor with contractual support. In those cases a hosted review tool is the lower-risk buy.
How to Pitch It (Stakeholders)
For executives: This is a CMS-native client feedback and annotation capability — pinned comments on live pages, screenshots, mentions, resolve workflow — that replaces a per-seat SaaS line item and keeps review inside the tool our teams already use. There is no database and no new infrastructure, so the cost to trial is a plugin install and a config change, and the cost to reverse is the same. I recommend a bounded pilot on one or two client sites, measured against current review turnaround and the SaaS spend it displaces, before any portfolio-wide commitment. Two caveats to state up front: this is a v1.0.0 with no adoption history, and its storage model is deliberately simple — it is a team review tool, not a reporting or analytics system.
For engineering: Statamic addon on Laravel. No migrations, no new services, no schema — feedback persists as flat-file YAML at a configurable path, so the operational surface is a storage directory and a permissions config. Frontend integration is a single Antlers tag; CP integration reuses Statamic's existing collections, entries, preferences and permission model rather than inventing a parallel auth or notification system. Everything is config-driven (widget position, pins, screenshots, listing column, storage path). What is not there in v1: a public API, outbound webhooks/issue-tracker sync, and any bulk query or export tooling over the YAML store — assume custom work if we need feedback to flow into the engineering backlog, and design an export/archival path early so we are not locked into a flat-file directory as volume grows. Practical asks before rollout: confirm supported Statamic/PHP versions, confirm the screenshot path and any review of captured data, and get the maintainer's stance on breaking changes and release cadence.