← Blog · Migration · 7 min read · May 19, 2026
From Bubble.io to React Native in 4 days — an honest 2-year migration retrospective
Solo founder. Data Engineer by day. Sports prediction app called BeTeam (private leagues for friend groups — beteamapp.com) by night. Built it on Bubble.io for almost 2 years before migrating to React Native + NestJS + Postgres. The rebuild took 3-4 days of evenings. This is the honest breakdown of what I learned — written because I would have killed for a post like this 6 months ago.
The numbers, all annual
| Bubble period (per year) | Native period (now, per year) | |
|---|---|---|
| Platform / wrapper subscriptions | $350 Bubble + $300 Natively wrapper = $650/yr | $0/yr (no platform fee) |
| Infrastructure (API + server + DB) | Free tier — wasn't at paid scale yet | ~$180/yr |
| Claude subscription | n/a | $1,200/yr — shared across all my apps + my day job |
Real apples-to-apples: $650/yr in platform fees → $0/yr. The ~$180/yr infrastructure cost is a scale-driven line item that would have come due in either world — Bubble would have hit the same paid-tier threshold at the same user count. The migration didn't add infrastructure costs; growth did.
The Claude subscription is a productivity tool I use across every app I build and at my day job. It's not a BeTeam-specific cost — it'd exist with or without this project.
Why I was on Bubble in the first place
I started BeTeam on Bubble.io because I wanted to validate a product idea, not become a mobile developer. Bubble's pitch — "ship a real app without writing native code" — was exactly right for that goal. I went from concept to working app in a weekend.
For the first 6 months it was great. Bubble's visual workflow editor, database, plugins, and the Natively wrapper let me focus on the product instead of the stack. Active users in my friend groups gave me feedback. The product found its shape.
The breaking point — cognitive load, not features
I didn't quit Bubble because it couldn't do something. Bubble can do almost anything if you're willing to fight it. I quit because the friction was eating my evenings.
Every customization required wrestling the platform. Every edge case needed an awkward workaround. Every plugin I added expanded the surface area of "things that might break in a future Bubble update." Mobile UX polish — the stuff that turns a working app into a product people share — was disproportionately expensive on Bubble. I'd spend 2 hours getting a single animation to feel right when on native it would have been 10 minutes.
At the same time, I'd become a daily Claude user in my Data Engineering day job. I knew how to prompt it for production-quality code. I knew its architectural capabilities. I knew when to write code by hand vs. when to delegate. And I'd watched it close the gap between "no-code productivity" and "real-code productivity" to the point where the comparison had inverted.
The 4-day rebuild — what surprised me
Going in, I assumed the rebuild would take 4-6 weeks of evenings. I'd built BeTeam over almost 2 years on Bubble. Surely the native version would take months.
Reality: 3-4 days of evenings for a fully functional native version.
The stack:
- React Native + Expo for the mobile app
- NestJS + Postgres for the API
- Supabase for auth
- Render for the API hosting (free-tier-then-paid as needed)
- Claude as my pair-programmer for the entire migration
The coding wasn't the bottleneck. Claude shipped code fast when I knew how to prompt it. The architecture decisions were quick because I'd already lived with the product for 2 years and knew what mattered. Even the App Store submission process — which I'd dreaded — was smoother than the Bubble + Natively round trip had ever been.
The actual bottleneck was reconstructing 2 years of micro-features.
What was harder than expected
There's no clean "export your spec" button in Bubble. Two years of accreted product nuance — every tiny edge case, every UX choice I'd made in response to user feedback, every "oh wait, I also need to handle…" — live inside the Bubble editor as a tangle of workflows, conditions, and plugin glue.
To migrate, I had to enumerate all of it. Open every screen. Open every workflow. Take notes. Write the spec on paper that I should have written 18 months earlier. The actual rebuild went fast because I'd done the spec work; the spec work took most of the real time.
If you're considering a migration, this is your real cost. Not the code. Not the infrastructure. The act of remembering everything you built — and being honest about what's worth bringing forward.
What was easier than expected
The coding itself. Once I had the spec in plain English, Claude shipped the React Native components, the NestJS endpoints, the database migrations, and the auth flows fast. Code review took longer than code production.
Specifically, the patterns that worked:
- Feed Claude the spec one feature at a time, not the whole product at once.
- Be explicit about constraints (target platform, library choices, performance budget).
- Iterate on each feature until it works end-to-end before moving to the next.
- Trust Claude to write tests; verify them yourself.
- Use Claude to translate Bubble workflow logic into TypeScript — it's surprisingly good at this kind of code transformation.
What I can do now that I couldn't on Bubble
The thing that mattered most: monetization control. Native gives me proper ad scheduling — smart interstitial cool-downs, custom UX gates that prioritize the user experience while still monetizing efficiently. On Bubble I had to choose between ugly placeholder ad layouts (literally "AD SPACE 300x100" blocks in the UI) or no monetization at all. The native version finally lets me orchestrate side-revenue without compromising the product.
Beyond ads — anything performance-sensitive is now actually possible:
- Native animations and gestures (instead of awkward Bubble approximations)
- Push notifications that fire reliably on iOS
- Proper offline state handling
- Deeper iOS integrations (App Store reviews API, deep links, share extension)
- A 6-language landing page with proper server-side rendering — built the same week as the migration
The single best filter for whether YOU should migrate
Can you describe your app in words without opening Bubble? Can you whiteboard the user flows, the data model, the why behind each feature?
If yes, you have a mental model. Your Bubble app is just one implementation of a clearer concept in your head. Migration is hard but doable — the Bubble app becomes a reference, not the source of truth.
If no, your Bubble project IS your product spec. There's no cleaner concept that exists outside the editor. For you, migration would be brutal — half the time would be spent asking "what does this even do? why does it exist? do I need this?" You'd be reverse-engineering your own product while also rebuilding it.
I'm in the first camp (Data Engineer, comfortable architecting things on paper). That's why my migration was 4 days instead of 4 weeks. If you're in the second camp, you have homework to do before any migration makes sense: write your product on paper first, then migrate.
Would I migrate again?
100%. The only thing I'd change is doing it sooner. I'd have my evenings back a year earlier.
Honest advice for anyone in the same spot
- If you're hitting Bubble's mobile UX ceiling and friction is eating your evenings — migrate.
- If you have a clear mental model of your product — migrate.
- If you use AI tools competently — the migration is way smaller than you think. 4-week budgets become 1-week budgets if you can prompt well.
- If your only goal is validation and the UX is good enough as-is — stay on Bubble. There's no virtue in rebuilding what works.
- If you don't have the spec in your head — write it on paper first, then revisit.
The hardest part of the migration wasn't writing code. It wasn't paying for infrastructure. It wasn't even learning React Native. It was admitting that 2 years of platform friction was a tax I was paying, every weekend, on the project I built for fun.
Removing that tax was the most catharic technical decision I've made in years.