At a glance
- 6M+
- users helped find lost 401(k)s
- $1B+
- in retirement assets reconnected with their owners
- 4+ years
- running production browser automation on Browserless
- Top 20
- U.S. retirement providers automated through Browserless
There's nothing better.
That's how Cyrus Ghazanfar, co-founder and CTO of Beagle, answered when we asked what's kept his team on Browserless after four years.
It's a short sentence, and a high bar. Beagle is consumer fintech: every signup is a real person hoping to find money they thought they'd lost. The browser infrastructure underneath that experience can't be flaky, can't drift, and can't page Cyrus's team at 2 a.m. For four years, it hasn't.
Good infrastructure disappears. This is the story of how Beagle's did, and why a CTO who tests every new browser-automation startup that ships keeps coming back to the same one.
The problem Beagle is solving
Most American workers change jobs every few years. Most leave a 401(k) behind when they do. Across a career, that adds up to a country full of forgotten retirement accounts, invested at former employers, bleeding hidden fees, eventually swept into safe-harbor IRAs that are even harder to find.
Beagle was founded in 2021 to fix that. A user signs up, hands over a few PII fields: name, date of birth, SSN, and Beagle goes out and finds their old accounts across dozens of providers. From there, users can roll funds into an existing IRA, their current employer plan, or into an IRA Beagle manages on their behalf.
We've found 401(k)s for over six million users and transferred more than a billion dollars.
The conversion to a paying user, Cyrus told us, scales directly with how many accounts Beagle finds. The more accounts surfaced in that first session, the more users convert. Browser automation that fails costs Beagle revenue in real time.
That's what "mission-critical" means in practice. It isn't an adjective in a brochure. It's a conversion curve.
Why "just build it" wasn't an option
Cyrus is a hands-on technical founder. He built the original integration with Browserless himself. Back in 2021, he also tried building the alternative.
Previously I tried to do, I mean, what you guys do at Browserless, a virtual frame buffer, basically tricking the rendering part. As you guys know, that's a whole company in itself. We're not in the business of creating headless browsers.
The implementation, he told us, isn't even the hardest part. The hardest part is what comes after the first version works:
The implementation is probably fine. It's the management of the session, making sure it's fault-tolerant. Those other pieces that are more like ops and DevOps and infrastructure. Those are the harder ones. And everything keeps changing. Browsers need to be updated to the new version of Chrome. All that stuff. It's a cat-and-mouse game.
Asked what it would take to rebuild this in-house today, even with AI help, Cyrus didn't hedge: months of work, then maintenance forever.
I already maintain the scrapers. I have other stuff to do.
For a small engineering team running a fintech product against financial portals that change every Tuesday, the build-vs-buy math isn't close. Browserless takes the meanest infrastructure problem in the category: keeping a fleet of real, undetected browsers alive at scale, off Beagle's roadmap entirely.
How Browserless fits in the stack
Beagle's scraping architecture is intentionally lean. The team's first move on any provider is the lightest path that works. When it doesn't, browser automation steps in.
For some providers, the API path doesn't work. The portal needs a real browser to acquire valid cookies, execute provider-side JavaScript, or pass session-level checks before any request is accepted.
Beagle doesn't run a browser for every user; only when one is necessary. Those moments cluster where the money is: 90% of U.S. 401(k) assets sit at the top 20 retirement providers, and Browserless covers the ones that require a real browser to access.
The setup is straightforward. A dedicated v1 fleet, scaled up last year as user volume grew, provisioned to keep latency low when a user signs up and the search has to happen now. Newer scrapers run on v2 with Playwright; the Selenium ones stay on v1.
We have to scale very quickly, and we have to be concurrent; everything happens within the same session when the user signs up. It has to be fast.
For four years now, this is the part of Beagle's stack Cyrus doesn't think about. That's exactly what production infrastructure is supposed to do.
Four years in: what kept Beagle here
Browserless has been in production for nearly nine years. Beagle has run on it for over four, half our entire production history. In that window, Beagle grew from launch to six million users, Browserless shipped v2 alongside v1, and a wave of AI-era browser-automation startups arrived (most one to two years old today). The infrastructure underneath Beagle didn't change shape. It just kept working.
We asked Cyrus directly: what's kept you here?
There's nothing better. We're happy.
That's the operator-grade version of a glowing review. Cyrus is the kind of CTO who tries every new browser-automation startup that lands on his Twitter feed, runs a consistent test suite against each, and switches the moment something objectively beats his current setup. Four years of "we're happy" from that profile of buyer is a different kind of endorsement than four years of inertia.
What changed under the hood matters too. Beagle started on a v1 dedicated deployment. Last year they grew the fleet from 10 to 15 workers. They added v2 alongside v1 for Playwright support, without disrupting the Selenium scrapers already in production. The infrastructure scaled with them: no rewrite, no re-architecture, no vendor switch.
Engineering time, support, and the things that actually move
Cyrus rolled the team's reasons for staying into a single CTO-to-CTO recommendation:
I usually say: we've been using them for more than four years, they've been reliable, it works well.
Three things sit underneath that:
Engineering time saved. Beagle's small team doesn't run a Selenium grid. They don't keep up with Chrome version churn. They don't operate the fault-tolerance layer around session management. That's months of build time avoided, and, more importantly, ongoing maintenance avoided forever. Cyrus is explicit that he doesn't want that work, because he already has scrapers to maintain.
Reliability that survives Beagle's growth. A demo isn't production. Production holds up while a fintech company goes from launch to six million users and a billion dollars transferred. The dedicated-deployment model carried Beagle through that growth, and through our own evolution from v1 to v2.
Support that shows up. Cyrus singled out Browserless's responsiveness, and named Alejandro on the team, when asked about the support experience.
Very good. Actually, very responsive. The support has been really good.
What's next
Beagle is building deeper consumer flows on top of its 401(k) recovery foundation. Each new flow raises the bar for the browser layer underneath it.
Browserless is built for that. Our roadmap, continued investment in stealth, fingerprinting, and the new Smart Scrape API, is shaped by exactly this kind of customer.
Four years in, Beagle's answer to "is this still the right browser layer?" hasn't changed:
There's nothing better.
Want the same outcome?
Running browser automation that has to behave like infrastructure? Fintech, healthcare, recruiting, anywhere a flaky session is a real-world problem. A dedicated deployment is built for you.
Stop building browser infrastructure. Start shipping.
30-MIN CALL · BRING YOUR STACK