How SoFi Scales Mobile Engineering with Flutter and AI

In our latest Build to Succeed episode, Phil Rabin, SoFi's Director of Mobile Engineering, shares what it really takes to scale one of the largest Flutter teams in production—while managing explosive code growth, adopting AI-driven workflows, and shaping the culture and systems that keep engineers moving fast. Here we highlight key insights from our conversation.
‍

The Early Journey That Forged a Mobile Engineering Leader
‍

Phil’s path into engineering leadership didn’t begin in a Silicon Valley unicorn—it started in Vancouver, in the ’90s, with a teenager who liked building websites when almost nobody else around him did.
‍

That curiosity led him to the CBC (the Canadian Broadcasting Corporation), where he helped build CBC Radio 3, a pioneering digital music platform that became a backbone for indie music in Canada. Long before “creator platforms” were a buzzword, Phil and his team were experimenting with social listening, streaming, and interactive features.
‍

From there, he moved into startups, then eventually to San Francisco. One startup folded (“classic story,” as he puts it), but another opportunity quickly followed: Uber.
‍

At Uber, Phil joined as one of the first 75 engineers and one of the earliest mobile engineers. He learned mobile on the job, just as the company was becoming a global phenomenon. Over the years, he built and led platform work for the core Rider app, Jump bikes and scooters, and Uber Eats. 
‍

He watched Uber evolve from a few hundred people to tens of thousands. He saw the growing pains, the scaling problems, the architectural resets, the cultural shifts. And he saw a pattern: As systems grow, the problems change.
‍

Early on, the challenge is “Can we build this?” At scale, the challenge is “Can we keep this understandable and sustainable?”
‍

From Uber’s Hyper-Growth to SoFi’s Super App Vision

‍

After nearly a decade of hyper-growth at Uber, Phil stepped away for a well-earned break—but it didn’t last long. As he watched the AI boom accelerate, he realized he wasn’t done building. He wanted to return to an environment where his experience scaling teams and systems could make an outsized impact. 

‍

That opportunity came when SoFi reached out. The company was in the midst of its own transformation, evolving toward a mobile-first “financial super app” and preparing to dramatically scale both its team and its Flutter codebase. Phil was looking for a director-level role at a growth-stage company facing real scaling challenges, and SoFi checked every box. 

‍

“Code Is Becoming Free to Write”

‍

This is one of the most striking ideas Phil brings to the conversation. When SoFi rewrote its mobile app in Flutter, the codebase started growing quickly. Then AI tools entered the picture, and the growth curve suddenly went from steep to very steep.

‍

Phil lays out the numbers almost casually, but they’re stunning: “In the first couple of years, we added about a million lines of code. Last year, another million, and 500,000 last quarter alone. AI tools and a growing team make the curve steep. At that scale, code management becomes its own engineering problem—we’ve had to evolve our developer tools and workflows just to keep up.”

‍

It’s not just that more features are shipping; it’s that AI-assisted development is allowing teams to produce code—including tests—at a pace that would have been unimaginable a few years ago.

‍

A thousand lines of code per engineer per month doesn’t sound wild until you realize AI can generate hundreds of lines in seconds, especially for test scaffolding and boilerplate. For SoFi, that means new products like SoFi Pay can be backed by thousands of tests generated and refined in a remarkably short period of time.

‍

But the flip side is just as important: Once you reach millions of lines of code, the codebase itself becomes a platform that needs architecture, governance, and tooling just as much as any product feature.
‍

Build times, CI pipelines, indexing, and test suites can all become drag factors if they’re not deliberately engineered for scale.
‍

Why Flutter Made Sense for SoFi
‍

By the time Phil joined SoFi, the company had already made a big their bet: the mobile app would be built in Flutter.
‍

For someone who spent years living the pain of maintaining separate native iOS and Android apps at Uber, that decision was a welcome one. “The decision to use Flutter was an awesome one”, Phil says. “With Flutter, everything is pixel-perfect across devices, since the rendering engine ships with the binary. At Uber, keeping two apps in sync was a huge effort. Flutter’s made it dead easy comparatively. 
‍

At Uber, balancing teams across platforms was a constant headache. If one team ended up with three iOS engineers and one Android engineer, the roadmap drifted. Features landed on one platform earlier, the other lagged. Keeping UX consistent across devices required enormous overhead and meticulous coordination.
‍

With Flutter, Phil sees a fundamentally different dynamic:

