Capture  ·  Triage  ·  Resolve  ·  Verify

Human finds it once.
The machine finds it
every time after.

Intake widgets are commodity. The differentiator is the autonomous back half: a report goes in, an agent reproduces it, opens a pull request, the reporter verifies, and a regression test is minted. No competitor closes that loop end to end.

Widget size
Under 40 KB gzipped
Time to submit
Under 3 seconds
Finding origins
3 (flagged, observed, graded
flagin-board: Findings
All
Open
In Progress
Verify
F-000091
Submit button unresponsive on mobile Safari
Openflagged · 3 reporters
F-000088
Dashboard count resets on page refresh
Reproducingobserved
F-000085
Sort order ignored on second filter apply
PR #3421 opengraded
F-000081
Invite email sent twice on resend
Verifiedflagged
The differentiator

Intake is solved. What comes after isn't.

Marker.io, Usersnap, BugHerd, Userback, Jam, and Canny all capture feedback. That category is commodity. Flagin's differentiator is the autonomous back half, the piece none of them have.

Other intake tools
  • ✓ Widget captures screenshot and metadata
  • ✓ Reports land in a triage board
  • – Engineer manually reproduces from the report
  • – Engineer opens issue, links PR by hand
  • – Reporter is never notified when it ships
  • – No regression test, same bug can return
  • – Signals from silent users are invisible
Flagin
  • ✓ Widget captures screenshot, console, session trace
  • ✓ Findings clustered, scored, and triaged automatically
  • ✓ Agent reproduces from captured evidence, no human
  • ✓ PR opened automatically, annotated with evidence trail
  • ✓ Reporter notified on deploy; verifies with one click
  • ✓ Regression test minted on verification, permanently
  • ✓ Signals board surfaces silent-majority behavior
The autonomous back half, no competitor has this loop closed end to end
The loop

From flag to regression test in four states

The reporter occupies exactly one position in the loop: they mark what is broken, and they confirm it is fixed. Everything in between is Flagin's job.

01
flagged › new › triaged

Flag

Anyone flags an issue via the widget. Route, build SHA, user context, console errors, network failures, and the last 60 seconds of session trace are captured automatically. The reporter only marks, they do not describe reproduction steps.

02
triaged › accepted

Triage

A triage agent clusters the Finding against open issues by route, build SHA, and trace similarity. Priority is computed from reach, impact, recency, and workaround availability. Fifteen reports collapse to one Finding, all fifteen reporters are tracked.

03
accepted › in_progress › resolved

Fix

The agent reproduces the issue, writes the patch, and opens a PR annotated with evidence and reporter count. A webhook moves the Finding to resolved on deploy, not on merge. A reporter asked to verify against an undeployed fix will report it broken again.

04
resolved › verified › closed

Verify

The original reporter receives a verify prompt with what changed and a link to the affected screen. They confirm or reopen. On confirmation, Flagin mints a regression test automatically. Human finds it once. The machine finds it every time after.

"Got it.
This is F-214."

Reporters stop reporting when nothing visibly happens

Four mechanics keep reporters engaged. Every one runs automatically, no engineering effort after initial setup.

01Immediate acknowledgment with Finding ID on ingest, in the widget, within seconds of submission.
02Status change notifications on accepted, resolved, wont_fix, and deferred. wont_fix always carries a human-written reason.
03Verify prompt on deploy, what changed, in plain language, with a one-click confirmation link. No account required.
04Weekly digest: "Here is what shipped from your reports this week." Attributed by name. This is what converts a silent user into a repeat reporter.
Finding origins

Three ways a Finding enters the system

One object, one board, one triage path, regardless of whether a human or a machine noticed the problem. All three producers emit the same Finding with a different origin field.

Origin 01

Flagged

Deliberate human act. A reporter clicks the persistent Flagin widget, available on every screen. Arrow, box, and text annotation converts vague reports into located ones. Works offline, queues until connectivity returns. Under 40 KB gzipped.

Origin 02

Observed

Ambient session telemetry detects anomalies, dead clicks, rage clicks, abandoned flows, and error spikes, creating a Finding before any user reports anything. Of 40 users, perhaps 8 will ever flag anything. The other 32 are visible here.

Origin 03

Graded

Flagin's grader runs your test suite after every deploy and scores each failure. Regressions surface as Findings with full diff context, failing assertion output, and environment metadata. Graded Findings land on the Signals board until the grader's false-positive rate is calibrated.

Canonical vocabulary

Why the record is a Finding, not a Bug

The naming is normative. Code, schema, UI copy, and documentation all follow it. The reasoning is worth knowing, it explains what the product is and is not.

WordJobWhere it appears
flag The user's deliberate act of capture. A verb, not a noun. Widget button label, "flag this," notification copy
Finding One record, something found, regardless of who or what found it. Absorbs all three origins without strain. Schema, API, detail page, GitHub cross-link
Findings The collection. Not "Issues," not "Bugs", avoids collision with GitHub Issues, which Flagin writes to. Left nav label, board title, count badge
open Non-widget creation, pasted reports, promoted Discord messages, filing on behalf of a user. Internal tooling, promotion actions, API
verify The reporter's confirmation that a fix is real. Only a human can do this. Machines resolve; humans verify. Notification copy, verification prompt, state label
Signals Observed Findings from ambient telemetry. Separate board until promoted, machine noise does not bury human reports. Signals board, passive telemetry tab
Why not Bug? Most of what arrives will not be bugs, it will be confusion, missing capability, slowness, and "this works but it is wrong." If the record is called a Bug, every one of those is mislabeled at creation. Why not Issue? Findings push to GitHub Issues. Two objects named Issue in one pipeline, one mirroring the other, is permanent confusion. Finding is the word audit and inspection use for something observed that may require action, before anyone has ruled on it. That is exactly the state of the record between capture and disposition.
Architecture

Three separable components

Intake is commodity because everyone builds it as a single-codebase feature and rewrites it for the second consumer. Flagin is three deployable pieces from the first commit. Extraction is a decision, not a rewrite.

@flagin/sdk

Capture widget

Script tag, not a React component. window.Flagin.init(). Works in any web app, any framework. Captures route, build SHA, user, environment, console errors, failed network requests, and the last 60 seconds of session trace. Screenshot annotation included.

flagin-ingest

API and Finding store

REST and webhook API for receiving, clustering, and storing Findings. Postgres-backed, own store, not entangled with the knowledge graph, so extraction requires no migration. Tenant-aware from the first commit. Build SHA required at ingest; a Finding without it is unactionable.

flagin-board

Board UI

Full triage board, embeddable in your product or hosted standalone. Filter by app, type, status, priority, reporter, and build. Threaded comments, evidence viewer, PR link, and the reporter verification flow built in. Consumes the ingest API; your application is the consumer, the data lives in your store.

Evidence trail

Every Finding carries route, build SHA, environment, console errors, network failures, session trace, and screenshot. Reproducibility before any code is touched. Reporters do not provide steps, the system does.

Autonomous PR

On accepted, the agent attempts the fix and opens a GitHub pull request annotated with evidence and affected user count. Engineers never leave GitHub. Reporters never see it. One direction of truth per field, bidirectional comment sync is where integrations die.

Duplicate clustering

Clusters by route, build SHA, console error signature, and semantic similarity. Forty users will report the same broken screen fifteen ways. Without clustering, the board is unusable by week two. Biased toward merging, a bad merge is cheap to undo.

Regression tests

On verification, Flagin generates a test from the session trace and the fix diff and commits it to your test suite. Human QA permanently upgrades machine QA. Human finds it once. The machine finds it every time after.

No wrong door

Keep accepting Google Docs, DMs, and verbal reports. Paste raw text into a Finding and the triage agent structures it, sets type, clusters it, and attributes the reporter. Discord messages, meeting notes, operator observations, all promotable in one action.

Full audit log

Every state transition, comment, evidence attachment, and agent action is logged with a timestamp and actor. wont_fix always carries a human-written reason, an unexplained decline costs more reporter goodwill than the report was worth.

Triage

Priority is computed, never declared

There is no priority field reporters can touch. Reporters always select critical, which destroys the signal. Priority is a function of real, measured data, computed on ingest, updated on new evidence.

Every Finding receives a computed score at triage:

priority_score = reach × impact × recency × (1 / workaround)
reach
Distinct affected users from cluster size and telemetry, not report count. A Finding with 1 reporter and 200 ambient sessions affected scores higher than 5 reporters on a flow nobody else uses.
impact
Type weight: broken > defect > performance > confusion > gap > enhancement. Confusion reports in a young product are the highest-signal reports received, they surface capability that nobody will ever explicitly request.
recency
Decay on first_seen, weighted hard for regressions against a recent build. Something that worked last build gets a hard multiplier. This is why build SHA is required at ingest, without it, regression detection is impossible.
workaround
1 if no workaround exists, 2 if a documented path is available. Divides priority so a show-stopper always outranks a confusing but recoverable flow, even with a much lower reach score.
Signals

The silent majority

Of 40 beta users, perhaps 8 will ever click the widget. The users quietly abandoning a flow are the strongest signal and will never report anything. A board fed only by manual intake systematically over-represents the loud.

Signals is a passive board fed by ambient session telemetry. Machine noise does not bury human reports, Signals sit separately until promoted with one action. Manual intake reports what people say. Signals report what is actually broken.

Dead clicks and rage clicks
Elements users expect to respond but don't. Often surfaces invisible overlays or broken affordances before anyone files a report.
Abandoned flows and drop-off by step
Users leaving at the same screen every time. The clearest signal that something at that step is wrong or confusing.
Repeated navigation loops
Users moving back and forth between the same two screens, which means "I cannot find it." Higher signal than a confusion report because it is a measured behavior, not a self-assessment.
Error rate spikes and time-on-task outliers
Tasks taking 8 minutes that should take 30 seconds. Error rates spiking on a specific route after a deploy. Catches regressions before any user reports them.
flagin-board: Signals
Dead click
Export button: /reports/summary
14 sessions · last 6h Promote
Abandoned flow
Drop-off at step 3 of onboarding
31 sessions · last 24h Promote
Error spike
500s on /api/clients, build 3a8f21c
8 sessions · last 2h Promote
Nav loop
Settings › Billing repeated navigation
9 sessions · last 12h Promote
Evidence & privacy

Capture aggressively. Store carefully.

A capture widget grabs whatever is on screen. In a client application that means real customer records, contact data, and financial figures. Flagin handles this with DOM-level redaction before any data leaves the browser.

Redaction before transmission

DOM-level masking runs client-side before the capture is sent. A selector allowlist and denylist is configured per tenant. Automated detection for card numbers, government IDs, and email addresses in captured text. Data never leaves the browser unredacted.

Classification before storage

Every attachment carries a DATACLASS-001 class before it is stored. Fail-closed: unclassified evidence is not stored. Evidence never crosses tenant boundaries, a tenant engineer viewing a client-app Finding sees redacted evidence unless explicitly granted access.

Configurable retention

Evidence retention windows are configurable per tenant, defaulting to 90 days. The Finding record itself outlives its evidence. Reporters can view exactly what was captured before they submit, no silent capture in the flagged path.

data-flagin-mask: mark sensitive DOM regions
<div data-flagin-mask> Sarah Johnson · sarah@company.com </div> <input data-flagin-mask type="text" value="4242 4242 4242 4242">
Built for

Every team that ships software

Whether you are a solo developer or running quality across a 20-person engineering team, Flagin fits the way you work.

Engineering teams

Close the loop on every defect

Stop chasing reporters for confirmation. The verify prompt goes out automatically on deploy. Reporters confirm from a single link, no account required.

Product & QA

Triage before it reaches the board

Findings arrive pre-scored with computed priority, reproduction steps, and evidence attached. You decide what to act on, not what it means.

Platform teams

Catch regressions before users do

Signals telemetry and graded Findings surface problems before any user flags them. Regressions against a recent build get a hard priority multiplier.

Solo developers

A complete feedback loop in one SDK

Embed the widget, connect the ingest API, and get the full lifecycle, capture, triage, fix, verify, without building any infrastructure yourself.

Agencies

Client-facing defect reporting

Give clients one place to flag issues. Findings land in your board, evidence-first, ready to triage. Evidence is redacted at the DOM before transmission, client data stays client data.

Any codebase

Framework-agnostic from day one

The @flagin/sdk is a script tag, not a React component. It works in any web application: the same widget, the same API, one board regardless of framework.

Roadmap

Where Flagin is today

Flagin is in active use across multiple applications with real-world defect intake and triage. The early access period is where we close the autonomous resolution loop before opening to the public.

Phase 1

Capture and see Live

Widget, ingest API, Finding object, filterable board, status notifications, manual triage. This ends the Google Docs era. Acceptance criterion: zero reports arriving by DM or Google Doc for two consecutive weeks.

Phase 2

Triage and close the loop In progress

Clustering agent, computed priority, GitHub issue creation, resolved webhook, verify prompt, weekly digest, and the promotion path for non-widget reports. Done when duplicate rate is under 15% and reporter verification rate on resolved Findings exceeds 60%.

Phase 3

Evidence depth Planned

Session trace attachment, evidence redaction and classification, Signals board, screenshot annotation. Redaction is required before Flagin is deployed in any application handling sensitive customer data.

Phase 4

Autonomous resolution Planned

Agent attempts the fix, opens the PR, links it to the Finding, moves to resolved on deploy, mints regression test on verification. Done when at least 25% of accepted Findings reach resolved with no human writing code.

Phase 5

Extraction and standalone product Planned

Multi-tenant hardening, standalone hosted board, self-serve onboarding, documentation, pricing. Extraction is a decision here, not a rewrite, because Flagin was built as three separable components from the first commit.

Pricing

Start free. Scale when you're ready.

Flagin is free to start. The full autonomous resolution loop is in early access. Request a spot and we will follow up.

Free
$0
Free forever
  • Up to 200 Findings per month
  • Flagged and graded origins
  • Full flagin-board UI
  • Manual triage and assignment
  • Reporter verification flow
  • 30-day evidence retention
Request access
Team
$19
per seat / month · 10-seat minimum
  • Everything in Pro
  • Unlimited evidence retention
  • Self-hosted flagin-ingest option
  • DOM-level evidence redaction per tenant
  • SAML SSO
  • Priority support
Request early access
Early access

Get on the list

Flagin is in limited early access. Drop your details and we will follow up.

No spam. We will follow up.

Got it. This is your Finding.
You are on the list. We will follow up.