The gap we kept running into
Every few years, a new category of developer tooling emerges that's genuinely useful. Error tracking (Sentry, Bugsnag) gave us stack traces and error grouping. APM (New Relic, Datadog) gave us request traces and query insights. Session replay (Hotjar, FullStory, LogRocket) gave us user behavior recordings for product analytics.
But there's a gap between these tools and the day-to-day experience of fixing bugs reported by users. Error tracking tells you an exception occurred, not what the user was doing when it happened. APM tells you a request was slow, not what the user saw on screen. Session replay gives you recordings, but most implementations are built for product teams doing conversion analysis, not developers debugging a specific issue.
And then there's the actual reporting mechanism. Most teams still rely on some combination of email, Slack, Jira, and support chat for bug reports. The user describes the problem in their own words (poorly, usually). The report gets triaged by a support person who may not understand the technical context. Eventually a developer gets a ticket that says "checkout is broken" with no additional information. They spend the next several hours trying to reproduce.
We kept hitting this pattern. We had Sentry for errors. We had monitoring for performance. But when a user reported a visual bug, a layout issue, a confusing workflow, or something that didn't trigger a server-side exception, we were back to asking "what browser are you using?" and "can you send a screenshot?"
FeedSnap started as an internal tool to close this gap.
What FeedSnap does
FeedSnap is an embeddable JavaScript widget that you add to your web application with a single script tag. When a user encounters a bug or wants to give feedback, they click the feedback button, type a description, and submit. Behind the scenes, the widget automatically captures:
A screenshot of the current page state, which the user can annotate — circles, arrows, or text to highlight what's wrong. No screenshot tool or browser extension needed.
Browser console output — the last several entries, including JavaScript errors, warnings, and log statements. If there's a TypeError or a failed assertion, the developer sees it immediately.
Recent network requests — API calls made by the page, including URLs, status codes, timing, and response sizes. Failed requests are highlighted so the developer can spot backend issues at a glance.
Environment metadata — browser, OS, viewport dimensions, device pixel ratio, screen resolution. The basics every developer needs and every user forgets to mention.
An optional session replay — a 30-second recording of the user's interactions before the report, captured from a rolling buffer in memory. Not an always-on recording. Only the relevant window of activity, and only when the user submits.
The developer receiving the report gets all of this in a single, structured view. Screenshot, replay, console output, network log — without leaving the dashboard.
The widget
The widget is small. The base bundle is under 50KB gzipped — that's the UI framework, feedback form, screenshot capture, basic telemetry, and the API client. For comparison, React alone is 40 to 45KB gzipped. Session replay and framework-specific features load on demand as separate chunks.
The widget renders inside a Shadow DOM for CSS isolation. The host page's styles don't affect the widget, and the widget's styles don't affect the host page. No class name conflicts, no z-index wars, no font inheritance issues.
Installation is one script tag:
<script
src="https://cdn.feedsnap.dev/widget.js"
data-project-key="pk_your_key"
async
></script>The script loads asynchronously and defers initialization until after the page's load event, so it has zero impact on Core Web Vitals. We measure this on every release — any regression fails the build.
The dashboard
Reports show up in a dashboard organized by project. Filter by status, sort by date or priority, search across feedback content. Each report shows full context: the user's description, annotated screenshot, console log, network trace, and session replay if enabled.
The dashboard supports team workflows. Assign reports to team members, add internal comments, change status, set priority levels. When a report is marked resolved, it's because a developer actually looked at the bug.
FeedSnap is a multi-tenant SaaS application. Each team gets their own workspace with their own projects, members, and data. No cross-tenant access. Each workspace is accessed through a dedicated URL path, and tenant isolation is enforced automatically at the database query level.
What FeedSnap isn't
Worth being clear about this, because the feedback tooling space is crowded and terminology overlaps.
FeedSnap isn't a survey tool. We don't do NPS surveys, feature voting, or satisfaction scoring. If you need "How likely are you to recommend this product?" — Canny, Productboard, and Typeform do that well. FeedSnap is for bug reports and technical feedback.
FeedSnap isn't a support ticket system. No customer-facing inbox, no canned responses, no SLA tracking. For a full helpdesk, look at Intercom, Zendesk, or Help Scout. FeedSnap captures the technical context before the ticket — the moment a user hits a problem.
FeedSnap isn't an analytics platform. We don't track user journeys, funnels, or engagement metrics. Session replay exists for bug context, not behavioral analytics. If you need always-on recording for product analysis, FullStory or Hotjar are better fits.
What we are: the layer between your users and your developers. The user clicks a button, describes a problem. The developer gets everything they need to diagnose it.
Privacy by default
Session replay has a justified reputation for privacy problems. Most implementations record everything by default and expect you to configure exclusions. We invert this: form inputs are masked by default, session replay uses a rolling buffer that only transmits data when the user submits a report, and sensitive data in framework component trees is automatically redacted client-side.
What's next
FeedSnap is in private beta. We've been using it internally and with a small group of early users. Here's what's on the near-term roadmap:
Slack and Discord integrations — Real-time notifications when new feedback comes in, posted directly to a channel of your choice.
Webhooks — For teams that want FeedSnap in their existing workflows. Subscribe to events and receive HTTP payloads at your endpoint.
Public REST API — Programmatic access to feedback data for custom integrations, dashboards, or automation.
Custom fields — Per-project metadata configuration. Capture the user's plan tier, account ID, feature flags, or any application-specific context alongside every report.
If you're building a web application and spending more time reproducing bugs than fixing them, we'd like to hear from you. Join the waitlist and we'll get you set up.