Migration snapshot
ActivePlatform
a Bravo Studio
Bravo Studio (Barcelona; legal entity App Foundry S.L. / 'Codeless Labs'; founder/CEO Toby Oliver; ~27 employees) is operating. Has not raised any funding since a $1.1M pre-seed on February 28, 2020. The 2026 bet is 'Bravo MCP' (Bravo 4.0, beta) — building native apps from inside Claude/ChatGPT/Cursor with React Native + Convex backend output. Also launched 'Bravo To Go' (done-for-you path with source code ownership). The React Native code-ownership path announced but still in beta as of the research date.
Typical timeline
8–12 weeks
Typical cost
$13K–$25K (agency, fixed)
Why teams leave a Bravo Studio
Bravo Studio's core promise — design in Figma, publish as a native app — works, but it comes with no code ownership, a mandatory external backend dependency, and a platform running on six-year-old seed funding.
No code export in the classic product
Bravo generates compiled build bundles (IPA/AAB) only — not Swift, Kotlin, or React Native source. The skywork.ai 2025 guide confirms this. Source ownership is only available via Bravo To Go or Bravo MCP (4.0 beta) — both are new paths, not the classic product most users built on.
Thin capitalization with no follow-on funding
Only $1.1M raised total (pre-seed, February 2020); no subsequent rounds in over six years; approximately 27 employees. Compared to any other mobile builder in the category, Bravo is the thinnest-capitalized platform — a genuine longevity risk if the MCP beta does not generate revenue.
Mandatory external backend dependency
Bravo requires you to bring your own backend (Xano, Backendless, Airtable, Firebase, or any REST API via Bravo Tags). This creates a two-vendor dependency structure: Bravo goes down or pivots, and your app's data layer is in a separate vendor you may or may not control.
Figma dependency and sync fragility
Changes in Figma do not auto-sync to Bravo; updates require manually pressing the Update icon. Figma permission issues and certain AI-generated Figma file URLs ('/make/' paths) break imports. These are documented community issues, not edge cases.
Bravo MCP 4.0 is beta and unverified externally
The React Native code-ownership path is announced but not confirmed as generally available. Do not promise clients a 'code export' path based on Bravo's marketing claims without testing your specific app first.
What can you actually take with you?
Your Figma file is a genuine and portable migration asset. Your external backend data is also owned by you. But classic Bravo produces no source code — the compiled bundles (IPA/AAB) are not extractable into readable source.
| Asset | Can you export it? | How | Notes |
|---|---|---|---|
| Data | Yes | Backend is bring-your-own (Xano/Airtable/Firebase/REST via Bravo Tags); data lives in your own backend — export from there directly | No Bravo-hosted data to extract; confirm you hold credentials for your external backend independently before starting migration |
| Code | No | Classic Bravo produces compiled IPA/AAB build bundles only; no Swift, Kotlin, or React Native source is accessible | Source ownership only via Bravo To Go or Bravo MCP 4.0 beta — verify your specific app path before assuming code exists; 'own the code' via MCP is unconfirmed as generally available |
| Design/UI | Yes | The Figma file IS the design source; you keep it; this is a genuine migration advantage over platforms like Adalo or Thunkable | Verify the Figma file is in your own Figma account and is not locked to a Bravo team workspace; export a local .fig backup |
| Logic/Workflows | No | Bravo Tags (API endpoint bindings) define all data connections; these are not exported as code | Document all Bravo Tags (endpoint URLs, parameter names, response mappings) — these become the API integration spec for the rebuild |
| Users & Auth | Partial | Via external backend (Xano/Firebase/etc.); if you control the backend, you have full access to user records and auth data | Password hashes depend on the backend: Firebase Auth gives you full control; Xano auth exports vary by plan; not documented by Bravo directly |
Swipe the table sideways to see the full breakdown.
Where each piece moves in code
Bravo's Figma-first architecture maps well to a React Native + Supabase stack — the design work is the migration's biggest head start.
a Bravo Studio
Bravo Figma design
In code
React Native components (re-implemented from Figma; use react-native-reanimated for animations)
Figma file is owned and portable; use it as the pixel-perfect spec for React Native component implementation
a Bravo Studio
Bravo Tags (API endpoint bindings)
In code
React Native API calls via fetch/axios or React Query
Each Bravo Tag maps to an API call; document all endpoint URLs and response shapes before touching code
a Bravo Studio
Xano backend (common Bravo pairing)
In code
Stays as-is (Xano REST API) or migrate Xano data to Supabase if Xano lock-in is also a concern
Decide upfront whether to keep Xano or migrate to Supabase; doing both simultaneously increases timeline but eliminates dual lock-in
a Bravo Studio
Airtable data source
In code
Stays as-is or migrate to Supabase tables
Airtable is viable for content-light apps; Supabase is recommended for apps with relational data or query complexity
a Bravo Studio
Firebase backend
In code
Stays as-is; Firebase SDK available in React Native
Firebase Auth user records are fully portable; no migration required if you control the Firebase project
a Bravo Studio
Convex backend (Bravo MCP 4.0 path)
In code
Stays as-is if choosing Bravo MCP; or swap to Supabase if going fully custom
Only relevant for apps built on Bravo 4.0 MCP beta; classic Bravo apps typically use Xano, Firebase, or Airtable
a Bravo Studio
Bravo signed bundle generation (IPA/AAB)
In code
Expo EAS Build for iOS and Android
EAS Build handles code signing, versioning, and App Store submission; confirm you hold Apple/Google developer accounts
a Bravo Studio
Push notifications
In code
Expo Notifications or Firebase Cloud Messaging
Standard React Native notification stack; re-configure notification triggers that previously ran through Bravo's backend
The migration roadmap
The first decision in a Bravo migration is whether you are on classic Bravo (full rebuild) or Bravo MCP/To Go (potentially code cleanup). Get the answer before writing a single line of code.
Audit and Decision Gate
Week 1- Determine whether the app is on classic Bravo or Bravo MCP/To Go — contact Bravo support to confirm if unclear
- If on Bravo MCP/To Go: verify whether React Native source code is accessible, buildable, and runs on a device
- Download and back up the Figma source file immediately (this is the single most portable migration asset)
- Document all Bravo Tags: endpoint URLs, HTTP methods, parameter names, response data mappings, authentication headers
- Confirm ownership of Apple App Store Connect and Google Play Console developer accounts — Bravo Solo plan includes store submission on your behalf
Watch out: If Figma file URLs include '/make/' paths or have permission restrictions, test a Figma export immediately — these known issues can block migration if discovered late
Backend Decision and Data Backup
Week 1–2- Decide upfront: keep existing backend (Xano/Firebase/Airtable) or migrate to Supabase during the rebuild
- Export all data from the external backend and verify you hold credentials independently of any Bravo team workspace
- If migrating to Supabase: design the target schema from Bravo Tag response shapes; plan data import process
- If keeping Xano: verify Xano plan allows direct API access from a self-hosted React Native app without Bravo intermediation
React Native Scaffold and Core Screens
Weeks 2–6- Scaffold the React Native project with Expo and configure React Navigation or Expo Router
- Implement auth screens first — auth architecture (Firebase keep vs. forced reset for Xano-managed users) must be resolved before any other screen work
- Build screens from the Figma file in priority order: revenue-critical and highest-traffic screens first
- Connect each screen to the backend via React Query or fetch/axios using the documented Bravo Tag spec
Integrations, Notifications, and QA
Weeks 7–10- Implement push notifications with Expo Notifications or Firebase Cloud Messaging
- Replace any Bravo-mediated payment flows with direct Stripe SDK integration
- Full regression QA against the Figma file and screen recordings; validate every user flow end-to-end
- Performance testing: validate backend response times under production-volume data
Launch and Cutover
Weeks 10–12- Submit to Apple App Store and Google Play via Expo EAS Build; allow 3–7 days for store review
- Execute user auth cutover plan (password reset campaign if applicable)
- Monitor production for 72 hours post-launch before canceling Bravo subscription
- Cancel Bravo only after the new app is approved on all stores and live update channels are confirmed working
Watch out: Do not cancel Bravo before store approval — users are live on the Bravo-published version until cutover is complete
Three ways to migrate — honestly
Every path has a real trade-off. Here is what each costs, how long it takes, and where it bites.
DIY (self with AI tools)
$0–$500 + time
4–8 months part-time
Fits
Technical founders comfortable with React Native, Figma-to-code translation, and backend API integration; works best for simple apps (under 10 screens) with a clean external backend
Risks
No source code to reference — Figma files and screen recordings are the only spec. Backend decision (keep vs. migrate) adds significant scope if chosen late. Thin-vendor risk means rebuilding is time-sensitive.
Freelancer
$3K–$10K
2–4 months
Fits
Apps with 10–20 screens and a clear Figma file as spec; most effective when the Bravo Tag documentation is complete before the freelancer starts
Risks
Vetting is harder without a codebase to review — assess the freelancer on React Native + Figma-to-code work specifically. Backend migration (if Xano-to-Supabase is in scope) adds complexity.
Agency (RapidDev)
Done-for-you$13K–$25K fixed
6–10 weeks
Fits
Founders who need code ownership for due diligence or fundraising, apps with complex backend migration (Xano to Supabase), or teams where thin-vendor risk makes timeline certainty non-negotiable
Risks
Higher investment is justified when backend migration and Figma fidelity requirements combine with a firm launch deadline
The real risks — and how to defuse them
Beta source-path uncertainty (Bravo MCP / To Go)
Mitigation: Do not promise clients a 'code export' path based on Bravo's marketing claims without first verifying that the React Native source is accessible, buildable, and passes a basic functionality test on a device. Treat MCP output as unverified until confirmed.
Figma sync fragility blocking migration prep
Mitigation: If the Figma file uses AI-generated URLs ('/make/' paths) or has permission restrictions, test a Figma export immediately. Figma import failures in Bravo are documented; catch them before migration planning depends on the file.
Thin vendor capitalization creating sudden service degradation
Mitigation: No funding since 2020, ~27 employees, and a platform pivot to a beta product. Export and back up everything independent of Bravo's platform today: Figma file, backend data, App Store credentials. Do not start new feature builds on Bravo while planning exit.
App Store account ownership gap
Mitigation: Bravo's Solo plan includes store submission on your behalf. Verify you hold Apple App Store Connect and Google Play Console accounts independently. Request account transfer documentation from Bravo before starting any rebuild work.
Dual backend lock-in (Bravo + Xano)
Mitigation: If the backend is Xano, decide in the scoping phase whether to keep Xano or migrate to Supabase during the rebuild. Attempting to evaluate both options mid-project is a timeline risk. Both are viable; the decision should be made once and committed to.
Should you actually migrate?
Migrating is a real project. Sometimes staying is the right call — here is the honest split.
Stay if
- You are actively using Bravo MCP 4.0 and getting usable React Native code output via the new AI-agent path — evaluate the code quality carefully before assuming a separate migration is needed
- The app is a Figma-heavy design showcase (product catalog, portfolio, brand app) where Bravo's design-fidelity strength is the core value and backend logic is minimal
- Development velocity with Bravo MCP is meeting your roadmap needs and the beta is stable enough for your use case today
Migrate if
- You are on classic Bravo with no MCP/To Go access and need code ownership for any reason — due diligence, technical team hiring, acquisition, or investor data room requirements
- The combination of thin capitalization ($1.1M total, no funding since 2020) and a beta platform pivot makes you uncomfortable with longevity for a production app you depend on
- Figma sync issues, Bravo Tag failures, or external backend dependency costs have made the platform more fragile than expected in production
- Your backend is Xano and you want to consolidate to a single vendor with a standard PostgreSQL interface (Supabase) — the migration resolves both lock-ins at once
Our honest verdict
Classic Bravo is a full rebuild exit — your Figma files come with you, but no other code does. Bravo MCP is an interesting bet if it works, but it is beta and unverified externally. If code ownership matters for any business reason, plan the exit now rather than waiting to see if Bravo 4.0 stabilizes.
Do this today: pre-migration checklist
Whatever path you choose, protect yourself first. Work through this before you touch a line of code.
Download and back up your Figma source file today
The Figma file is your single most portable migration asset — it becomes the pixel-perfect spec for the React Native rebuild
Verify whether your app is on classic Bravo or Bravo MCP/To Go
The migration scope differs significantly: classic Bravo is a full rebuild; MCP/To Go may have accessible React Native source that changes the timeline and cost entirely
If on Bravo MCP/To Go: test whether React Native source is accessible, buildable, and runs on a device
Do not assume code exists based on Bravo's marketing; test it before committing to any migration scope or timeline
Confirm ownership of Apple App Store Connect and Google Play Console developer accounts
Bravo Solo plan includes store submission on your behalf; if Bravo holds the accounts, losing them on exit loses your app listing and review history
Document all Bravo Tags: endpoint URLs, HTTP methods, parameter names, and response data mappings
Bravo Tags are the only documentation of your API integration layer; they become the rebuild spec for all data connections
Export all data from your external backend (Xano/Firebase/Airtable) and confirm you hold those credentials independently
Backend data is owned by you, but only if your credentials are independent of any Bravo workspace or team account
Decide upfront whether to keep your current backend or migrate to Supabase during the rebuild
Changing this decision mid-project is a timeline and budget risk; commit to one path in the scoping phase before development begins
Frequently asked questions
Can I export my Bravo Studio app code?
In the classic Bravo product: no. Bravo generates compiled IPA and AAB build bundles only — not Swift, Kotlin, or React Native source. This is confirmed by independent sources including skywork.ai's 2025 guide. The exception is Bravo To Go and Bravo MCP 4.0 (beta), which are new paths offering React Native source output — but both are unverified externally as of the research date. If you built on classic Bravo, assume a full rebuild is required.
What assets can I take with me when I leave Bravo Studio?
Your Figma file is the most valuable and genuinely portable asset — it comes with you and becomes the spec for your React Native rebuild. Your external backend data (Xano/Firebase/Airtable) is also owned by you if your credentials are independent of Bravo's workspace. What you cannot take is the app logic and API bindings (Bravo Tags) in code form; these must be re-implemented.
How long does migrating from Bravo Studio take?
For a classic Bravo app (full rebuild from Figma spec), typically 8–12 weeks with an experienced team. The Figma file as spec is a genuine head start compared to platforms where screens must be recreated from scratch recordings. Apps with complex backends (Xano-to-Supabase migration in scope) or 30+ screens take the full 12 weeks. If Bravo MCP/To Go source code is verified as buildable, timeline can shrink to 4–6 weeks for code cleanup and CI/CD setup.
What happens to my users and their passwords when I migrate?
It depends on your backend. If you use Firebase Auth, user records and auth tokens are in your Firebase project — no password reset required. If you use Xano-managed auth or any backend where Bravo intermediated the auth flow, verify that user credential export is possible with your Xano plan. Password hashes are not documented by Bravo directly. Plan a forced password-reset email campaign as a fallback for any users whose auth cannot be cleanly migrated.
Is Bravo Studio shutting down?
No confirmed shutdown as of mid-2026. Bravo Studio is operating and shipping new features (Bravo MCP 4.0 beta, Bravo To Go). The concern is not imminent shutdown but thin capitalization: only $1.1M raised total in a pre-seed round from February 2020, with no subsequent funding rounds and approximately 27 employees. A platform pivot to an unproven beta product (MCP) adds a second layer of uncertainty. These are not shutdown signals — but they are meaningful longevity risks for a production app you depend on.
What is the difference between classic Bravo and Bravo MCP 4.0?
Classic Bravo takes a Figma design and publishes it as a native app with API bindings (Bravo Tags) — no source code produced. Bravo MCP 4.0 (beta) is a new approach where you build native apps by talking to Claude, ChatGPT, or Cursor, and Bravo generates React Native + Convex source code. Bravo To Go is a done-for-you service that includes source code ownership. If you are on classic Bravo and want code ownership, migrating off the platform is the only proven path.
Should I keep Xano or migrate to Supabase when I leave Bravo?
Both are valid choices, but decide before coding starts — not during. Keep Xano if your team is productive in it, the data model is complex and already working well, and Xano's pricing is acceptable. Migrate to Supabase if you want a single vendor with a standard PostgreSQL interface, Row Level Security, real-time subscriptions, and a generous free tier for smaller apps. Attempting both options in parallel mid-project is a significant timeline risk.
How much does a Bravo Studio migration cost, and can RapidDev help?
DIY with AI tools costs $0–$500 in direct expenses but 4–8 months of part-time work — feasible for technical founders with simple apps and a clean Figma file. Freelancers typically charge $3K–$10K for a 10–20 screen rebuild over 2–4 months. RapidDev offers fixed-price Bravo migrations at $13K–$25K completed in 6–10 weeks, including backend decision consulting, Figma-to-React Native implementation, and App Store submission. Book a free scoping call if you are not sure whether your app needs a full rebuild or qualifies for the MCP code-cleanup path.
We migrate no-code apps to production code
- Fixed price — $13K–$25K (agency, fixed)
- No data loss, no downtime
- You own 100% of the code
30-min call. Quote within 48 hours.