Code export · Softr
Softr does not export code. Here is what you can move instead
Export policy checked on September 2026
What comes out
What Softr actually exports.
Softr doesn't export code, and it's upfront about why: the app runs on tested platform components rather than generated code, so there's no custom codebase to download. What you can take with you is the thing that's usually hardest to move — your data — because it never lived inside Softr in the first place.
No app code
There's no HTML/CSS/JS or framework project to export — the pages, blocks and logic run on Softr's hosted platform.
Your data, from its real home
Softr sits on top of Airtable, Google Sheets or its own database. Airtable and Sheets export natively; Softr Databases export to CSV.
You already control the source
Because the data lives in a source you own, you don't extract it from Softr — you take it from Airtable/Sheets/CSV directly.
Custom-code blocks stay put
HTML/CSS/JS snippets you added as blocks (Basic plan and up) run inside Softr — they're an inbound feature, not an app export.
How the export works: There's no export button for the app itself. To leave, you take your data from wherever it lives — export the Airtable base or Google Sheet, or download a CSV from a Softr Database — and rebuild the interface elsewhere.
The gap
What the export does not include.
Because only data comes out, the "gap" is the entire application. That's the shape of a hosted front-end builder: the data was always portable, and the app that presents it is not.
The whole app stays on Softr
Pages, blocks, list and detail views, forms, user accounts and permissions all live on Softr's platform, with no source download. Moving off means re-implementing the interface and its access rules on a stack you own.
BlockerSources: [1]Custom code blocks don't come out as an app
You can inject HTML/CSS/JS into Softr as blocks, but that's you putting code in — not a way to get the assembled app out. Having written a snippet inside Softr doesn't make the site exportable as source.
MinorSources: [2]Some data fields don't transfer cleanly
Airtable-specific fields — record IDs, certain formulas, rollups and lookups — don't always move cleanly between data sources, so a migration needs a reconciliation pass rather than a blind copy.
MinorSources: [1]
The real question
Is the exported code maintainable?
Softr export:No code to assess
There's no exported code to assess, so the real question is data portability — and there Softr is genuinely well-placed, because your data was never trapped. It sits in Airtable, Google Sheets or a Softr Database you can export to CSV, all of which you already control. What you can't carry is the app: the interface, the logic and the permissions are re-implemented on the new stack. The upside is that a rebuild can point straight at your existing data (or a clean Postgres import of it) while giving you an owned front end you can host, extend and hire for.
Your options
What to do with the export.
Three honest routes. The right one depends on how far the app has to go and who is going to own the code once it gets there.
- 01
Stay on Softr
Keep running on Softr. For an internal tool or a portal over Airtable, the hosted model is productive and the data stays portable anyway.
- Right when the app is a straightforward front end over data and Softr's limits aren't hurting.
- Wrong when you need custom logic, real ownership of the app, or to escape per-seat/hosted limits.
- 02
Point a new front end at your existing data
Keep your Airtable/Sheets/Softr-DB data where it is (or export the CSV) and build an owned front end against it.
- Right when the data model is sound and it's the interface and logic you've outgrown.
- 03
Full rebuild on an owned stack
Move the data into a real database and rebuild the app as owned code, so both the data layer and the app are yours.
- Right when the app has to scale or needs logic and integrations Softr can't express.
Softr: the data was never the hard part
The reason a Softr exit is less painful than it sounds is that the usual villain — trapped data — doesn't apply. Portable already: your records, because they live in Airtable, Google Sheets or a Softr Database you can export to CSV. Not portable: the app itself — pages, blocks, forms, accounts and permissions, all of which stay on Softr. So the migration isn't about extracting data from a black box; it's about rebuilding a front end and its access rules on top of data you already hold. That reframes the whole project.
- Code export
- None
- Data
- Airtable / CSV
- Data portable
- Yes
- Leaving =
- Front-end rebuild
Sources: [1]
FAQ
Questions people actually ask.
- Can you export code from Softr?
- No. Softr runs on hosted platform components rather than generated code, so there's no custom codebase to export — no HTML/JS bundle or framework project. What you can take is your data, from the source it already lives in. Leaving Softr means rebuilding the interface, not extracting an app.
- Where does my Softr data live?
- In the source you connected: Airtable, Google Sheets, or Softr's own database. That's the key point — your data was never locked inside Softr's app layer, so you take it from Airtable/Sheets directly, or export a Softr Database to CSV.
- Can I export Softr data to CSV?
- Softr Databases export to CSV, and if your data lives in Airtable or Google Sheets you export it natively from there. So the data side of a migration is straightforward — the work is rebuilding the app around it, since the app itself doesn't export.
- Is Softr lock-in a problem if I leave?
- Less than you'd fear on data, more than you'd like on the app. Your data is portable because it lives in Airtable/Sheets/CSV you control. The app — pages, logic, permissions — stays on Softr and has to be rebuilt. So the lock-in is in the interface layer, not your records.
Every builder, one table
Code export across the hub, at a glance.
The same status table on every export page. “Exports” means real, usable source comes out; “partial” means a major layer is missing; “none” means no source export at all. The nuance is on each page.
| Platform | Code export | What you get |
|---|---|---|
| Lovable | Exports code | React repo via GitHub |
| Base44 | Partial export | Front end; backend locked |
| Webflow | Partial export | Front end only, no CMS |
| FlutterFlow | Exports code | Dart / Flutter source |
| Framer | No code export | Host-only, no export |
| Bolt.new | Exports code | Project files / GitHub |
| Bubble | No code export | No source export |
| Replit | Exports code | Full code, you own it |
| SoftrThis page | No code export | No code (data only) |
| Glide | No code export | No code (data only) |
| Adalo | No code export | No source export |
| Retool | Partial export | Self-host, not source |
| Xano | Partial export | API portable, no export |
Sources
Every claim, traced to a primary source.
The numbered references in the body link here. We cite vendor docs, pricing pages, changelogs and named reporting — dated where the document is dated, so the page can be re-audited each quarter.
- [01]Database migration tips — data sources and export
Softr Help Docsdocs.softr.io
- [02]Custom code block overview
Softr Help Docsdocs.softr.io
Own the Softr app outright?
We’ll map the route to code you actually own.
Book a call with Jackson, our Growth Partner — he’ll walk your export or app, the gaps that matter, and a fixed-price plan to get it production-ready, live on your screen. Or get an instant estimate first.
Or see fixed-price migration packages and how we work.