An export can preserve “Door seal damaged” without the photo, access rules or logic that created the inspection. Compare Bubble and WeWeb + Xano by what you would need to retrieve, rebuild and host after leaving.
The property-inspection product below is fictional. Aster Properties, Birch Properties and their records are invented, not vendor exports. No application was built, published or migrated, and no attachment binary exists. The inventory separates documented exports from the behaviour a replacement still needs.
The inspection you want to take with you
- Two account rows
acct-demo-A: Aster Properties.acct-demo-B: Birch Properties.- Inspection row
ID:
insp-demo-101
Account:acct-demo-A
Owner:user-demo-A
Status:draft- Finding row
ID:
finding-demo-01
Inspection:insp-demo-101
Text: “Door seal damaged”
Attachment:file-demo-01- File-reference row
ID:
file-demo-01
Storage key:demo/door-01.jpgbytes_exported=false
These references connect the account, inspection, finding and attachment, but contain no image bytes or sign-in, validation or access rules. Displaying the finding while letting Birch read Aster’s inspection would fail the product’s access requirement.
Three different meanings of “export”
Vendor documentation checked on 13 September 2026 establishes the following boundaries. No successful export or deployment is implied.
Bubble: database records leave; application logic is rebuilt
Bubble documents database exports in CSV, JSON and Newline-Delimited JSON (NDJSON). Those formats carry data, not an executable application. Bubble data exports.
Bubble says its apps run only on its platform and cannot be exported as application code. Leaving requires rebuilding the logic. Its promise to release Bubble’s source if the service is discontinued does not provide a current self-hosting option. Application and data ownership.
WeWeb: an interface ZIP is not the whole service
WeWeb documents an interface ZIP for self-hosting, available after at least one publish. The same page says fullstack self-hosting for WeWeb-managed backend capabilities is not yet available. Hosting the interface does not move its database, file and authentication services with it. WeWeb hosting and code export.
In a WeWeb + Xano design, check Xano backend portability, data exports, attachment bytes and authentication separately from the UI ZIP. Inventory the interface’s URLs, headers, bindings and plugin dependencies; plugin compatibility still needs project-specific checks.
Xano: records, definitions and runtime are separate
Xano documents CSV export for a table or selected database view. CSV export. It also documents CLI workspace pulls as individual .xs XanoScript definition files; --records optionally includes database records. CLI push and pull.
XanoScript definitions are not proof of a vendor-independent Node or Python runtime. Xano offers own-cloud or on-premises self-hosting on Custom plans arranged with its team, not on every plan. That arrangement is distinct from an independent backend runtime. Xano self-hosting FAQ.
What is still missing from this inspection
Illustrative exit inventory, not test results: both columns apply the documented boundaries to the same fictional records and product requirements.
| Asset or behaviour | Leaving Bubble | Moving a WeWeb + Xano system |
|---|---|---|
| Account, inspection and finding rows | Use the documented database export; map IDs and relationships into the replacement database. | Export Xano data separately from the UI: table/view CSV or a CLI pull with records. Map IDs and relationships. |
| Attachment bytes | The sample file reference is not the photo. Retrieve the authorised binary separately from its actual host. | The UI ZIP and sample file reference do not establish a binary export. Identify the file host and retrieve the authorised bytes separately. |
| Sign-in and roles | Replace platform-dependent authentication and access behaviour when leaving. User rows alone do not implement it. | The interface still needs an auth service. Exportable definitions do not establish session, password or password-hash portability. |
| Create inspection | Rebuild the workflow’s validation and actions. | Preserve the frontend request bindings and run the backend validation in an explicitly supported runtime. |
| Known foreign-ID denial | Recreate and test the access rule; a database export does not enforce it in a replacement app. | Preserve and test backend denial after changing hosting or bindings. Hiding an inspection in the UI is not the required denial. |
| Hosting | Current app execution remains on Bubble until the replacement is built. | The interface can have its own host; the backend needs its own supported arrangement. Xano Custom self-hosting is not independent-runtime proof. |
For the rows, the next check is to compare actual authorised counts, IDs, nulls, relations and timestamps after import. For file-demo-01, require the retrieved bytes, a matching checksum and intended access on the destination—not merely the string demo/door-01.jpg. There is no checksum to report for this fictional file.
The behaviour requirements are equally concrete. A signed-in user-demo-A must be able to create a valid inspection within acct-demo-A; invalid input and duplicate submission need defined handling. user-demo-B must not read insp-demo-101 by supplying its known ID. Login, logout, session expiry and recovery must work in the destination. All of these remain expectations to test, not observed vendor outcomes. The separate tenant-request guide covers allowed and denied requests in its own implementation context.
Choose the exit obligation you can accept
- If rebuilding application logic on departure is acceptable, Bubble remains a candidate under that explicit constraint. Do not disguise the rebuild as a database import.
- If independently hosting the interface is required, WeWeb’s documented export addresses that layer. WeWeb + Xano remains a candidate only if you also accept and verify the separate backend, file and authentication arrangements.
- If a vendor-independent backend runtime is mandatory, neither a Bubble database export nor XanoScript files establish that requirement. Keep the architecture decision open until a supported destination runtime is demonstrated.
No plan, region or workload quote was obtained. Cost, build speed, safety, scale and migration effort have not been measured or ranked.
Start an authorised exit check with one real inspection matching this example. Export its records, retrieve its photo and reconstruct their relationship outside the source system. This checks the missing attachment; the application behaviours listed above still need testing.