How Protopia Got Developers Out of Manual Regression With Amikoo
Every multi-region release used to pull Protopia's developers away from product work to help with manual regression. With Amikoo, Protopia's solo QA engineer now runs repo-native Playwright tests across regions, cutting deployment testing from two to three days to about one day, catching three defects before production, and eliminating the need to pull developers into manual test passes.
Impact at a glance
Maggie Hernandez, QA Engineer at Protopia, on going from zero test-automation experience to owning a multi-region Playwright suite.
Before Amikoo, I was manually testing everything… it was very time consuming for one person to do, and I was getting help from the development team.
The challenge
Protopia's AI-powered platform supports personalized donor experiences and connects job seekers with expert resume feedback tied to charitable giving.
As Protopia expanded into more regions, every release became harder to validate. Customer privacy requirements meant systems had to run separately across regions including Asia, Australia, the UK, and Canada. Each environment still needed to behave the same way, so the same regression and integration workflows had to be repeated across every region.
That work fell primarily on Maggie Hernandez, Protopia's only QA engineer, who also supports production. One person could not absorb the entire multi-region regression pass, so developers had to step away from product work and help manually test releases.
Protopia explored automating the work themselves. Selenium introduced too much learning overhead. Raw Playwright was more promising, but learning the framework and authoring the tests still took more time than the team wanted to spend on maintaining E2E automation.
The shift
Maggie connected Amikoo to Protopia's existing GitHub repositories and explained how the product works and how users move through it. Amikoo read the codebase and generated working Playwright tests for the workflows the team cared about.
The important part for Protopia was not simply generating tests. It was reducing how much testing work the team had to own themselves.
The tests are standard Playwright TypeScript and live inside Protopia's own repositories. They can be reviewed alongside the rest of the codebase instead of being locked inside a proprietary testing platform.
When Protopia's application behavior caused an early generated test to miss the right field identifiers, Maggie did not need to rewrite the test from scratch. She corrected Amikoo, and the agent adjusted the test.
The team also started deliberately with the flows that matter most to a release: the primary user happy paths and the workflows that can block a deployment.
Because of the connection between the repos or the GitHub repositories we have with Amikoo, it started working when I was explaining it.
The result
- Developers stopped doing manual regression. The test passes that previously pulled engineers away from roadmap work now run without them. Releases no longer require the development team to spend days helping QA validate the application across regions.
- Multi-region deployment testing dropped from two to three days to about one. The same release pass can now be completed by one QA engineer, even with a heavy ticket load, without borrowing developers to finish it.
- Three defects were caught before production. Issues that previously would have surfaced only when someone manually walked through a workflow were caught during automated runs before customers encountered them.
- The suite focuses first on what gates a release. In its first few months, Protopia built 28 Playwright tests across six files. Rather than chase test count for its own sake, the team prioritized the workflows that could block a deployment. Coverage is continuing to expand from there.
What's next
Protopia is now expanding beyond the initial happy paths into internal approval and rejection workflows, with additional email validation also on the roadmap.
Maggie is also using Amikoo's Worker, which generates tests from changes in pull requests. That means E2E coverage can grow alongside the application instead of waiting for a manual testing pass after deployment.
The direction is simple: move more of the testing work earlier in development, keep the tests visible and reviewable in the team's repo, and continue reducing the amount of manual regression anyone at Protopia has to own.
Get E2E testing off your developers' plate.
Connect your repository, show Amikoo how your application works, and build repo-native Playwright coverage around the workflows that matter most, without turning your developers into full-time test automation engineers.
Book a demo