DPDzero is a collections-as-a-service company that helps lenders solve delinquencies and improve their conversion rates. They are a small, fast team building in fintech. Their CTO, Ranjith, has a simple philosophy: build it, release it. Today, no commit gets merged to production unless Empirical runs are green. These tests run 16 to 17 times a day, complete in under 10 minutes, and notify the engineering team the moment a regression is found.
Challenge
Ranjith loves shipping. His ideal cadence? Releases every hour. He believes production is the best filter on quality, and the faster you get code out, the faster you learn. To keep that pace, his team invested in unit tests, backend tests, linting rules, and CI/CD.
But one thing kept eluding them: UI automation. Ranjith tried a couple of times to set it up in-house, but it never stuck. It’s a full-time job, and finding engineers who can approach test automation with the same rigor as the rest of the team is genuinely hard. So it got parked.
Without that layer, small regressions would sometimes slip into production. A user would notice something before the team did. Ranjith knew exactly what was missing, he just didn’t have the bandwidth to solve it.
“I wanted to always do UI automation and I just wasn't able to kind of do it with the focus that I wanted. It's a full-time job and you need to hire really good people who can think at the same quality of engineering as other people in the team, and hiring that is hard.”
Solution
Once Ranjith discovered Empirical, the UI automation problem he had been sitting on for a while became much easier to solve. We plugged into DPDzero’s existing branching workflow and started running tests on every merge.
The rollout happened in two phases:
Tests on Every Dev Merge
DPDzero uses two branches: dev and master. Anytime a PR gets merged into dev, Empirical runs are triggered. If something is broken, the team knows right away, before anything reaches production.
Ship to Production with Confidence
Because Empirical catches problems on dev, the team can cut a release branch and deploy to production knowing things are clean. Regressions no longer get discovered by users, they get discovered by tests.
One thing Ranjith keeps coming back to is how the forward deployed engineer model works in practice. When DPDzero needs a new test, they just tag the Empirical team on Slack. It gets done.
“Anytime there is a new test that we want to get added, we just tag the team and it happens. I just feel like I'm prompting the AI and it's happening.”
Results
Here’s what changed:
Impact
Ranjith’s team averages about four releases a day now, with no dedicated QA team. Empirical runs on every merge.
The TypeScript migration put things to the test. DPDzero was migrating their Vue.js codebase from JavaScript to TypeScript, using Claude to speed up the process. They were merging to dev six or seven times a day. Empirical caught regressions three or four times during that entire migration, each time before anything hit production.
Ranjith doesn’t have to think about test maintenance, flakiness, or infrastructure. His team tags the Empirical bot with a request on Slack, and the test just shows up.
Looking ahead
With coding agents becoming a bigger part of how DPDzero builds, the amount of code getting pushed is only going up. More code, more changes, more surface area for things to break. That makes Empirical’s role even more important going forward.
“You need to build confidence in your releases. And the best way to have confidence is to make sure you have an end-to-end integration test, and Empirical will help you do that. So don't wait for it, just go for it.”
Advice for teams considering Empirical
We asked Ranjith what he’d say to other engineering teams thinking about this. His advice was direct: start now, and don’t wait for perfect conditions.