Migration snapshot
ActivePlatform
a Teta
Teta (Rome, Italy; Crunchbase) historically a Flutter no-code builder, now markets as 'Teta | AI App Builder' with SvelteKit-first output and VS Code integration deploying to Vercel. Ships an open-source version ('Teta OSS,' AGPL-3.0; GitHub ondateta/teta; last updated December 2025).
Typical timeline
6–10 weeks
Typical cost
$13K–$25K (agency, fixed)
Why teams leave a Teta
Teta's Flutter-to-SvelteKit pivot means users may be on a product that has fundamentally changed. The good news is code is exportable — the challenge is knowing which export you have and where it leads.
Product identity shift — Flutter era vs SvelteKit/AI era
If you built a Flutter app on Teta, the current product has moved to SvelteKit/AI. Export targets, documentation, and supported features may no longer match your project. The two eras require completely different migration strategies.
Flutter code export value depends on code quality
Older Teta projects historically exported Flutter code — but the migration value depends heavily on whether the generated Flutter code is clean enough to maintain independently. Generated code quality from no-code tools varies significantly.
SvelteKit vs Next.js ecosystem mismatch
The new Teta is SvelteKit-first, but most teams in 2026 target Next.js for web apps. Migrating from Teta SvelteKit output to Next.js still requires meaningful refactor work — same concept but different framework syntax and conventions.
AGPL-3.0 copyleft on Teta OSS
The open-source version (Teta OSS) is licensed under AGPL-3.0. If you are building a commercial SaaS and plan to self-host Teta OSS, AGPL copyleft obligations apply and must be understood before proceeding.
Small vendor with shifting roadmap
Anecdotal reviews (Capterra, incentivized) report that updates sometimes broke essential builder features. Small Rome-based team with a major product pivot = execution risk for production apps dependent on the platform.
What can you actually take with you?
Teta is one of the better exits in the mobile builder category because code is genuinely exportable — but the mechanics differ entirely between Flutter-era and SvelteKit-era projects. Verify your project vintage first.
| Asset | Can you export it? | How | Notes |
|---|---|---|---|
| Data | Partial | Backend and database access depends on whether the backend was Teta-managed (no-SQL query historically) or external. Export path is not centrally documented. | If backend was Teta-managed, contact support for data export before starting migration. If external backend, export directly from that system. |
| Code | Yes | Flutter-era projects exported Flutter code. Current SvelteKit product has VS Code integration and Vercel deploy, plus Teta OSS (AGPL-3.0, GitHub ondateta/teta, updated December 2025) that can be self-hosted. | Verify which output (Flutter vs SvelteKit) matches your project vintage — export mechanics differ entirely. Check for .dart files (Flutter) vs .svelte files (SvelteKit) in your export. |
| Design/UI | Yes | UI is in the exported code — Flutter components for Flutter-era projects, SvelteKit components for current projects. | UI is embedded in the code export, not a separate design file export. |
| Logic/Workflows | Yes | Business logic is in the exported code for both product eras. | Same vintage caveat applies — confirm which codebase you are exporting before planning the port. |
| Users & Auth | Partial | OAuth providers were historically supported (Teta Auth). If auth was Teta-managed, export path is not documented. | Password hashes not documented as exportable. If auth was Teta-managed, plan a forced password reset for all users. |
Swipe the table sideways to see the full breakdown.
Where each piece moves in code
Teta projects migrate to Next.js + Supabase (web-first) or React Native + Expo (mobile) depending on project era and target platform — keeping Vercel as the deployment target is valid for SvelteKit-era projects.
a Teta
Teta SvelteKit pages (current product)
In code
Next.js app router pages
Component-by-component port; Svelte-to-React syntax differences require manual rewrite but structure is similar
a Teta
Teta Flutter screens (legacy product)
In code
React Native + Expo screens
Flutter-to-React Native is a different paradigm — budget for UI rebuild, not line-by-line conversion
a Teta
Teta OSS AGPL editor
In code
Drop entirely; run own Next.js codebase
Do not self-host Teta OSS for a commercial product without legal review of AGPL-3.0 obligations
a Teta
Teta Auth / OAuth providers
In code
Supabase Auth (email, GitHub, Google OAuth providers)
Supabase supports the same OAuth providers Teta historically offered
a Teta
Teta no-SQL queries (backend)
In code
Supabase PostgreSQL with Row Level Security
Design schema from Teta data model; add RLS policies per table
a Teta
Vercel deploy target (SvelteKit era)
In code
Keep Vercel — compatible with both SvelteKit and Next.js
No hosting migration required for SvelteKit-era projects that already deploy to Vercel
a Teta
AI builder features (current product)
In code
Remove dependency; replace with standard development workflow
After export, you no longer need the Teta AI layer — the code is yours
The migration roadmap
The first step is diagnostic: determine your project vintage. Everything else — the migration target, the tools, the timeline, the risk profile — flows from that single question.
Phase 1 — Determine Project Vintage & Extract
Week 1- Confirm project vintage: open exports and check for .dart files (Flutter era) vs .svelte files (SvelteKit era)
- Download or clone the full exported codebase from Teta or GitHub sync immediately
- Export all backend data — contact Teta support if no-SQL export path is not self-service
- Verify Auth provider: was auth Teta-managed or external OAuth?
- If considering Teta OSS self-host: read AGPL-3.0 license before proceeding for commercial use
Watch out: If backend was Teta-managed and data export path is undocumented, this is the critical blocker. Prioritize data extraction before any other work.
Phase 2 — Choose Migration Strategy
Week 1–2- Flutter-era: exported Flutter code is your starting point — decide to continue as React Native (port) or rebuild in Next.js (web-first)
- SvelteKit-era: exported SvelteKit code is the baseline — port to Next.js or deploy SvelteKit as-is on Vercel (eliminating Teta dependency)
- Assess exported code quality: does it boot, is it maintainable, is it clean enough to extend?
- Choose target stack and confirm deployment infrastructure
Phase 3 — Foundation Setup
Week 2–4- Set up Next.js or Expo project with TypeScript and Tailwind/NativeWind
- Provision Supabase project; design schema from Teta data model
- Configure Supabase Auth; plan forced password reset flow if auth was Teta-managed
- Set up Vercel deployment (Next.js) or Expo Application Services (React Native)
Phase 4 — Code Migration & Feature Build
Week 4–9- Port SvelteKit components to React/Next.js (or Flutter components to React Native)
- Migrate data from Teta backend to Supabase PostgreSQL
- Implement auth flow with Supabase Auth; test OAuth provider connections
- Rebuild any AI builder-generated features as standard React components
Watch out: Flutter-to-React Native is not a line-by-line port — it is a UI paradigm change. Budget for full screen recreation, not just syntax translation.
Phase 5 — QA & Cutover
Week 9–10- Full QA pass against feature inventory on target platforms
- Deploy to Vercel (web) or submit via EAS to App Store/Play Store (mobile)
- Send password-reset communication if auth was Teta-managed
- Monitor post-launch; decommission Teta account after stable period
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 (with AI tools)
$0–500 + time
3–6 months part-time
Fits
Developers comfortable with both the source framework (Flutter or SvelteKit) and the target (React Native or Next.js). Teta has a better DIY story than most mobile builders because you have actual code to start from.
Risks
Flutter-to-React Native scope is regularly underestimated — they are not the same paradigm. Data extraction from Teta-managed backend may require vendor cooperation. AGPL implications need legal review if self-hosting OSS.
Freelancer
$3K–10K
1–3 months
Fits
SvelteKit-era projects with clean exported code that needs porting to Next.js. Flutter-era projects are a harder freelancer scope due to paradigm differences. Works well if data extraction is already complete.
Risks
Freelancers may not anticipate Teta-managed backend extraction complexity. Vet for experience with both the source framework and Supabase migration.
Agency (RapidDev)
Done-for-you$13K–$25K fixed
6–10 weeks
Fits
Production apps where the project vintage is unclear, backend data extraction is at risk, or the Flutter-to-React Native scope needs accurate estimation before committing. Fixed price handles ambiguity without cost overruns.
Risks
Minimal. RapidDev assesses project vintage in week 1 and scopes accordingly. Free scoping call at rapidevelopers.com.
The real risks — and how to defuse them
Misidentified project era — wrong migration strategy chosen
Mitigation: Check file extensions in your export before planning anything. .dart files = Flutter era (port to React Native or rebuild web). .svelte files = SvelteKit era (port to Next.js or deploy SvelteKit as-is). Do not plan until you know.
Data stranded in Teta-managed backend
Mitigation: Contact Teta support immediately for data export if the no-SQL backend was Teta-managed and not clearly self-service accessible. This is the highest-risk scenario — prioritize it in week 1.
AGPL-3.0 copyleft trap — self-hosting Teta OSS for commercial SaaS
Mitigation: Do not self-host Teta OSS (GitHub ondateta/teta) for a commercial product exposed to users without legal review. AGPL-3.0 requires source disclosure for software used as a network service. Consult legal counsel before proceeding.
Flutter-to-web scope severely underestimated
Mitigation: Flutter and React Native are different UI paradigms. Budget for full UI recreation, not line-by-line conversion. Run a component audit on the Flutter export to understand the actual rebuild scope before committing to a timeline.
Small vendor longevity — pivot plus small team equals execution risk
Mitigation: Self-host the exported code or move to standard code immediately. Teta OSS GitHub shows last commit December 2025 — check repo activity as a longevity signal before deciding how quickly to migrate.
Should you actually migrate?
Migrating is a real project. Sometimes staying is the right call — here is the honest split.
Stay if
- You are on the SvelteKit product, already deploying to Vercel, and the OSS editor works for your team's workflow
- You want a visual editor on top of real code and AGPL self-hosting is acceptable for your non-commercial use case
- Your project is a web MVP where SvelteKit (not Next.js) is acceptable long-term and you have no plans to switch frameworks
- You are on the Flutter era and the exported Flutter code runs cleanly and serves your mobile app without Teta dependency
Migrate if
- You built in Flutter-era Teta and the product has moved — your Flutter app no longer aligns with current Teta documentation or support
- You need Next.js or React Native and do not want to maintain a SvelteKit codebase or manage framework migration yourself
- Your backend is Teta-managed and you cannot extract data cleanly — staying creates ongoing data portability risk
- The AGPL copyleft on Teta OSS conflicts with your commercial product plans
Our honest verdict
Teta is one of the better exits in the mobile builder category because code is exportable and an OSS option exists. But the Flutter-to-SvelteKit pivot means you may be on a product that no longer exists in the same form. Confirm your project era before any other decision.
Do this today: pre-migration checklist
Whatever path you choose, protect yourself first. Work through this before you touch a line of code.
Determine your project vintage: open exports and check for .dart files (Flutter) vs .svelte files (SvelteKit)
This single check determines your entire migration strategy — wrong diagnosis wastes weeks
Download or clone the full exported codebase from Teta or GitHub sync immediately
Your code export is the primary migration asset — secure it now regardless of migration timeline
Export all backend data — contact Teta support if the no-SQL export path is not self-service
Teta-managed backend data is the highest-risk asset; resolve extraction before anything else
Verify Auth provider: was auth Teta-managed or external OAuth? If Teta-managed, plan password reset
Teta-managed auth means forced password reset for all users — build this into launch planning
Read the AGPL-3.0 license if considering Teta OSS self-host for a commercial product
AGPL copyleft applies if you expose Teta OSS as a service — legal review required first
Check GitHub ondateta/teta repo health (last commit December 2025) for OSS longevity signal
Repo activity tells you whether the OSS editor is maintained enough to self-host long-term
Decide migration target: React Native (mobile), Next.js (web), or SvelteKit-as-is on Vercel
Target determines the entire rebuild scope; lock this in before starting any development work
Frequently asked questions
Can I export my Teta app's code?
Yes, in both product eras — but the output differs. Flutter-era Teta projects exported Flutter (.dart) code. The current SvelteKit-era product provides SvelteKit code via VS Code integration and Vercel deploy, plus a self-hostable OSS editor (GitHub ondateta/teta, AGPL-3.0, updated December 2025). The critical first step is determining which era your project is from: check your export for .dart files (Flutter) or .svelte files (SvelteKit).
Can I export my Teta app's data?
It depends on whether your backend was Teta-managed or external. If Teta managed the no-SQL backend, the export path is not centrally documented — contact Teta support and request an export before starting any migration. If you connected an external backend, export from that system directly. Prioritize data extraction above all other migration steps.
How long does a Teta migration take?
Typically 6–10 weeks for a web-first migration (SvelteKit to Next.js). Flutter-to-React Native migrations run 8–12 weeks because the paradigm shift requires UI recreation rather than code porting. Data extraction complexity adds time if the backend was Teta-managed. A SvelteKit-era project deploying to Vercel with clean code can move faster.
What happens to my users and their passwords after migration?
If auth was Teta-managed, you will need to trigger a forced password reset for all users. Password hashes from Teta's auth system are not documented as exportable. If you used external OAuth providers (GitHub, Google), those users can continue to log in via OAuth on the new platform — only password-based accounts require a reset.
Is Teta shutting down?
Teta is not confirmed to be shutting down as of July 2026. The company is operating with a pivoted product (SvelteKit/AI) and an open-source editor (GitHub ondateta/teta, last commit December 2025). The pivot from Flutter to SvelteKit is the main concern — if you built in the Flutter era, you may effectively be on a discontinued product path even though Teta the company is still running.
What is the AGPL-3.0 implication for Teta OSS?
Teta OSS is licensed under AGPL-3.0, which is a copyleft license. If you self-host Teta OSS and expose it as a service to users (for example, in a commercial SaaS product), AGPL requires you to make your source code available. This is distinct from deploying your own application built with Teta's output — the AGPL applies to the Teta editor software itself, not to the SvelteKit or Flutter code it generates. Get legal review before self-hosting Teta OSS for a commercial product.
What is the difference between migrating Flutter-era Teta vs SvelteKit-era Teta?
Flutter-era: your export is .dart files targeting iOS and Android. Migration target is React Native + Expo for mobile parity. This is a paradigm change, not a port. SvelteKit-era: your export is .svelte files targeting web, deployable to Vercel. Migration target is Next.js + Supabase. This is a framework port (Svelte → React) on similar web infrastructure. The two paths have different timelines, tooling, and skill requirements.
Can RapidDev handle Teta migrations from both the Flutter and SvelteKit eras?
Yes. RapidDev assesses your project vintage in the first week and scopes accordingly — Flutter-era projects are scoped as React Native + Supabase rebuilds; SvelteKit-era projects are scoped as Next.js ports. Both are offered as fixed-price engagements. Book a free scoping call at rapidevelopers.com.
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.