Questions we actually get asked.

Testers who did valid, in-scope work are still paid — base mission pay is not contingent on finding something. A clean run is a real result: a record of what was tested and by whom, not a claim that the product is bug-free.

A bug is an objective defect a second person independently reproduced, with steps and evidence attached — it goes into your queue for your agent to fix. A Product Signal is judgment: what confused someone, what felt slow, what they expected instead. Signals are optional input, never verified defects, and nothing acts on them automatically.

No. A bug reaches DONE only after a human retests the fix, and the database rejects the write if the actor asserted on that transition is an agent, or if no human actor is asserted at all. This is not a policy an integration can opt out of.

Only the tester assigned to the mission, and only while it is active — access is least-privilege, short-lived, and revoked at completion or expiry. Where possible we use disposable accounts and synthetic data rather than anything of yours.

By relevance, not availability — device and OS, language and country, the domain they work in, and how close they are to the customer you are actually building for. Testers are trained and certified, and a probationary tester's first missions are reviewed before their scope opens up.

The product ships in English, Spanish, Portuguese, Russian or Ukrainian, and testers are recruited across those language regions. A translated finding is reviewed by someone who speaks the language, not just the tester who filed it — a translation is never trusted to preserve meaning on its own.

A run is quoted from seven factors — effort, tester count, required relevance, device scarcity, urgency, verifier load and any bounty you add — not a flat per-seat rate. See pricing for the full breakdown.

Credits move through tracked states — reserved when you fund a run, then spent, released or refunded depending on outcome. See the refund policy for the exact terms.