For beta testing

Beta testers report what they remember. The browser remembers the rest.

A beta is a short window in which people who owe you nothing are willing to tell you things. Every step you put between noticing a problem and reporting it — an account, a form, a Slack invite, an email address to find — spends that willingness on administration.
Start freeNo credit card required.

The situation

What this usually looks like

  • Testers report in whatever channel is nearest

    A WhatsApp message, a Slack DM to whoever invited them, a reply to the announcement email. None of it is in a list, and half of it is lost by the end of the week.

  • "It crashed" is the entire report

    They were testing, not documenting. Asking a beta tester to open the console and paste the error is asking for work they did not sign up for, and most will not do it twice.

  • Onboarding testers into a bug tracker fails

    Inviting fifty people to Jira or Linear produces a handful of accounts and a lot of unread invitations. The tool your team lives in is not the tool your testers will use.

  • The same bug arrives five times, described five ways

    Without the technical context you cannot tell whether those are one bug or five, so you triage the descriptions instead of the problem.

Why this fits

What changes for beta testing

Testers need no account at all
The button is on the page they are already testing. They type a sentence and press send. Nothing asks them to register, accept an invitation or install an extension first.
The technical half is automatic
Browser and version, operating system, window and screen size, time zone, up to ten JavaScript errors with stack frames, and the last fifty clicks, form submissions and page changes.
Duplicates become obvious
Five vague reports that all carry the same stack frame and the same route are visibly one bug. That is the difference between a triage session and an afternoon of guessing.
You can close the loop with testers
Move a report to shipped and the tester who found it is emailed, in their own language. People who see their reports acted on keep testing; people who hear nothing stop within a week.

Who this is not for

Save yourself the trial

If your beta is a mobile app or a desktop binary, the widget cannot help — it lives on a web page. If your testers need to annotate screenshots with arrows and notes as part of the process, Marker.io and BugHerd are built around exactly that and this is not. The comparison pages say which tool we would send you to instead.

FAQ

Questions

Do beta testers need to install anything?
No. There is no extension, no app and no account. The widget is already on the page you asked them to test, so reporting is one tap for someone who has never heard of your bug tracker.
Can I keep beta feedback separate from production?
Yes. Create a separate project for the beta build with its own key, inbox and domain allowlist. Projects are unlimited on the plan, so running one per environment costs nothing.
How do I know which tester sent which report?
If your beta build knows who is signed in, pass that id with identify and every report arrives attached to the tester. Otherwise they can leave an email, which is optional but usually given.

Put it on your site today.

One script tag. Unlimited projects, widgets and reports on one plan, and your users never make an account.