How Rosebud decided to go native with Expo

Users15 minutes read

Chrys Bader

Chrys Bader

Guest Author

Ever wondered what would happen if you prioritized native instead of the web? Rosebud started with web then switched to native and the results are compelling.

How Rosebud decided to go native with Expo

This guest post is from Chrys Bader, co-founder and CEO of Rosebud, where he leads product and engineering. Chrys has been a builder since the age of 13, has a passion for craftsmanship, and aspires to master a broad set of tools and skills.


Update on August 6, 2025 (it was originally published on 8/26/24):

One year after launching our native app, Rosebud has reached 10,000 paying customers who have collectively journaled over 700 million words. This milestone is directly attributed to our successful native app launch, which since enabled us to raise $6M in funding and scale both our team and product.

...

Rosebud is a therapist-backed interactive journal designed to create positive change in your life. We do that by incorporating AI with proven journaling techniques and evidence-based modalities.

After developing Rosebud as a React progressive web app over the past 12 months and seeing moderate success with over 100 million words journaled, a native app was the number one request from our customers.

In February 2024, with less than 12 months of runway left, we were faced with a choice: either double down on our web-first strategy or pivot our resources towards building a native mobile experience.

Web headwinds

The idea of going native first emerged in fall 2023, but we initially brushed it aside, focusing on refining our core feature set — there was still more nurturing to do. As 2024 began and our runway continued to shrink, we revisited the idea. However, concerns about unknown risks and diverting focus from product development still held us back.

Come February, with the clock ticking, we kept feeling the headwinds of being web-based:

  1. Lack of natural distribution points like an app store
  2. Potential users saying, "I'd use this if it was an app"
  3. Tougher re-engagement without push notifications

We realized we might be missing out on significant potential customers already searching for us in the App Store, customers we needed to survive as a business.

The turning point

The pivotal moment came in March during a spirited Zoom call with my co-founder Sean and our advisor Max Hellerstein, CEO of Extra. Frustrated by our inability to fully express our product vision within a web app and feeling the pressure of dwindling runway, I vented my concerns. His words pierced through: "Chrys, it’s clear you want to bet the company on this."

His words stuck with me and served as the wake-up call we needed. After much deliberation, we decided to bet the company on a native app. It was a high-risk, high-reward gamble, but one grounded in data and instinct.

With apps dominating 88% of mobile time and converting 157% better than websites, our bet was that native would boost organic distribution, improve retention and revenue, and deliver a higher quality experience, overcoming web's technical limitations.

That brought us to another complex question: which mobile technology should we use?

With the stakes this high, we needed a structured approach to help us make the most informed decision. So, we devised a comprehensive framework to evaluate our options.

Our decision-making process

Our objective was clear: build a flagship native mobile version of Rosebud that distills the best aspects of our product into a coherent, simple, and high-quality experience. To achieve this, we needed to choose a technology that would empower us to build a quality product while also getting to market as quickly as possible.

To guide our decision, we chose a set of criteria that were most important to our business and the success of the project:

Assessment criteria:

  • Team experience with language & platform
  • Code reusability
  • Ecosystem maturity
  • Native-like experience
  • Scalability and future-proofing
  • Time to market

The contenders:

  • React Native & Expo
  • Flutter
  • Native iOS
  • Capacitor

1. Team experience with language & platform

Why it matters: The team's experience with a programming language directly impacts development speed, efficiency, and code quality. Familiarity reduces learning curves, accelerates problem-solving, and enables leveraging best practices effectively

With Rosebud's web version built in React & TypeScript, our team was already in top form in these technologies. Choosing React Native & Expo allowed us to focus on implementing a new framework rather than learning a new language. While Capacitor offered similar familiarity, React Native struck a better balance between familiarity and native functionality. Unlike Flutter (Dart) or native iOS (Swift), React Native built on our existing skills while providing robust native performance, allowing us to focus on mobile-specific challenges more effectively.

By building on our strengths, we narrowed our learning curve to only learning Expo, which ended up being pretty straightforward, easy to grasp, and eventually a force multiplier.

2. Code reusability

Why it matters: Leveraging an existing codebase for mobile development reduces time to market and costs. It ensures consistency across platforms, minimizes duplicate effort, and simplifies maintenance.

For Rosebud, this was crucial. We had invested significantly in our web app's logic and components. The ability to carry over much of this work made Expo incredibly appealing, both for resource efficiency and consistency.

React Native (with Expo) stood out for its high code shareability with our web codebase. Unlike Flutter (requiring a Dart rewrite) or native iOS (limiting reuse), React Native allowed us to share hooks, utilities, types, and business logic. While Capacitor promised even more direct integration, Expo offered a better balance between code reuse and native app performance. It let us leverage our React and TypeScript code while providing robust native APIs and mobile-specific optimizations.

By choosing Expo, we accelerated development, maintained cross-platform consistency, and focused on optimizing the mobile experience rather than rewriting large portions of our codebase. This approach allowed us to bring Rosebud's core functionality to mobile platforms efficiently, ensuring a coherent user experience across web and mobile.

3. Ecosystem maturity

Why it matters: A mature ecosystem offers extensive libraries, tools, documentation, and community support, speeding up development and problem-solving. It provides tested solutions, reliability, and resources for learning and growth.

