The CEO who is also a user
Marshall Gould is the co-founder and CEO of Juno, a health assistant for people living with chronic illness. He holds an MSc in Genomic Medicine from Oxford, where his thesis grew out of time spent with patients between appointments, and he lived with myalgic encephalomyelitis / chronic fatigue in 2020, the same condition a large share of Juno's users have. He talks about the app as a user. "As someone who has to come back to the app every day, it's essential that everything works."
Jakub Sys is the engineer who owns Juno's release pipeline. He joined on 10 August 2026, into a codebase moving at fifty to a hundred pull requests a day, and setting up TesterArmy was his first task. Before Juno he shipped mobile apps where every change was verified by hand on emulators and real devices, with five features in flight at once and each one waiting for a build and a QA pass. The word he keeps using for the difference is confidence.
A health app you cannot test in production
Most apps learn about bugs from production. Juno cannot. "Because we are a health app, we're not getting every single person's logs, and we're not screen recording every single thing that they do," Marshall says. Juno strips personal health records from what it collects, so the team has fewer ways to watch what happens on a user's phone. "It almost becomes more important to test beforehand and make sure we have a good regression workflow. So when we enter production, we have less bugs than the average app, simply because we have less capabilities to test in production."
The cost of a bug is different too. A Juno user might log twenty symptoms a day or take twenty medications. "If I mistake taking one medication or I take the wrong dosage, that could be life-threatening. So it's not just an app where it's convenience, it's necessity."
"If I mistake taking one medication or I take the wrong dosage, that could be life-threatening. So it's not just an app where it's convenience, it's necessity."
Until August, testing was Marshall. "Before TesterArmy, it was just me tapping." A proper pass through the iOS and Android builds, screen by screen, took a day to a day and a half. With one or two updates a week, that came to two full days a week the CEO did not spend shipping or growing the company.
The update that broke sign-in
Manual testing misses things, and one miss reached users. Google sign-in on Android broke, and for a whole update nobody could sign in or sign up that way. "That caused a lot of churn. These sorts of things would have been identified easily by a regression suite, which we didn't have in place at the time."
What Juno tried first
Marshall did not go straight from tapping to TesterArmy. He had Codex run tests on a simulator. He then drove a jailbroken phone with Claude Code so an agent could tap through real hardware. That worked for payments and notifications, but standardized tests kept failing when the agent ran out of memory or lost track of what it was doing. He paid for two agentic QA products. On one, a single test was a ten-page pseudocode document. On the other, natural-language tests needed several rounds to pass once, and the agent could sit on one screen for ten minutes burning credits. Neither ran on pull requests. He cancelled both in July 2026 and posted on X that he was looking for manual QA testers.
TesterArmy came in through the same post. Jakub set it up on his first day. He handed the docs to a coding agent, uploaded the release build, and pointed the CI at the TesterArmy API on pull requests. First runs happened on 14 August. Juno subscribed on 21 August.
"Before TesterArmy, it was just me tapping."
Marshall's own explanation of why the earlier attempts fell short comes down to mobile. "On a website you can quickly test regressions in the browser. In terms of a mobile app, it's a lot more complicated. You really need to be testing on a physical device or a simulator, with an agent that understands the workflow of things it needs to test, and device logs at the same time. Without that, you can't be shipping as quickly as web apps can."
"You really need to be testing on a physical device or a simulator, with an agent that understands the workflow of things it needs to test, and device logs at the same time. Without that, you can't be shipping as quickly as web apps can."
A regression suite on every pull request, iOS and Android
Every pull request, both platforms
Juno's CI calls TesterArmy on pull requests. TesterArmy reads the diff, decides whether the change needs a run, and executes the regression suite on iOS and Android simulators, about six runs per pull request at roughly five minutes each.
Jakub arrived to a repository moving at fifty to a hundred pull requests a day, and TesterArmy gave him something to review against. "For me to actually review everything from the coding perspective and make sure it's not breaking anything was, let's say, concerning. Once we introduced TesterArmy, it was the aha moment: we can validate it. I have the very first feedback from TesterArmy, and based on that I can review it."
"Once we introduced TesterArmy, it was the aha moment: we can validate it. I have the very first feedback from TesterArmy, and based on that I can review it."
Regression on flows that must not break
The suite covers the paths a Juno user hits every day: onboarding, symptom logging, medication, notifications, the paywall, and account flows like the Google sign-in that once shipped broken. The team writes tests as plain-language user flows, so when a screen changes the agent follows the flow rather than a selector. Marshall no longer tests each pull request himself. "I don't always feel the need to test each one, because I know it goes through TesterArmy, and I know TesterArmy will find bugs in it. And it does find bugs."
From user bug report to fix in production within minutes
Juno's power users have been on the app since October and report anything that changes. The team treats those reports as the gold standard. Marshall's loop: paste the report into his own agent skill, check analytics for the issue in production, launch a simulator to reproduce it, steer the coding agent to a fix, open a pull request. "That would be reviewed by a TesterArmy agent to examine if there are any bugs, any regressions with that fix. If we've confirmed that fix works and it's a high confidence fix, then we can ship it to production and get it to our users within minutes."