This June, Bravado launched its first app on iOS after only six weeks of development. The app has since been a key driver of user engagement and satisfaction. Behind the speedy and successful launch is a process propelled by a clear purpose, exemplary leadership, and close collaboration.
Solving User Problems
Building a mobile app was originally on the Q4 2021 roadmap, but the urgency to accelerate the timeline increased after the Bravado War Room gained traction. As the only online community for sales, the War Room provides a platform for salespeople around the world to share, network, and uplevel their careers. It quickly became a popular destination for sales professionals after it debuted in February.
As we observed more and more users engage with the War Room, interviewed them about their experiences, and conducted metrics analyses, we noticed several user problems:
- Lack of real-time, non-email notifications: Our users were only notified via email when others interacted with their posts or comments. If they didn’t check their inbox frequently or thoroughly, they’d easily miss these notifications or the window to respond in a timely manner. This as a result obstructed real-time conversation flows in the War Room.
- Limited accessibility: Our users are accustomed to having their social networks readily accessible on their mobile devices, especially when they’re not at a desktop (about 60% of the day). The limited accessibility to Bravado made it difficult for the War Room to become a habitual destination for our users.
- Less appealing mobile UX: Creating and interacting with content on the web mobile interface is more cumbersome without the ease of navigation the app provides. This was demonstrated by the fact that our users’ mobile session durations were on average 50% shorter than the desktop ones.
To promptly solve these user problems and move the needle on our engagement metrics, we moved the task to build a mobile app up the roadmap to Q2.
Developing the MVP App
Team Objective
Lisa, Bravado’s VP of Product, and Anton, our VP of Engineering, assembled a lean team for this project. We first aligned on our team objective — to build an MVP and migrate our user base as soon as possible.
We decided to build the MVP on iOS first considering the majority of our users use the iOS operating system. Then we nailed down the MVP scope to incorporate solutions to the most urgent user problems (e.g., real-time push notifications, upload photos/videos from camera roll) and essential War Room features (e.g., sign in/up, create and engage with War Room posts).
Technology Stack: React Native
The development team evaluated various front-end and back-end technologies to pick the optimal technology stack.
We debated about which mobile application development framework to use. Anton suggested Apache Cordova, which enables developers to wrap the web application into a native container. We estimated this solution could be implemented in just two weeks and was the cheapest solution of all the options, but its non-native nature presented a risk of rejection by the App Store and technological limitations. On the other end of the spectrum, our Lead Designer, Alex, suggested we go full native with Apple’s Swift. While it’d solve the issue with Cordova, we did not have native iOS developers on the team and hiring/training would extend the timeline.
After consulting iOS developers in our network and weighing the tradeoffs, we eventually decided to create our app with React Native, the framework that combines native development capabilities with the React framework. React Native appeared to be the best fit for Bravado because of:
- Cross-platform development: As a startup, we didn’t have abundant resources to assemble separate teams for different platforms (i.e., web, iOS, and later Android). React Native, however, enabled us to build versions of components specific to each platform so a single codebase can share code between web and iOS. This significantly streamlined our development and release process.
- Easy developer adoption: Since React Native is written in Javascript, a popular programming language, it didn’t require much effort to onboard our existing JavaScript developers to the mobile app team. We’d also be able to hire new mobile developers relatively easily.
- Rich ecosystem: The Facebook-created framework is widely used by developers around the world. The extensive communal resources and network provided support for our developers throughout the development process.
- Potential switch to Native: We learned that if we wanted to switch to Native Apps eventually, we could still start with React Native and then move pages and even UI elements to Native without rewriting the whole app. This gave us flexibility in making future decisions.
Technology Stack: GraphQL
Additional problems with the cross-platform development remained to be solved. At the time, we were dependent on REST APIs, which allowed us to fetch data by accessing multiple endpoints for platforms. However, due to the distinct UX on the web vs. iOS, the platforms required separate endpoints for support. One rule change in one platform required us to apply changes in both, resulting in messy complications including over- and under-fetching issues.
The only way for a client to download data with REST is by calling endpoints that return fixed data structures. REST APIs lack the flexibility to return one’s exact data needs. As a result, we often would download more information than required in the app; or we would need to make additional requests when a specific endpoint didn’t provide all that was required. The performance issues, called over-fetching and under-fetching respectively, slowed down our development process and consumed a lot of data points.
To tackle the issues with REST APIs, our Tech Lead, Felipe, introduced GraphQL as an alternative. GraphQL, a query language for APIs, lets the client specify exactly what data it needs in a single request, makes it easier to aggregate data from multiple sources, and uses a type system to describe data.
Below is a comparison between how to fetch data from this War Room web page with REST and GraphQL.
We need to make five requests with REST, like the following:
Some may argue we could create a single endpoint that returns everything, but this approach has serious downsides. First, we’d need to support and evolve at least one endpoint for each platform. Second, as we launch new app versions with UI/UX changes, we’d need to keep supporting older versions. To support all versions, we’d need to either create separate endpoints for different versions or keep unused data in the endpoint to prevent any versions from crashing.
The versionless and flexible nature of GraphQL enables us to handle this issue easily. Plus, only a single request is needed to fetch data with GraphQL like the following:
Despite the short-term effort to implement GraphQL on a tight schedule, the team discussed the tradeoffs and decided to take on the task to reap the long-term benefits of organizing our endpoints between multiple platforms. For efficiency, we decided to migrate to GraphQL on-demand and concurrently with the development of the same feature.
Fortunately, the implementation of GraphQL did not end up affecting our development schedule! It not only made up for the implementation time spent with the improved process but also served as a motivation boost for the developers with its hot technology appeal and pleasant developer experience.
Development Process
Besides the productivity boost spurred by new technologies, the successful development process is attributed to the team’s remarkable leadership and collaboration.
Following the Scrum framework, the team held daily stand-ups and weekly sprint and retrospective meetings. Echoing Bravado’s core value, “purpose before action”, Felipe along with the rest of team leadership made sure all team members understood the (potential) impact of their work on our users and the business. Our team’s lean nature allowed everyone to participate in decision-making, from choosing the technology stack to backlog grooming. With the introduction of GraphQL and new platforms, we created a collaborative learning culture where developers helped each other adopt new technologies and solve tasks outside of their areas of expertise. Involving the team and infusing a clear purpose in the process contributed to quick team alignment and high team morale throughout the process.
It was not all smooth sailing. To abide by the App Store guidelines and increase our chance of getting approval with the first submission, we had to revise our MVP scope to include features such as Apple sign-in and user reporting and budget additional testing time for a bug-free submission. The team made quick decisions to cope with these challenges and meet the fast-approaching deadline. When making trade-off decisions, we prioritized features with direct impact on our key metric, existing user engagement, over features that’d improve user growth or activation, such as onboarding; we generally prioritized core features that affect UX over UI gestures that optimize the flow; we postponed some integrations, such as A/B testing tools, considering the limited initial user base of the app.
MVP Launch and Post-Launch
The iOS App 1.0 was submitted on June 10th and approved by the App Store later that day.
On June 16th, Bravado hosted a launch party with our top users, where the announcement of our first mobile app was well-received!
Since the launch, more than 30% of our user base has downloaded the app. We learned that the app continues to resurrect churned users and drive existing user retention. As you can see in our user retention chart below, iOS users have a 48% retention rate vs. 20% for web users on day 1. The retention rate and the iOS advantage remain stable in the next 30 days.
We have triaged the remaining backlog items to all feature teams, and the mobile app team has returned to our respective feature teams to build new features for the mobile app and make improvements based on user feedback. The v1.8 was just released — you can check it out here. Feedback welcome!
Bravado is hiring! To view and apply to open roles, visit our Careers page.
