2 min reading time. Any thoughs about the article email?👉 pauline.mialhe@happo.io!
This article continues a conversation with Henric, CEO and co-founder of Happo. Henric co-founded Happo in 2016 with Joe Lencioni. I really value these moments with him. They give me the chance to slow down, spend 15 min (sometime more) learning more about our technical craftmanship and dig on what is our product at Happo. It’s also a way to talk with my colleague about his work and his daily tasks.
During this second interview, we spoke about screenshot testing on mobile. On the web, it has become almost second nature. Tools for React and other front-end frameworks make it easy to capture snapshots, compare them across versions, and catch visual regressions early. On native mobile apps like iOS and Android, the picture changes. The challenges touch scalability, developer speed, and the long-term health of the codebase.
To understand how teams face these issues, I sat down once again with Henric.
Pauline : On the web, screenshot testing feels smooth and familiar. But you say it’s very different on mobile. What makes it so hard?
Henric : On the web, there are plenty of tools and good practices. Mobile developers often don’t have that. They end up building their own setups, and most of the time that means keeping screenshots directly in the repository.
It works in the beginning, but it doesn’t take long before problems show up. The repo fills up with thousands of PNG files. Builds and clones slow down because every developer has to download gigabytes of data. And each UI change means generating new snapshots, which makes maintenance painful.
For small projects, maybe it’s still fine. But as soon as you grow, snapshot testing stops being a help and becomes a drag.
Pauline : So when teams hit that wall, what happens next?
Henric : We’ve seen it clearly with a large social media company. They had built their own snapshot testing system for Android using Roborazzi. It generated screenshots quickly and without devices or emulators. That part worked really well.
But creating screenshots wasn’t the problem. The real struggle came after: comparing them across versions, dealing with the explosion of PNG files, and keeping the repo usable for hundreds of engineers.
Their system was fine with dozens of tests. At thousands, it broke down.
Pauline : That sounds like a scale issue. How did you approach it with Happo?
Henric : Exactly. The problem wasn’t taking screenshots, it was managing them at scale. Their system could create images, but storing them in the repo was slowing everything down.
So we built a Gradle plugin to connect their setup with Happo. It did three key things: it found screenshots from Roborazzi, uploaded them to Happo through our API, and compared new ones with older ones while generating reports.
With Happo handling storage, diffing, and reporting, their workflow stayed the same, but suddenly it could scale.
Pauline : And what difference did that make for their developers day-to-day?
Henric : A big one. The repository became light again. Builds got faster. And comparisons were simpler.
No more bloated repos with thousands of PNGs.
Faster comparisons, because Happo only looks at what actually changed.
And scalability: the workflow worked smoothly for hundreds of developers in parallel.
Pauline : If other teams are listening to this, what should they take away from the story?
Henric : A few things. First, don’t think screenshot testing is just about capturing images. The real challenge is comparing, storing, and scaling them properly.
Second, scale changes everything. A manual setup might be fine for five or ten developers. But once you’re dozens, it quickly becomes a bottleneck.
And last, choose the right path for your situation. If you’re starting fresh, build screenshot management in from the beginning. If you already have a big legacy setup, the best way forward is to externalize and automate step by step.
Pauline : So the big picture is clear. But what’s the takeaway for teams working on native apps right now?
Henric : Screenshot testing remains one of the best ways to protect the look and feel of your app. On mobile, it comes with extra hurdles, but those hurdles can be solved.
This case proved it. By externalizing storage and letting Happo take care of comparison and reporting, a system that was slowing down hundreds of developers became fast and reliable again.
Pauline : Thank you Henric for your time!
Henric : Thanks! But wait, before we wrap up — what’s your next article about?
Pauline : I’m working on an interview with our other co-founder, Joe Lencioni. He’ll be sharing his thoughts on “Why every senior developer I know is planning their exit” — an article he posted on his channel that I want to dig into. It was a ride with Joe, going from his days candy company at school, to empathy in design, and the ergonomics of a wooden spoon handle as a metaphor for his interest with user experience.
Henric : Wow. Candy hustling and wooden spoons? Both articles sound nice. Can’t wait to read them.
That will be the next interview. But before that, the upcoming article will take inspiration from another question many teams face: Should we build our own tools or integrate external solutions? The answer isn’t always one or the other. Often the most effective approach is a mix of both.
