Mobile onboarding evolution at Flo Health - Engineering Strategy

Introducing myself

Hi, I’m Eugene, Director of Engineering at Flo Health. Today, I want to share how we evolved our onboarding experience from a rigid, release-bound flow into a dynamic, server-driven platform that now powers rapid experimentation across mobile and web. This is a story about breaking Conway’s Law, building internal platforms with product thinking, and enabling teams to move fast—without breaking things.

Introducing the company

Before diving deep into details, I want to give you an overview of Flo’s domain, scale, and challenges. This information can help you understand why our onboarding is so complex and diverse.

Flo is a super app with various user segments: cycle tracking, getting pregnant, pregnancy tracking, sex life, socializing in secret chats, and many more. Moreover, we recently launched a Flo for Partners feature with 1+ million MAU in 2024, meaning we are no longer only a female health app.

What was the high-stakes problem?

At Flo, onboarding isn't just a product feature - it’s a critical growth lever. As a product-led growth (PLG) company, our ability to convert new users into active, engaged members within their first few minutes in the app directly influences our retention, revenue, and impact.

Initially, we approached onboarding as a set of hardcoded screens - a simple solution that sufficed for a time. But as our ambitions grew, so did the complexity of our onboarding journeys and the urgency to iterate on them quickly. To scale experimentation, we introduced a domain-specific language (DSL) that allowed onboarding flows to be described more flexibly. However, this DSL was still embedded in the app codebase, locking every onboarding change to the mobile release cycle.

This created a high-stakes bottleneck.

• Every experiment or fix was gated by a mobile release, making it impossible to react in real time to user behavior or localization issues.

• Errors took days to detect and fix, delaying learnings and negatively impacting conversion metrics.

• The complex onboarding created a cognitive and operational burden on engineers, PMs, and QA to maintain.

• Mobile engineers were disengaged, spending time updating massive DSL configs instead of solving high-impact user problems.

In short, the very process designed to accelerate onboarding innovation became the blocker. And in a PLG company, slow onboarding iteration is not just a developer inconvenience - it’s a growth risk.

Engineering Strategy

As a business it was critical for Flo to grow onboarding revenue and incite higher engagement from our users. So to address the growing complexity, slow iteration cycles, and developer pain points in our onboarding system, we defined a strategy focused on decoupling onboarding logic from mobile releases and empowering product teams to move faster. Inspired by existing server-driven UI patterns used in multiple parts of the app, we began migrating onboarding flows to a server-driven model. This shift enables real-time updates, safer experimentation, and faster hypothesis validation - without waiting for a mobile release. As a second step, we introduced a visual editor, allowing non-technical stakeholders to create, manage, and test onboarding flows autonomously, further reducing engineering overhead and accelerating iteration.

Analysis

What Works Well in the Flow

1. Established DSL & Contracts
   We already have a robust domain-specific language and clear contracts for rendering key onboarding screens, providing a solid foundation for further abstraction.

2. Backend-driven UI
   Our Backend-Driven UI system is mature enough to describe screen layouts and deliver UI configs via the server, reducing the need for mobile releases.

3. Cross-Platform Consistency
   The DSL allows us to maintain consistent onboarding logic across iOS, Android, Web, reducing platform-specific divergence.

4. Experimentation Culture is Strong
   The product team is hungry for faster iteration and has a clear sense of the right hypotheses to test - demand for rapid change is high and well-structured.

What Blocks the Current Flow

1. Slow Mobile Release Cadence
   Mobile releases are on a two-week cycle, delaying onboarding experiments, fixes, and urgent updates (e.g., localization or attribution errors).

2. Error Feedback Loop is Too Long
   It often takes more than 24 hours to detect misconfigurations in experiments due to non-real-time analytics and delayed rollout visibility.

3. Engineering Time Spent on Config Work
   Mobile engineers are blocked doing low-leverage work like editing large onboarding JSON configs, which reduces team engagement and velocity.

4. Mobile-Only Team Structure (Conway’s Law)
   A team composed entirely of mobile engineers naturally gravitates toward mobile-driven solutions, limiting exploration of server-driven or cross-platform strategies.

5. Lack of Visual Flow Management
   Product managers and QA rely on Miro boards and ad hoc tools to track flow logic. There’s no unified source of truth or editor to visualize and modify onboarding journeys safely.

Direction

Things We Want to Do

1. Apply the Conway Maneuver: Add Backend Engineers
   To break out of mobile-centric thinking and enable backend-driven solutions, we expanded the team to include backend engineers. This shift allowed us to rethink onboarding as a distributed, server-powered capability—not just a mobile UI flow—and enabled quick validation of this new architectural approach.

2. Use Download-at-Once Strategy for Config Delivery
   Following the Lean methodology, we selected the simplest and fastest approach: downloading the entire onboarding JSON (up to 300KB gzipped) at app start. In the first iteration, our backend service was a lightweight wrapper serving configs directly from Git. As a fallback, we include an embedded version of the main onboarding flow (without experiments) in the app bundle during each mobile release. This setup balances speed, reliability, and offline coverage.

3. Launch via Controlled Experiments
   We introduced server-driven onboarding behind a feature flag, starting with Android EN users and gradually expanding exposure (5% → 100%). We defined success not as improvement but as no statistically significant negative change across key business and technical metrics—signaling a safe infrastructure shift.

4. Enable Safe, Validated Server Releases
   Our backend performs structural validation of onboarding flows before serving them to clients. It checks for graph consistency, unreachable nodes, duplicate transitions, and cycles. Invalid configurations are blocked from release, ensuring high confidence in every server-side deployment.