When comparing options, React Native (and by extension, Expo) stood out for its mature ecosystem. While Flutter's ecosystem is robust and growing, it's relatively newer compared to React Native. Native iOS development offers a very mature ecosystem, but it's limited to Apple's platforms. Capacitor, being newer, has a growing-but-far-less-established ecosystem.

Expo's ecosystem has evolved significantly in recent years, offering a massive set of tools, libraries, and thorough documentation. It's compatible with native modules, making it an attractive option. Beyond the technology, React Native's mature ecosystem correlates with a larger talent pool, which is crucial for several reasons:

  • Easier recruitment of skilled developers
  • Competitive hiring rates due to market dynamics
  • Abundant resources like tutorials, forums, and open-source libraries

For us, this meant we could build with confidence, assured of our tech stack's sustainability and our ability to scale the team in the future. Expo's maturity allowed us to leverage existing solutions for common challenges, freeing us to innovate on Rosebud's core features and user experience, while still benefiting from the broader React Native ecosystem.

4. Native-like experience

Why it matters: An app's performance, look, and feel should align closely with user expectations on their device's operating system. High native-like quality leverages platform-specific features, animations, and UX patterns, making the app intuitive and more delightful for users.

We needed to know our chosen technology could support our vision for user experience. To validate this, I built several proof-of-concept (POC) implementations for our most critical features. This included voice recording, streaming audio playback, and navigation (where expo-router proved to be excellent). These POCs were crucial in confirming that we could achieve the level of native quality we were aiming for.

Expo impressed us with its ability to deliver a truly native feel while maintaining the benefits of cross-platform development. Its optimized components and APIs allowed us to create smooth, responsive experiences that feel natural on both iOS and Android.

We adopted a principle of working within the constraints of the platform rather than trying to force overly complex or fancy interactions. The discipline to stay within Expo’s well-designed boundaries allowed us to develop faster while maintaining an authentic native feel.

5. Scalability & future-proofing

Why it matters Choosing a new technology at this stage of the business needs to accommodate user growth and support future developments with a high quality. Whichever technology we choose should best support the roadmap and key differentiating features that will make Rosebud stand out.

Key considerations included:

  • How well would the technology support our ambitious roadmap?
  • Could it handle potential AI integrations we're considering for the future?
  • Would it allow us to rapidly iterate and add new features as we learn from our users?

We ultimately chose Expo because of its robust scalability and future-proofing capabilities:

  • React Native's architecture allows for easy integration of native modules, giving us the flexibility to add complex features as we grow.
  • Expo's managed workflow provides a solid foundation that can be modified without limitation, offering a clear path for scaling our app's capabilities.
  • The active development of both React Native and Expo means we're likely to see continued improvements and new features that will help us stay current.
  • React Native's component-based structure facilitates code reusability and maintainability, crucial for managing a growing codebase.
  • Expo's over-the-air updates allow us to quickly push new features and fixes, enabling rapid iteration as we scale.

This combination gives us confidence that we can invest into Expo long-term and increase the complexity and sophistication of Rosebud without worrying about limitations.

6. Time to market

After assessing all of the other points, it became clear that React Native with Expo offered us the fastest path to launching our native app. Here's why:

  • Our team's existing React expertise meant minimal learning curve.
  • Expo's pre-configured development environment saved us significant setup time.
  • The ability to reuse portions of our web codebase accelerated development.
  • Cross-platform capabilities allowed us to target both iOS and Android simultaneously.
  • The rich ecosystem provided ready-made solutions for common mobile app features.
  • Expo CLI's auto-submit feature streamlined the app store submission process.

This combination allowed us to hit the ground running, focusing on building Rosebud's unique features rather than wrestling with tooling or platform-specific intricacies. Expo's managed workflow, in particular, eliminated many of the initial hurdles in mobile development, allowing us to see results quickly.

While we recognized that the fastest option isn't always the best long-term solution, in this case, the speed-to-market aligned well with our other criteria. It gave us the ability to get our product into users' hands faster, start gathering feedback, and iterate quickly – all super important for a startup with limited time remaining.

The ROI of going native

All-in, it took us 2 months to release the first beta, and 5 months to launch publicly. At the time of writing, Rosebud Native shipped exactly two weeks ago and the early results suggest that our bet is paying off.

Product impact

  • D7 retention is 40% (almost 2X better than web app)
  • 11% of installs start a trial
  • Upgrade screen conversion is 20% (2X better than web)
  • 5% of users who sign up end up sharing the app with a friend

Business impact in first 14 days

  • $20K in revenue collected since launch (on Native only)
  • $6K MRR added (from Native alone)
  • Daily new trials has stabilized at 3X what it was before
  • Inbound investor & partnership interest

The ROI of OTA Updates

One of the most powerful things about Expo is the ability to push updates to your users without having to go through the App Store process. This has been essential in addressing production bugs without any hurdles. It feels like a superpower.

Reflections on the process

Looking back, I'm incredibly proud of the thorough decision-making process and evaluation that we undertook. Our comprehensive assessment of various technologies, careful consideration of our team's strengths, and strategic alignment with our business goals all contributed to making an informed choice.

This experience reinforces the value of a methodical approach to technology decisions, especially for startups where resources are limited and the stakes are high. By aligning our technology choice with our team's skills, our product's needs, and our business goals, we've set ourselves up for sustainable growth and success.


ota updates
expo upates
native modules
code reusability
time to market

Accelerate building apps with Expo and AI

Learn more