Most people evaluating a testing service want to know one thing that the pricing page does not answer: what actually happens after I hand over my app?
So here is the whole process, start to finish, with no marketing gloss.
Step 1 — You submit a run
You start a run from your dashboard. It takes a couple of minutes and asks for three things.
Your build. Whatever form it takes:
- An Android APK or AAB uploaded directly
- A Play Store closed testing opt-in link
- A TestFlight invite link
- A staging or production URL for web apps and PWAs
- A browser extension package
Your target coverage. Which platforms, which OS versions, and which regions matter to you. If you have a specific device class in mind — older mid-range Android, tablets, a particular OS version — this is where you say so.
What you want tested. This is the field that determines how much value you get, and it is worth spending five minutes on rather than thirty seconds.
You can write it as freely as you like, but the most useful version is a short list of flows:
1. Sign up with a new account, all the way to the first saved project
2. Buy the Pro plan. Also try a card that will be declined.
3. Use the app with wifi off, then reconnect
4. Change the profile photo, force-close, reopen — is it still there?
Known issue: the settings screen is untranslated. Don't report it.Four specific assignments produce dramatically better results than "have a look around and tell me what breaks." Listing known issues matters too — otherwise you pay attention for things you already know about.
If you would rather not write it yourself, describing your product in a sentence or two is enough for us to build the brief.
Step 2 — Testers get matched
You do not recruit, brief, chase, or talk to anyone. That is the entire point of the service.
Testers are matched from a vetted pool against what your run needs — the platform, the OS versions, the device classes, and the regions you specified. Runs are deliberately over-provisioned, because some proportion of any tester group drops out of any test, everywhere, always. Over-provisioning is how you end up with the coverage you asked for rather than most of it.
If your run is a Google Play closed test, this is also where the 12-tester requirement gets handled: real accounts, opted in, staying opted in for the 14 continuous days Google requires. We wrote a full guide to that requirement if you want the details.
Step 3 — Testers actually use your app
Each tester installs your build on their own real device and works through the brief.
That phrase — their own real device — is doing a lot of work. It means your app runs on hardware with a real life on it: storage that is partly full, notifications arriving mid-flow, a real mobile network, a manufacturer skin with its own battery optimisation, whatever font scaling that person actually uses. That is the environment your users are in, and it is the environment an emulator structurally cannot reproduce.
Testers are working through your flows deliberately rather than racing a stopwatch. Nobody is rewarded for skimming.
When something goes wrong, they capture it properly: what they did, what they expected, what happened instead, on which device and OS version, with screenshots. Critical bugs get a screen recording.
Step 4 — Submissions get verified
Raw tester output is not a report. Before anything reaches you, submissions are reviewed:
- Duplicates across testers are merged into one issue
- Reports missing steps or device context get sent back
- "Not a bug" reports and misunderstandings get filtered out
- Severity is assigned consistently rather than by whoever felt strongest about it
This is the step that separates a structured report from a chat thread full of screenshots, and it is the step most DIY testing setups never get to.
Step 5 — Your report lands
You get a structured report in your dashboard containing:
- Bugs with severity, each with numbered reproduction steps
- Screenshots attached to every issue
- Screen recordings for critical bugs
- Device and OS context on every report — model, version, platform
- Task completion status per tester, so you can see what was actually covered rather than assuming
- PDF export of the whole thing, for sharing with a client or a team that does not use your dashboard
The important property is that each issue is actionable on arrival. A developer should be able to open a bug and reproduce it without a round of follow-up questions. That is the standard we hold reports to, and it is the difference between testing that saves engineering time and testing that costs it.
Step 6 — You fix, then run it again
Testing is not a one-time event. Every release is a new surface. Subscribers get consistency across runs — the same testers seeing your app over multiple releases, which is how regressions get caught rather than shipped.
If you would rather not commit to a subscription, credit packs work the same way without a monthly plan. One credit is one test run.
What it costs you in time
Realistically:
- Two to five minutes to submit a run
- Zero minutes managing testers
- However long you spend reading the report and fixing what it found
That is the whole time commitment. Everything between submission and report is handled.
Start one
If you have a build sitting in TestFlight or a closed track right now, that is all you need to begin.
- [Start a test run →](/client/tests/new) — submit a build and go
- [See pricing](/pricing) — plans and credit packs, no contract
- [Create an account](/auth/signup) — if you want to look around the dashboard first