How did Arta Finance’s client engineering team decide on Flutter as the framework for their iOS, Android, and web apps?

Jishnu Mohan, a software engineer at Arta with a background at Google, discusses the key factors that influenced this choice. He shares insights into the project’s early stages, initial challenges, and its evolution, offering a behind-the-scenes perspective on why Flutter was selected and how it has shaped Arta’s app development journey.

What factors influenced the decision to build Arta's web application using Flutter, and how did the team balance the trade-offs between web and mobile development?

During Arta's friends-and-family and early access phase, the application was initially designed to be mobile-only. The only way to use Arta was to install the app from the Google or Apple stores.

One key bit of feedback we received from users was a strong preference for handling sensitive tasks—such as onboarding, signing legal documents, creating investments, and transferring money—on a larger screen. The most logical response to this, while reducing friction in the user acquisition process, was offering a desktop web experience for Arta.

For several reasons, the fundamental decision was to use Flutter Web for the application rather than build a new one with a framework like React or Angular. Firstly, Flutter allowed us to ship faster since running the application in web mode already worked, and the app wasn’t heavily tied to native mobile functionality. We could also leverage the existing codebase for RPC integration and other business logic, making the transition more seamless. Additionally, our frontend team was already well-versed in Dart and Flutter, with established development processes in place, which further streamlined the process.

Secondly, by sharing the same codebase, we ensured easier maintenance and minimized the risk of divergence. Using a single frontend framework and language reduced context switching for developers, allowing for more efficient work. Maintaining one unified codebase also helped us avoid inconsistencies in UI or features between web and mobile, which could have occurred if different teams had managed two separate applications.

We made this decision fully aware of some potential downsides. For instance, Flutter Web might not have the standard 'feel' of a traditional website, requiring additional effort to implement all the expected web behaviors. Additionally, degraded performance was likely compared to a dedicated web framework, especially without specific optimizations.

Finally, we implicitly decided on the degree of code reuse from the existing Flutter codebase. In hindsight, we aimed to reuse core business logic—such as authentication, RPCs, and protos—while keeping 'web-only' elements separate from the mobile app to minimize the risk of regression. To illustrate, for a particular feature page - say Social Security Number Entry: 1) we used the same controller object controlling business logic built for mobile also to, which continued to invoke the same backend call, but 2) in the Flutter Widget, we forked the top-level "build" method into one for mobile, which held the existing layout, and added a new case for the "web" layout based on Flutter's kIsWeb indicator. This new case used a different design which made use of the increased screen size.

How did it go?

The project was completed on time according to estimates, successfully delivering the core value proposition of having a web application that continues to provide value to members.

We shipped quickly, largely due to most of the front-end team joining the effort. Our initial milestone, which we nicknamed Web-Lite, focused on shipping only a few core flows like onboarding and funding - directing users to install the mobile app for other use cases. It went into production about a month after starting the project. “Web-Next” followed this, which took another 1.5 months, after which most of Arta's functionality was made available on the web. Today, the web app matches the mobile app’s capabilities and offers a broader feature set, with new developments often being rolled out on the web first.

Data shows the web app has become a significant part of Arta’s offering for some members. It accounts for about a quarter of homepage views, a third of unique users, and most onboarding completions. Anecdotally, our member success team has noted that users appreciate having the option to access Arta via the web, and the web presence has also greatly helped the go-to-market team integrate more effectively.

The frontend team has adapted well to switching between Flutter web and mobile development. There’s minimal difference in the language or framework when working on either platform and ramp-up time for platform-specific tasks—such as running emulators or retrieving logs—is minimal. Even though new feature development is often web-first, most team members can extend features to mobile when needed, even in more complex scenarios like custom micro-index creation (similar to creating your own ETF).

What challenges did the team experience?

Flutter Web presented some challenges that we anticipated. For instance, delivering a best-in-class web experience while using Flutter Web requires continuous effort to optimize performance—rendering times and memory usage—and recreate fundamental web behaviors like URLs, embeds, accessibility, search (Ctrl+F), and browser navigation.

