WHY WE ADOPTED EXPO ROUTER AT SCALE

The Essent and Energiedirect apps are built by a growing Mobile App Community, with developers from multiple teams contributing to the same codebase.

As that community grew, we ran into a scaling problem that is probably familiar to many mobile teams: navigation stopped being just navigation.

It became onboarding friction. It became team dependency. It became the reason a simple question like “how do I add a new page?” could turn into a longer support discussion than it should.

When I first joined Essent, the Mobile App Community was still quite small, and most developers working on the app were part of one team. At that time, we were also moving more toward Expo, but Expo Router was not really on the radar yet. Our app navigation was built with React Navigation, a flexible and widely used library for managing screens and flows in React Native apps.

I brought Expo Router up during one of our community meetings and we discussed it together. There were good arguments in favor of it, but also good reasons not to introduce it too early. In the end, we decided not to adopt it yet. We were not feeling enough pain yet, and because we were already in the middle of another major migration, it was not the right moment to take on a change like this.

At that moment, that was the right call. A couple of months later, things started to shift.

More people joined the Mobile App Community, with different levels of mobile experience and different technical backgrounds. More teams started collaborating in the app, and we started seeing the same support question come up more often:

How do I add a new page?

That was the point where the Expo Router discussion came back, but now in a very different way.

The question was no longer whether React Navigation worked. It did. The question was whether our navigation setup still scaled well for the way we were now building the app together.

This time, as a community, we decided to adopt Expo Router.

From React Navigation to Expo Router

Our previous setup was based on React Navigation with a fair amount of manual configuration. For a long time, that worked well.

But as more teams and developers started contributing, it became clear that adding a page was not always just adding a page. You had to understand where routes were registered, how navigators were nested, how deep links were configured, and what part of the app flow you might accidentally affect.

The work itself was usually not the difficult part. The difficult part was knowing where everything lived and how it all connected.
A small team can carry that kind of knowledge for quite a while. But once your mobile community grows, a setup like that starts creating friction much faster.

We saw that during onboarding and cross-team work as well. When someone wanted to update a flow or add a screen in an area they did not know well yet, the biggest challenge was often not building the screen itself. It was understanding how that part of the app was wired into navigation, and who knew enough about it to change it safely.

That was really the core of the problem for us. It was not that our navigation setup was bad. It had simply become too dependent on central knowledge.

Why Expo Router made sense for us

Expo Router builds on top of React Navigation, but introduces file-based routing, where the folder and file structure helps define how route areas are organized.

For us, that was not mainly interesting because it reduced boilerplate. It was interesting because it reduced indirection.
Instead of having routing logic mainly live in central configuration, the route becomes much more closely tied to the file structure itself. That made it easier to understand where things lived, how route areas were structured, and where a new page should belong.

That lowered the barrier for teams working in their own feature areas and made the app structure easier to follow without needing as much background knowledge first.

That is what made Expo Router a good fit for us. Not because it is automatically better in every situation, but because it matched the stage our mobile organization had reached.

The first push started with a POC and a hackathon

Before we started migrating more seriously, we first created a POC. That gave us a much clearer view of where Expo Router fit well, where the migration would become tricky, and what patterns we wanted to follow in a real production app.

It also helped us identify things early, like how to think about layouts, route groups, shared flows, and how existing concerns such as deep links and app structure would need to keep working during the migration.

That work mattered a lot, because it meant we did not go into the migration blindly. We already had findings, conventions, and pitfalls documented before making the first bigger push.

That bigger push happened during an in-between week around Christmas, when not everyone was on holiday. People from each team who were available used that time to collaborate on the first real step toward Expo Router.

What made that week valuable was not just the technical progress. People who would normally only meet online came into the office and worked through the migration together. That made it much easier to align on structure, make decisions quickly, and share context while doing the work.

The hackathon did not finish the migration, but it turned the earlier POC into concrete progress. It gave us a real starting point, created momentum, and made Expo Router something the wider community could actively contribute to rather than just discuss.

We did it as a community

One of the strongest parts of this migration was that we did not handle it as a central platform-only rewrite.

We approached it as a community. Different teams converted their own route areas over time, and we aligned through shared discussions and conventions on how the new structure should work. That meant the teams that owned the features were also involved in migrating how those features were navigated.

If a team owns a feature, it also makes sense that they understand how that feature is structured in the app. Expo Router supported that well, because it made routing feel more local and easier to work with in the context of the feature itself.

That was a big improvement for us. Instead of one small group becoming the support desk for navigation forever, more teams could work with the navigation system themselves.

The trade-offs

Of course, that did not mean the change was free.

The biggest trade-off was migration effort. Changing the routing model in an existing app is very different from starting a fresh app with a clean structure. You have to preserve existing behavior while changing how everything is organized.

That includes deep links, current app flows, route-based analytics, and all the small edge cases that have built up over time.
There was also a learning curve. File-based routing is easier once people understand the conventions, but teams still had to learn how to think in layouts, route groups, nested flows, and shared structures.

More generally, Expo Router is also more opinionated. That is one of its strengths, but also one of its constraints. You gain consistency and discoverability, but you give up some flexibility compared to a fully manual setup.

For us, that trade-off was worth it.

What changed for us

What changed most for us was pretty simple: navigation became easier to work with.

It became easier to add new pages, easier to explain the app structure to new people, and easier for teams to work on their own route areas without needing as much help from others.

That was the real win for us. Not just changing libraries, but ending up with a navigation setup that fit much better with how we were actually building the app as a growing mobile community.

That is really why we adopted Expo Router at scale.

When the community was smaller, our previous setup was good enough. But once the community grew, we needed a navigation model that scaled better with both the app and the people building it.