About Bukuwarung. Bukuwarung builds bookkeeping, payments, and credit tools for over a million small businesses across Indonesia, helping owners move off paper ledgers and onto a single app.
📋Customer Story
Bukuwarung made mobile QA less dependent on spare engineering time
Bukuwarung runs five apps on a single Android codebase, serving small businesses across Indonesia. Their Engineering Team Lead, Bhanu Sisodia, walks through what automation looked like before Panto, what a shared codebase made painful, and what changed after.
5 apps1 shared Android codebaseLean QA team
The Shift, At A Glance
What changed across three pressure points
Before getting into the detail, here's the short version of what moved for Bukuwarung's QA team.
DimensionBefore PantoWith Panto
Automation backlog
Inconsistent
Actively maintained
Test creation
Requires deep coding
GUI based, low code
P0 validation
Frequent friction
Caught earlier, pre-QA
Before Panto
An automation backlog that never got a dedicated line
Bukuwarung's QA team is small and stretched across five apps that all ship from the same Android core. Automation work had to compete for time with everything else on the roadmap.
“The automation timeline was uneven due to competing priorities. Given our lean team structure, it was challenging to allocate dedicated bandwidth consistently for addressing the automation backlog.
Bhanu Sisodia, Engineering Team Lead, Bukuwarung
The Biggest Headache
One codebase, five apps, full blast radius
Three issues kept resurfacing, plus one fix the team is putting in place to get ahead of them.
Build fragmentation
Different Android builds often introduced failures on different screens, making it hard to keep the automation suite stable from one release to the next.
Shared codebase, shared risk
All five apps share a single Android codebase, so even a small change could ripple into automation scripts across every app, multiplying debugging and maintenance work.
Developer testing gaps
The FE and Android teams weren't always close to the end to end business flows, which created friction during P0 validation, with some critical scenarios only surfacing once testing began.
The fix in motion
IN PROGRESSA standard set of automation scripts developers can run against their own feature branches before raising them for QA, catching issues earlier and easing back and forth on P0 releases.
What Changed
Automation that doesn't depend on who has spare cycles
For a lean team juggling five apps, the biggest unlock wasn't a single feature, it was accessibility. A GUI based workflow meant test creation and maintenance no longer required deep coding expertise, so the backlog stopped depending on which engineer had a free afternoon.
“Ease of use was a key focus. There are very few GUI based tools available in the market that make mobile app automation and testing accessible without requiring extensive coding expertise.
Bhanu Sisodia, Engineering Team Lead, Bukuwarung
“A productivity tool you don't realize you need until you start using it.
Bhanu Sisodia · Engineering Team Lead, Bukuwarung
Why Teams Switch to Panto
Autonomous QA across 150+ real Android and iOS devices
Panto runs a swarm of agents against your app around the clock, covering every workflow on real hardware instead of emulators, then hands you one report with the root cause already worked out.
Real device first execution
Tests run on the actual phones and OS versions your users carry, not emulators, so platform specific bugs get caught before release.
Self healing automation
When the UI changes, Panto adapts the test flow on its own instead of leaving a broken script for someone to fix.
Natural language test creation
Describe a flow in plain English and Panto walks through it step by step, no scripting required to get a reusable test case.
⚡ Go live in 60s