To take URLs and browser navigation (e.g back and forward button) as an example - these paradigms are not present in the same way on mobile applications. Our mobile application used Flutter's Navigator with named routes, such that named pages were pushed and popped as the user interacted with the app. However, most navigation was within a nested navigator in the app and not the top-level navigator, so in the initial web application that we deployed internally always remained at https://app.artafinance.com/ irrespective of user’s actions within the applications. This meant that functions like browser refresh and bookmarking would not work, and the browser back would always result in leaving the application. We patched this issue by using Flutter's Navigator 2.0 API to build translation layers to both report the app's navigation state as a URL and convert a new URL into a navigation state, while not breaking all the existing code that relied on pushing named routes.

How did the team decide to separate web and mobile layout code, and what lessons were learned from that approach?

Two key factors guided our decision to separate web and app layout code.

First, we prioritized the stability of existing mobile app flows, which were already in use by internal users and early members. Meanwhile, the web project’s requirements were still evolving, with frequent updates. Second, the web feature set was initially more limited, and the engineers working on it didn’t have full visibility into the mobile code, so we chose to avoid introducing unnecessary complexity early on.

This approach allowed us to move quickly and adapt to shifting requirements in the short term. However, over time, we realized that a more unified design from the start would have streamlined our efforts more effectively.

The key takeaway is that the real design challenge isn’t just addressing new requirements but seamlessly integrating them into the existing system. By considering new requirements within the broader context, our development efforts scale more efficiently and help avoid future integration hurdles.

Had we initially designed for responsiveness across mobile and desktop, the effort would have been similar to creating separate forks for web and app. Still, we would have gained greater flexibility to support multiple devices. We’ve now achieved this flexibility with ResponsiveData.isTight. It's a valuable reminder of the importance of a holistic design approach from the outset.

Our initial approach created independent layout code for desktop and mobile. This helped us make sure all the work we were doing for desktop did not affect the existing mobile layout which was actively being used. However, this approach had two main drawbacks. By separating at this level, we duplicated a lot of elements and components that were present in both settings, just at different positions or rendered differently. And by having logic based on kIsWeb and focusing on "mobile" and "desktop", we did not support more diverse screen sizes, and form factors like tablets.

A holistic design from the outset would have been to make each page layout and each of it's components responsive to the available screen size instead of having independent "app" and "web" pages.

How do you balance the need for speed in engineering with the need for thoughtful, long-term design?

Good engineering requires distinguishing between what’s fundamental and what’s incidental in a project’s scope. This distinction helps identify which elements should be fixed in the design and which can remain flexible to adapt as the project evolves.

The best designs recognize true constraints while leaving room for adjustment where necessary. For example, organizational boundaries or MVP scope limitations aren’t fixed constraints and shouldn’t be rigidly built into the design. In contrast, fundamental constraints, such as security requirements, framework limitations (e.g., what’s supported or not in Flutter), and scaling considerations, need to be addressed from the outset.

This approach isn’t about overengineering but about thoughtful, future-focused design. The goal is to create solutions that integrate smoothly with current systems and remain extensible as needs grow. While time spent on design may sometimes feel like an upfront "tax" with no immediate user-facing value, the long-term benefits are invaluable. The importance of good design cannot be overstated.

How do you approach engineering decisions at Arta to ensure that the systems you build can evolve and scale effectively over time?

In engineering, delivering a product that meets requirements on time and with decent quality is often seen as a success. But to build a technology company that endures, we need to go even further. Engineering should focus not just on solving today’s problems, but on creating a living software system that can evolve and continuously deliver value.

Good software design anticipates future needs. While we don’t need to build out every future feature, we should make sure today’s design decisions make future development easier. Ideally, the time and effort needed to add new features should decrease as the system grows, allowing the business to scale without exponentially increasing engineering resources.