# Migrating Bravo Studio to Code: The Complete Playbook (2026)

- Tool: No-Code to Code Migrations
- Last updated: July 2026

## TL;DR

Classic Bravo Studio produces only compiled IPA/AAB bundles — no Swift, Kotlin, or React Native source. Your Figma file is a genuine migration asset you keep. The platform is active but thinly capitalized ($1.1M total, no funding since February 2020) and pivoting to an unproven beta product (Bravo MCP 4.0). Audit whether you are on classic Bravo or the new MCP path before committing to a migration scope: the answer changes everything.

## Platform status

- Status: active — 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.
- Migration urgency: medium
- Typical timeline: 8–12 weeks
- Typical cost: $13K–$25K (agency, fixed)

## Why migrate

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 you can export

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 | Exportable | How |
| --- | --- | --- |
| Data | yes | Backend is bring-your-own (Xano/Airtable/Firebase/REST via Bravo Tags); data lives in your own backend — export from there directly |
| Code | no | Classic Bravo produces compiled IPA/AAB build bundles only; no Swift, Kotlin, or React Native source is accessible |
| 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 |
| Logic/Workflows | no | Bravo Tags (API endpoint bindings) define all data connections; these are not exported as code |
| Users & Auth | partial | Via external backend (Xano/Firebase/etc.); if you control the backend, you have full access to user records and auth data |

## Stack mapping

Bravo's Figma-first architecture maps well to a React Native + Supabase stack — the design work is the migration's biggest head start.

| Platform concept | Code equivalent |
| --- | --- |
| Bravo Figma design | React Native components (re-implemented from Figma; use react-native-reanimated for animations) |
| Bravo Tags (API endpoint bindings) | React Native API calls via fetch/axios or React Query |
| Xano backend (common Bravo pairing) | Stays as-is (Xano REST API) or migrate Xano data to Supabase if Xano lock-in is also a concern |
| Airtable data source | Stays as-is or migrate to Supabase tables |
| Firebase backend | Stays as-is; Firebase SDK available in React Native |
| Convex backend (Bravo MCP 4.0 path) | Stays as-is if choosing Bravo MCP; or swap to Supabase if going fully custom |
| Bravo signed bundle generation (IPA/AAB) | Expo EAS Build for iOS and Android |
| Push notifications | Expo Notifications or Firebase Cloud Messaging |

## 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.

### Phase 1: 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

### Phase 2: 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

### Phase 3: 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

### Phase 4: 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

### Phase 5: 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

## Cost paths

| Path | Cost | Timeline | Fits |
| --- | --- | --- | --- |
| DIY (self with AI tools) | $0–$500 + time | 4–8 months part-time | 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 |
| Freelancer | $3K–$10K | 2–4 months | 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 |
| Agency (RapidDev) | $13K–$25K fixed | 6–10 weeks | 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 and mitigations

- **Beta source-path uncertainty (Bravo MCP / To Go)** — 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** — 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** — 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** — 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)** — 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.

## Stay or go

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

Go 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

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.

## Migration checklist

- 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.

---

Source: https://www.rapidevelopers.com/no-code-to-code/how-to-migrate-bravo-studio-project-to-code
© RapidDev — https://www.rapidevelopers.com/no-code-to-code/how-to-migrate-bravo-studio-project-to-code