Case Study — OneSafe
How OneSafe Cut Release QA From Four Days to One
COMPANY
OneSafe is a regulated neobank that gives businesses and individuals an account for moving and managing money, including digital assets.
INDUSTRY
Fintech ($200 Million)
COMPANY SIZE
1–50
FOUNDED
2021
75%
Less QA time per release
down from four days to one.
80%
Bug catch rate,
up from roughly 60% manually.
95%
Release confidence,
up from under 80% on a finance platform.
The Challenge
Manual QA on a fintech platform with one person and a day to do it.
Denise came into QA from customer service and operations, no testing background, no fintech experience. She built the process herself, working from hundreds of test cases in a Notion spreadsheet, running every flow by hand.
The problem wasn't effort. It was math. Across seven or eight payment methods, a manual pass might cover two or three. Flows got walked halfway rather than completed end to end. With a weekly code freeze and roughly a day for QA, there wasn't time for more.
When bugs surfaced days apart, releases slipped to Tuesday or Wednesday. Changes made after code freeze were sometimes missed entirely. And withdrawals, the most critical flow on the platform, where a single bug was effectively a system-down event, still left Denise less than 80% confident the platform was clean.
"A withdrawal bug was effectively a system-down event."
.png)
The Solution
47 suites, 124 tests, 2,500 runs a month, all written in plain English.
OneSafe now runs automated regression and legacy feature testing through Spur, about 2,500 test runs a month across 47 suites and 124 tests. Instead of scripting each case individually, Denise connects tests to scenario tables: a set of withdrawal scenarios written once, then reused and multiplied across new tests automatically.
Spur runs on staging before release and again on production afterward, executing every flow end to end, including the payment methods and full withdrawal completions that manual testing consistently skipped.
"I just let Spur run by itself. It is its own employee."
For writing new suites, Denise uses Spur's MCP integration with Claude. New tests that used to take one to two days to write now take one to two hours. Platform-wide edits that would once mean touching every affected test by hand take seconds.
Spur also works as a change log. When developers ship an unexpected UI or copy change, affected tests fail, surfacing changes that engineering hadn't flagged and bridging the gap between dev and ops.
The Results
Four days of QA became one and confidence crossed 95%.
The shift was immediate and significant. QA time per release fell from four days to one, sometimes two. Where a manual pass might catch five bugs over three days, Spur surfaces a comparable set in an hour or two. Bug catch rate climbed from roughly 60% to about 80%. Release confidence went from under 80% to roughly 95%.
But the bigger change was what Denise could do with the time she got back. Automating regression freed her to focus on the product itself and on managing her operations team, work that actually requires her judgment, rather than spending days clicking through payment flows.
"It is definitely one of the most useful things we have had, not just for QA but for our company in general. I would just suggest other fintech teams try it out. It would give you more security that your actual money and your actual processes and flows are being covered very comprehensively."
2,500
test runs per month
47
automated suites running on staging and production
1–2h
to write new test suites with Claude
Key Insights
OneSafe didn't hire a QA team. They gave one person, with no QA background, the tools to build one. Automated regression across every payment method. Tests that multiply themselves through scenario tables. A change log that catches what engineering forgets to mention. Four days of manual clicking became one. And Denise went from running flows to running the operation.