• One codebase, not two
• One set of engineering standards
• One training pipeline for new engineers
• Pixel-perfect consistency across devices
  ‍

For a company positioning itself as a “financial super app,” that consistency isn’t just nice—it’s strategic. It means the mobile team can move faster without fighting fragmentation every step of the way.
‍

You Can’t Scale Without a Platform Team

Even with Flutter as a unifying layer, SoFi’s growth created new scaling challenges. More engineers, more features, more products, more lines of code—and all of it shipping weekly into a single app.

‍

To keep that from collapsing under its own weight, SoFi made a deliberate investment in platform engineering. As Phil puts it, “You can't get to scale without having a strong platform team. The goal is to make product engineering fast and easy. You want the product teams to be able to crank out new features, get products to market really fast, iterate on UIs, find the product-market fit, and onboard new users.”
‍

Phil’s platform team is highly senior—staff and principal-level engineers who live and breathe architecture, tooling, and developer experience. Their mission is simple and ambitious:
‍

• Make it easy to do things the right way.
• Make it hard to accidentally do things the wrong way.
  ‍

That means:
‍

• Building and enforcing design systems
• Removing friction from CI and release pipelines
• Modularizing the app so that not everything lives in a single massive package
• Moving away from global service locators toward proper dependency injection with tools like Riverpod
  ‍

Turning the Codebase into a Code Factory

Phil often talks about SoFi’s engineering environment as a code factory—not because it’s mechanical or soulless, but because at scale, reliable production becomes a discipline in itself: 
‍

“You have to do capacity planning, start looking at all of your pipelines, and try to speed up development time, onboarding, and CI runs,” he explains. “You’re looking for efficiencies across your entire pipeline. You’re generating a giant code factory, and that code has to go out every single week. So there’s automation across every part of your stack. Pushing code out and getting everything tested becomes a big effort, so all those things need to scale up.”
‍

Every part of the pipeline becomes its own engineering problem:
‍

• How fast can a new engineer become productive?
• How long does it take to run tests on a merge request?
• How stable is the build?
• How often does CI get in the way instead of helping?
• How can you shard tests or modularize code to keep everything manageable?
  ‍

At SoFi’s scale, even “simple” things like switching branches or indexing a repo matter. They shape how engineers experience their day-to-day work. A little friction might not seem like a big deal until you multiply it by hundreds of people, every day, for months.
‍

A Simple Rule That Changed the Culture
‍

One of the most surprisingly powerful moments in the conversation isn’t about tools or architecture. It’s about how knowledge moves through a team.
‍

Phil describes a cultural rule he introduced.
‍

“One of the most powerful cultural shifts we made was a simple rule: never answer a Slack question without a link or documentation. It forces the team to document the right way to do things, and it eliminates repeated questions. Over time, that one habit transformed how knowledge moved through the organization.”
‍

Instead of long Slack threads with slightly different answers every time a problem resurfaces, engineers are gently nudged toward:
‍

• Writing documentation
• Improving existing docs
• Sharing links instead of opinions
  ‍

It’s a small behavior change with a huge ripple effect. Over time, it turns tribal knowledge into shared institutional knowledge. It makes onboarding smoother. It reduces confusion. And it reinforces a culture where clarity and consistency matter just as much as raw speed.
‍

Leadership as Energy Management

For all the talk about scale, pipelines, and frameworks, Phil keeps coming back to something very human: how people feel at work. He believes deeply in radical candor and in treating people well—not as a nice-to-have, but as a strategic necessity.
‍

If people are misaligned, unclear, or stuck in constant friction, they burn out. If they’re doing hard, meaningful work with support and trust, they’ll pour energy into it.
‍

Phil imagines the book he might one day write about his career and leadership philosophy. The title he gives is simple and telling—“Treating People Right, and How to Motivate Teams Without Burning Out.”
‍

His view is straightforward. People love doing hard things when they’re aligned with the mission, supported by good systems, and given real opportunities to grow. The job of a leader is to create that environment—especially when everything around them is scaling fast.
‍

Listen to the Full Episode Here
‍

For engineering leaders, product leaders, and anyone building ambitious digital products, Phil’s experience offers something rare: a ground-level view of what it actually means to scale in this new era—beyond hype, beyond tools, down to people, practices, and decisions.
‍

If you’re navigating similar questions at your own organization, or you’re just curious how teams like SoFi’s operate behind the scenes, this episode is a must-listen!
‍

‍