Things We Discarded or Don’t Want to Do

1. Introduce a New Team Prematurely
   We intentionally avoided creating a new team or scaling the org structure before validating the value of server-driven onboarding. Instead, we applied a lean approach—testing the hypothesis with minimal changes and leveraging existing team members to deliver the proof of concept.

2. Build a Visual UI or Complex Backend Logic Early
   For the initial phase, we decided against building a visual editor or adding complex backend authoring tools. It was acceptable that all onboarding configurations would be written by engineers using the existing DSL. This kept the scope tight and allowed us to move quickly while focusing on validating the core approach

Coherent Actions

After the successful proof of concept, it became clear that backend-driven onboarding was technically feasible and brought tangible business benefits—faster iteration cycles, more robust experimentation, and reduced engineering overhead on repetitive tasks.

Rather than treating onboarding as a standalone system, we chose to take a deeper, more strategic step: we established the Survey Engine as a dedicated platform team. Onboarding became just one of many internal customers of this platform. This shift allowed us to generalize the infrastructure and scale its impact across multiple user-facing surfaces like in-app quizzes, polls, and dynamic content.

Key coherent actions we took:

• Established Survey Engine as a Platform Team
  The team’s mission expanded beyond onboarding. It now owns core capabilities such as configuration delivery, runtime rendering contracts, and safe rollout mechanisms- serving multiple product teams across the org.

• Provided Visual Tooling for Configuration Management
  The team built internal tools enabling product managers and content teams to visually create and manage onboarding flows, significantly reducing the need for engineering involvement in day-to-day experiments.

• Integrated Existing Capabilities into a Unified System

  • CMS Integration: Enabled safe release and publishing of onboarding content.

  • Experiment Service Integration: Allowed dynamic branching and targeted delivery of flows through experimentation.

  • Localization via translation management system (TMS): Made all experiments fully translatable from Day 1, eliminating a common delay in onboarding launches.

• Introduced a New Role: Content Operations
  To streamline the workflow, we introduced a Content Operations role. This person acts as a bridge between product, design, and analytics - taking ownership of flow configuration, copy updates, and experiment setup.

• Redefined the Role of Engineers
  Engineers are now focused solely on developing new capabilities (e.g., new component types, data logic, validation rules), not maintaining onboarding flows. This shift both reduced cognitive load and increased engineering team engagement.

Together, these actions established onboarding as a high-leverage, product-led capability- no longer a bottleneck, but a dynamic and adaptable system aligned with Flo’s experimentation culture.

Outcomes, Learnings & Next Steps

The migration to the Survey Engine platform delivered clear, measurable impact:

• Significant Uplift in ARPU and Subscription Conversion
  The shift to rapid, low-cost experimentation drove substantial business impact: average revenue per user (ARPU) increased by 13.5%, and the conversion rate to subscription during onboarding rose by 20%. These are critical metrics for PLG companies, highlighting the direct connection between experimentation velocity and monetization outcomes.

• Experiment Velocity Increased by 170%
  After moving onboarding to Survey Engine, we now launch an average of ~30 experiments per month. This made onboarding one of the most iterative and data-informed parts of the user journey.

• 87% of Experiments Launch Without Engineering Involvement
  By enabling visual tooling and empowering product teams, 87% of onboarding experiments are now launched without engineers, dramatically reducing the cost of iteration and freeing up engineering focus for core platform work.

• Cultural Shift in Product Thinking
  Product managers increasingly validate hypotheses directly with real users rather than relying solely on upfront user research. While user research remains valuable, the lower cost of experimentation has shifted the balance toward more hands-on testing in real contexts.

• Survey Engine Gained Broad Adoption Across the Org
  Thinking globally from the start—and building a platform rather than an onboarding-specific solution—allowed us to onboard ~20 internal customers. Several teams have decommissioned legacy tools or stopped using third-party vendors, consolidating efforts around a shared, robust infrastructure.

• Unified Web and Mobile Onboarding Experience
  Completing the migration of web onboarding to Survey Engine enabled the merger of mobile and web onboarding teams. Product managers now focus not on individual platforms but on delivering a cohesive, cross-platform user journey.

Next Steps

• Integrate AI as a Copilot for Content Creation
  To further accelerate time from idea to release, we are embedding AI capabilities into Survey Engine as a creative and operational copilot. This includes assisting with content generation, validation, and layout suggestions—especially important in sensitive domains where medical and legal credibility are paramount.

• Speed Up Experiment Delivery with AI-Powered Workflows
  We’ve already seen early success: in a recent use case, researchers fully created and launched a survey using just a PRD and prompt within Survey Engine—no engineer and designers' involvement required. This demonstrated the potential for AI to radically simplify and speed up the path from concept to live experiment.

• Content Safe and Credible Automation
  As AI takes on more of the content lifecycle, we’ll implement guardrails for automated validation—checking for medical accuracy, localization quality, and compliance with internal and external standards.

Further Reading & Technical Deep Dives

This post focused on the strategic and organizational aspects of our onboarding evolution at Flo Health. For readers interested in the technical implementation details, architectural decisions, and deeper engineering insights, we've published a comprehensive series that covers the full journey:

• Mobile Onboarding Evolution - Part 1: The Technical Foundation Dive deep into the technical architecture that enabled our server-driven onboarding platform.

• Mobile Onboarding Evolution - Part 2: Migration & Scaling Explore the practical challenges of migrating from client-side to server-driven flows at scale.