Super app evolution: Building a platform-based ecosystem for holistic user experience
Since many of our teams at Flo transformed into platforms, I decided to share the history of this journey from the beginning to the current state.
I will stress key milestones, show how they were connected to the business strategy, and explain how a combination of planned and organic changes led to the platform ecosystem.
Stage 0: Market fit
Necessary minimum before platforms
Let's start from the foundation for any platform investment: market fit.
At that time, we operated as a single, flat team consisting of mobile engineers, content specialists, and medical advisors, working directly with the chief product officer
We developed the application to track periods and view future cycles, sending daily notifications to users about the symptoms they could experience.
Our primary goal was to survive and only then scale. It was a crucial step before investing in platforms.
Stage 1: Super app strategy
Planned change
After the market fit, Flo became a habit product, as it is based on a woman's natural cycle.
However, monetizing the tracker function was challenging because we had a lot of competitors. We needed to provide additional value on top of the core experience to scale monetization. That's why we chose the super app strategy, which involved developing multiple domains simultaneously, bringing added value, and monetizing them.
This approach required extensive experimentation to identify the most valuable features for our users. Still, we faced complexities due to sensitive data restrictions and the inability to use third-party tools.
To address business strategy, we adapted the engineering strategy:
- Hiring DevOps(MobileOps, MLOps)-minded engineers to accelerate independent domain development
- Inner sourcing as the primary interaction model for shared components and tools across teams
- Backend-driven user interface (UI) and data mesh to accelerate experimentation
To reinforce our strategy, we established the first platform teams:
- Data platform — to support the "data as a product" concept and in-house experiment service development
- Velocity — to accelerate the path to production by continuous integration and continuous delivery, infrastructure as code, and cloud adoption
Essential aspects of these two teams were deciding what to buy and build, selecting the right vendors, and managing relations with them.
Stage 2: Growth of platform teams
Organic change
While our business strategy drove the previous stage, the next evolved organically.
Instead of waiting for direct business requests, we focused on the triggers of team evolution described in the Team Topologies:
- The software has grown too large for one team
- Delivery cadence is becoming slower
- Multiple business services rely on a large set of underlying services
During that time, we experienced the emergence of complex subsystems as part of our business solutions. Then, they scaled up and transformed into platforms.
Let's look at the Feed team, which provided personalized insights based on user body signals and behaviors.
This team developed the user profile service to address specific content personalization needs. Over time, this service became central to personalization in general. Eventually, it evolved into the foundation platform, which aimed to cover all company needs and provide personalization as a service.
The same was with the content development. In the beginning, the team solved its local problems. As the number of different types of content grew and went beyond one team, we formed a platform to serve various teams' needs and optimize their experience.
It was essential for us to create platforms, not to solve particular problems of specific teams. The best way to achieve this was to follow the mesh principles as a rule:
- Domain-oriented decentralized ownership
- Platform as a product
- Self-serve infrastructure
- Technical governance
Stage 3: Holistic user experience
Planned change
While platforms helped scale developer efficiency, we faced a new challenge:
Teams became too independent from a product perspective
Let's take, for example, Secret Chats, which allowed users to discuss intimate topics and seek support from the Flo community.
This feature became so detached within Flo that some users downloaded the app only for Secret Chats, while others never used the community feature at all. This was not ideal, as we wanted to reinforce the synergy between different parts of the app to serve our users' needs better.
We restructured several teams and departments to address this issue, merging them into a single stream that supported a holistic user journey. Then, we created dedicated teams for our main application modes: Track, Trying to Conceive, and Pregnancy.
These teams focused on personalization and smooth transitions between different app parts based on user goals.
We also embedded content specialists and medical advisers into some engineering teams to enhance collaboration, similar to the market fit stage.
The philosophy of platform teams also evolved. It became crucial for platforms to focus on clients and enable them properly. Our platforms shifted their attention from introducing new capabilities to adoption.
One example of this shift was the strategy of data quality. With an increasing amount of data in our system (more than a billion events a day), the data platform worked to eliminate misunderstandings around data quality and provide guidance for domain teams.
Stage 4: Transformation of domain teams
Organic change
The previous stage impacted some domain teams with channel capabilities. We refer to channels as the parts of the app where users consume multiple content items of the same type.
For example, the Feed team mentioned earlier had stories and content library channels. By creating systems for content release and personalization, we enabled platform-level management.
Other domain teams underwent similar transformations: the Virtual assistant team with fully customizable chatbots, the Communication team with mobile pushes, etc.
Over time, personalization extended beyond content. We introduced widgets to navigate users across the app and take action (for example, to log symptoms) in channels.
As the complexity of widgets grew due to their representation of complex domains with their backend logic, we introduced abstractions based on service level objectives (SLO), ensuring channel resilience to domain-related issues.
The interaction model with these teams also changed when the number of supported modes increased, essentially transforming these teams into platforms.
In a nutshell, we went through the classic steps of the team's evolution into a platform:
- Embedding subject matter experts into teams and building platform capabilities through continuous improvements
- Introducing self-service for everyday use cases and providing facilitation for unique ones
- Developing platforms with API and interaction models based on SLO to ensure resilience
The important fact is that channel teams continue to measure success using business-related metrics, such as user engagement, instead of typical platform metrics, like other teams' adoption. It helps not to be just a component library but solves the discovery challenge, experimenting with new forms of interaction and optimal placements.
Stage 5: Super app ecosystem
Current stage
What about the current stage?
Today, we have delivery platform teams in a more traditional sense: infrastructure, data, content, experiments, and machine learning.
Additionally, we have teams that form our ecosystem of channels, such as chatbots, stories, feeds, pushes, emails, and onboarding.
All platforms complement each other and comprise more than half of our engineering force.
Finally, we formed a high-level development strategy based on the different goals of different teams:
- We build modes by platform capabilities and feature orchestration
- Domain teams cover specific needs and interact with our users through widgets
- Channels link domains and modes, helping users discover different application parts
Takeaways
We went throw several stages of growth, each driven by a mix of planned and organic changes:
- Initially, the focus was on market fit without platform investments.
- Then super app strategy led to forming of teams working on various domains. First platform teams supported independent development and experimentation.
- The subsequent growth of platform teams happened organically, from domain-specific solutions to platform capabilities.
- A planned change to create a holistic user journey resulted in the reorganization.
- Domain teams with many internal clients became platforms on top of other platforms.
Finally, the platform ecosystem emerged, where various teams are working together to build a comprehensive application
Sometimes, the evolution was reflected in organizational structure changes, and sometimes not. But it is always better to organize departments around the shared purpose because it maximizes the potential of several teams.
In conclusion, I hope you found our insights and experience valuable as you navigate your own platform development journey.
I want to say a big thanks to my partner in crime — @esergueev— who helped me a lot with this article! Now it’s your turn!
More about Flo Health and Careers
