A web app that users kept asking to turn into an app
Rosebud is a therapist-backed journaling app that pairs AI with evidence-based journaling techniques. For its first year, Rosebud ran as a React progressive web app, and it worked well enough that customers had journaled over 100 million words. But the number one request from those customers was a native app.
By February 2024, that request had turned into an existential question. Rosebud had less than 12 months of runway left, and its team had to decide whether to keep investing in the web product or redirect its remaining resources into a native mobile build. Chrys Bader, Rosebud's co-founder and CEO, has written that the company was feeling the limits of being web-only: no app store presence, no push notifications for re-engagement, and prospective users saying they'd use the product if it were an app.
The real constraint: no budget for a second team
The technology decision wasn't just about frameworks. It was about headcount. Traditional native development meant either hiring separate iOS and Android specialists, which would have doubled Rosebud's engineering costs, or asking its existing web developers to learn two new platforms while the runway kept shrinking. Neither option fit a startup with less than a year of cash left.
Rosebud's team, already fluent in React and TypeScript, needed a path that let them ship to both iOS and Android without becoming platform specialists first.
Weighing React Native and Expo against Flutter, native iOS, and Capacitor
Rosebud built a formal evaluation framework and scored four options: React Native with Expo, Flutter, native iOS, and Capacitor. The criteria included team experience with the language and platform, code reusability, ecosystem maturity, native-like experience, scalability, and time to market.
On team experience, React Native with Expo won because it let Rosebud build on skills the team already had. Flutter would have meant learning Dart, and native iOS would have meant learning Swift. Expo let the team focus on learning one new framework rather than a new language.
On code reusability, Expo let Rosebud share hooks, utilities, types, and business logic between its existing web codebase and the new native app, instead of rewriting large portions of the product from scratch. Flutter would have required a Dart rewrite, and native iOS would have limited what could be reused at all.
Before committing, Rosebud validated the approach with proof-of-concept builds for its most demanding features: voice recording, streaming audio playback, and navigation. Expo Router handled the navigation piece well enough that the team called it out specifically as it confirmed the app could hit the native-quality bar Rosebud wanted.
What shipped, and how long it took
Rosebud released its first native beta two months after starting the project and launched publicly five months in. The team has said this came in close to 30% faster than the timeline they'd projected for a traditional native build with separate iOS and Android workstreams.
A team of three engineers built the full app, including voice recording, AI-powered insights, and animation work, in that five-month window, and the same three-person team went on to maintain both the web and native platforms afterward, sharing about 70% of business logic between them.
Rosebud has also reported 100% engineering retention since going native, which the team attributes to not having to split people across separate iOS, Android, and web codebases.
The takeaway for teams evaluating the same tradeoff
Rosebud's decision framework is a useful reference for any team weighing native technology choices under a real deadline: score your options against what your team already knows, how much of your existing codebase you can carry over, and how quickly you can validate the riskiest features before committing. For a small team with a React codebase and no room to hire specialists, that scoring exercise pointed to Expo, and the timeline held.
Sources
How Rosebud decided to go native with Expo (2025-08-06)
Expo is more than a dev framework, it's a business strategy (2025-10-23)
