Early in 2022, Sparkbox was approached by a multibillion-dollar tire manufacturer to develop a mobile app to work with their proprietary tire sensor technology. The sensors send real-time data on conditions such as tire pressure, leak status, and vehicle location to allow users to assess the health of their tires and whether their vehicle is safe to drive. They wanted something that would add value for their customers working with the technology in the field and wanted to get an initial version of the app into users’ hands fairly quickly so they could prove its worth before rolling it out to a larger audience.
While the app would initially be released in the US market (where their customers primarily used iOS devices) they knew that they eventually wanted to take their idea to the European market where Android has the most market share.
With their quick time to market, and a need to support both major mobile platforms, the client’s initial reaction was to use a low-code solution they thought might get them to MVP quickly. However, after looking at the complexity of the idea that was presented to us, we weren’t convinced that a low-code solution would be able to support all of the advanced features they were looking to implement or serve them well in the future.
We, instead, proposed slowing down to investigate other possible solutions. This, we explained, would allow us to move more quickly once we started and would allow us to be able to better support future needs.
The extra time we spent at the beginning of the project was a great investment for the team, the client, and the future of the app.
We knew that our client had a long-term vision for their technology and expected to develop additional apps over the next few years. We wanted to make sure that we were taking their future needs into account when choosing a technology. These are a few of the points we considered when making that decision.
Just Because a New Technology Sounds Good, Doesn’t Mean It Is
During our initial discussions, the client expressed an interest in using the low-code solution provided by OutSystems to develop the app. One of the main reasons for their interest was a touted feature: the ability to download a template and make changes to the app using Figma. Their understanding was that this solution would allow them to get to market quickly.
The Sparkbox team was immediately skeptical of OutSystems’s ability to deliver what that client was looking for. No one on our team had used it (or even heard of it), so we didn’t have the experience to say whether or not it would work. We did know that the client was going to need some relatively advanced and specialized access to their users’ device sensors down the road and we weren’t confident that OutSystems could fully support the features we needed. We ultimately ran a series of investigations and decided that using OutSystems posed too much of a risk to the future of the app.
It can be tempting to jump into a technology solution because it meets an immediate need, especially if there are time constraints. However, not taking the time to assess your options upfront can lead to a lot of rewriting and failed projects down the road.
Years ago, on another project at another agency, I saw how jumping on the “latest and greatest” tech bandwagon could backfire. A client had come to my then-agency with a rather large, multi-year software project that they insisted on being developed in Aurelia—an emerging product they were convinced was the next great JavaScript framework. Even though the agency wasn’t sold on Aurelia being the correct framework to use, they were unable to sway the client and moved forward with the project. They built the requested software in the requested framework and learned as they went.
That approach, as you can imagine, eventually posed problems for both the client and the agency. The agency was one of the few places that developed in Aurelia, limiting the client’s options to hire another agency or developers if needed. This would put the client in a real bind—as the popularity of the app dwindled, they were now locked in with few options other than to have the project rewritten in another framework.
The Aurelia decision also became an issue within the agency itself. While using the new framework technically gave the agency security with the client, (now being one of the very few places that worked with the framework), they ran into issues with staffing. Since the framework was relatively obscure, many developers on the team were hesitant to work on the project because they felt they weren’t gaining knowledge that would help them grow their careers. The agency also had to contend with the task of attracting new developers who either already had knowledge of the framework or who were willing to learn.
These were all concerns that we had in mind when considering our options with our recent engagement.
Don’t Let Today’s Needs Get in the Way of Future Growth
With OutSystems ruled out, we turned our attention to other solutions. We knew that the client was still driven by a need to get the MVP to market quickly while being able to support both Android and iOS devices.
Creating an iOS and an Android app, separately, in their native languages (Swift and Java respectively), would mean the app would need to be written twice and would result in two codebases to maintain. The client had neither the time nor the budget to take that approach, so we were now looking for a solution that would allow us to support both platforms with one codebase.
Three main contenders emerged in our research which would meet the client’s need to release to both Android and iOS using just one codebase. The first two, Flutter and React Native, are both open source frameworks that allow developers to write in one code base and then render native code for release to both major mobile platforms. The third option would be to build a Progressive Web App (PWA), which allows developers to create an installable web application.
Each one had its strengths and limitations and we wanted to investigate them thoroughly before proceeding.
Consider Your Team’s Skillsets
We wanted to bring the product to market as quickly as possible (a must for the client), but we also wanted to leave the door open to expand the team in the future. While we planned on a long-term partnership with the client, we also didn’t want to lock them into something that would make it hard for them to move on if, for any reason, we needed to part ways in the future. This left us with two major considerations when evaluating the three technologies:
What existing knowledge did the Sparkbox team and the client team have to contribute to the project?
How easy would it be to onboard additional developers to the project as needed?
At Sparkbox we were already very familiar with React and Vue, and we had previously created PWAs using Vue. That made React Native or a PWA built with Vue appealing to our team. While we hadn’t worked specifically with React Native before, we were confident that our existing React knowledge would make it easy to learn.
Flutter, on the other hand, uses Dart. Dart is a frontend programming language similar to JavaScript, so we knew we could learn it, but the added ramp-up time was going to cut into the desire the client had to get an MVP to market fairly quickly. It would also make onboarding a new developer from our current pool a more lengthy process, as they would also need to become accustomed to a new language before contributing.
Choose Technologies That Are Well Supported Now, and Will Be in the Future
One of our concerns with using Flutter was that it is a relatively new technology compared to the other options. The first stable release of Flutter was in December 2018, making it a little over 3 years old at the time of our decision. By contrast, React Native had been in use since 2015, had already been tested, and was in use by many large companies developing widely used apps such as Instagram, Shopify, and Mercari.
We also knew that our client had some specialized needs for this app in terms of device sensor usage, so knowing what libraries were available was also important. At the time of our decision, React Native had over 45,000 libraries available—Flutter had 14,000. Most importantly, Flutter was missing support for a very specific software development kit (SDK) that we suspected we were going to need in the near future. While the number of apps using Flutter and the number of libraries built for it is growing, React Native felt more established.
Take Multiple Options Through Proof of Concept
Having narrowed our choices to React Native or a PWA, we had to do one more thing before we could make our decision. Since React Native was a new technology for us, we wanted to verify our assumption that our transition from working in React to React Native would be smooth. React Native is a cross-platform mobile framework that uses React for building apps and websites. While the two share design philosophies, such as component-based architecture and reusable components, React Native also involves working with platform APIs, some native UI elements, and platform-specific design patterns.
We also identified a few key features that our client wanted—primarily access to certain device sensors—and decided to test those out with a quick proof of concept written in each technology.
The two prototypes were written simultaneously by two different developers, who then compared notes. We were able to successfully verify that React Native would be easy to pick up for any developer familiar with React. We also found that an app written in React Native gave us more reliable access to the device’s camera and sensors than a PWA would.
These two prototypes took minimal time to build and gave us the confidence we needed to recommend React Native to our client. In addition, our research and POCs gave us the proof we needed to back up that choice.
Let a Consultant Mindset Help You Lead Your Client to Success
The client approached us with an interesting project, but also came to us with a solution that wasn’t likely to serve them well in the future. With a consultant mindset, we were able to recommend a more suitable solution that still met their goal of getting a product to their users quickly while ensuring that the project was set up for future success. Now, several months into our engagement with the client, we are getting ready for our second release of the original app, working with them on the design of a second app, and looking forward to a productive long-term engagement with a very satisfied client.
