Migration snapshot
ActivePlatform
a WeWeb
WeWeb is operating normally and actively expanding as of 2026. It launched native backend 'WeWeb Tables' (Postgres + auth + storage) in April 2026, overhauled pricing in April 2026, and has WeWeb AI in beta since February 2025. SSR has been explicitly confirmed off the 2026 roadmap (CEO statement, weweb.io/blog/our-2026-roadmap). No shutdown signals.
Typical timeline
6–12 weeks
Typical cost
$13K–$25K (agency, fixed)
Why teams leave a WeWeb
WeWeb is one of the better visual app builders — it is honest about its constraints and has strong Figma-to-app workflows. Teams migrate when they hit specific ceilings the platform is not designed to cross.
SEO and SSR requirement
WeWeb is a client-rendered SPA and the CEO confirmed SSR is off the 2026 roadmap. Lighthouse mobile scores of 20–50 are typical for WeWeb SPAs on public-facing pages. Any app that depends on organic search traffic has a structural blocker that WeWeb cannot resolve in 2026.
The 'code export' misconception
WeWeb's code export produces a compiled Vue.js deploy artifact. WeWeb's own documentation states: 'The code is structured by a machine for a machine and is not organized like a human developer would organize it… not feasible if you're planning to… maintain it independently outside the platform.' Teams expecting editable, human-readable source are surprised by this on first export.
Plugin breakage on self-hosted export
Plugins that route through WeWeb microservices — including Airtable, Stripe, and WeWeb Auth — break in self-hosted exports. If these plugins are central to the app, the compiled export is not a functional standalone artifact.
Per-seat pricing escalation
WeWeb's April 2026 pricing overhaul separated Workspace and Site plans; total cost of ownership (seat plan + site plan + backend) grows faster than expected for teams scaling beyond 3–5 seats. Teams do the math and find a flat infrastructure cost more predictable.
Backend standardization
Many teams assembled WeWeb frontend + Supabase or Xano backend over time. When they want a single, owned stack (Next.js + Supabase with Server Actions), the WeWeb frontend layer becomes the odd piece out.
What can you actually take with you?
WeWeb's data portability is good if you use an external backend — but the code export is a compiled artifact, not maintainable source. WeWeb itself is honest about this in its documentation.
| Asset | Can you export it? | How | Notes |
|---|---|---|---|
| Data | Yes | If using external backends (Supabase, Xano, Airtable), data lives there — export from the source directly via standard Postgres dump, CSV, or API. WeWeb Tables data is a managed Postgres; export via pg_dump before any account or plan changes. | WeWeb itself is not the data store for external backends. WeWeb Tables adds a managed Postgres that must be exported separately — no self-serve backup UI is documented. |
| Code | Partial | WeWeb exports a compiled Vue.js SPA (ZIP of built files for Vercel/Netlify/Cloudflare deploy) — requires Essential plan or above (annual billing). | WeWeb docs: 'The code is structured by a machine for a machine… not feasible if you're planning to… maintain it independently outside the platform.' This is a deploy artifact, not editable source. You remain dependent on the WeWeb editor for any UI changes. |
| Design/UI | Partial | The compiled export contains all rendered UI as machine-generated HTML/CSS/JS. Use it as a visual reference artifact alongside WeWeb editor screenshots. | Not human-maintainable. Any design change after export requires going back into the WeWeb editor and re-exporting. |
| Logic/Workflows | Partial | Visual logic is compiled into the SPA export. WeWeb Tables backend workflows are API-accessible. | The visual workflow layer is WeWeb-editor-only; there is no separate export of workflow definitions. Logic must be reconstructed in TypeScript during migration. |
| Users & Auth | Partial | If using Supabase or Xano for auth, credentials live in your backend — export from there. WeWeb Auth (microservice-dependent) does not survive self-hosted export. | WeWeb Auth users must re-register after migration; the microservice dependency breaks on export. Password hash export for WeWeb-managed auth is not documented. Plan a magic-link re-registration campaign. |
| WeWeb Tables (Postgres) | Yes | Run pg_dump against the managed Postgres instance before initiating migration or making any plan changes. | No self-serve backup UI is documented as of 2026. This is the highest-risk data asset — export it first before any other migration step. |
Swipe the table sideways to see the full breakdown.
Where each piece moves in code
WeWeb's Vue.js SPA maps to a Next.js App Router (React) project with Supabase — a full paradigm shift from client-rendered SPA to SSR, not a line-by-line port.
a WeWeb
WeWeb visual pages and components
In code
Next.js App Router pages and React components
Vue → React paradigm shift; no direct porting path from compiled export; use WeWeb editor screenshots and live app as UX spec
a WeWeb
WeWeb SPA client-side routing
In code
Next.js file-system routing with Server Components and SSR
The single biggest gain from migration — public pages become indexable, Lighthouse scores recover dramatically
a WeWeb
WeWeb + Supabase backend
In code
Keep Supabase as-is; reconnect from Next.js (minimal data migration)
If already on Supabase, the backend layer needs minimal work — reconnect via Supabase JS SDK in Server Components
a WeWeb
WeWeb + Xano backend
In code
Keep Xano as-is or migrate Xano logic to Next.js API Routes/Server Actions
Xano REST endpoints can be called from Next.js Server Actions; full Xano migration is optional and independent
a WeWeb
WeWeb Tables (managed Postgres)
In code
Supabase PostgreSQL (pg_dump restore into Supabase)
Most direct migration path — dump the managed Postgres, restore into a new Supabase project
a WeWeb
WeWeb variables and state
In code
React useState / Zustand / TanStack Query
Simple local state = useState; cross-component = Zustand; server state = TanStack Query; map to complexity of each WeWeb variable
a WeWeb
WeWeb workflows and conditions
In code
TypeScript functions in Server Actions or API Routes
Reconstruct from WeWeb editor screenshots; business logic maps cleanly to typed TypeScript functions
a WeWeb
WeWeb Auth (microservice-dependent)
In code
Supabase Auth with email/password, magic links, or OAuth
Complete replacement; forced re-registration for all WeWeb Auth users; export user email list before migration
The migration roadmap
This migration is a Vue-to-React frontend rewrite with a backend connection update — not a code port. The compiled WeWeb export is used as a visual reference, not as a starting point for the codebase.
Snapshot and export
Week 1- Run pg_dump on WeWeb Tables managed Postgres immediately — this is the highest-risk data artifact
- Export all external backend data (Supabase, Xano, Airtable) as a pre-migration snapshot
- Export the WeWeb compiled ZIP (Essential plan+ required) — keep as visual/UX reference only
- Screenshot all WeWeb pages, component states, and workflow logic in the visual editor
- List all WeWeb plugins and identify which route through WeWeb microservices
Watch out: Do not begin any other phase until the WeWeb Tables Postgres dump is confirmed complete and restorable.
Architecture and design spec
Weeks 1–2- Recreate the WeWeb app's page structure and component hierarchy in a design doc or Figma
- Define the Next.js routing structure to match WeWeb pages
- Decide on state management approach (Zustand, TanStack Query) based on WeWeb variable audit
- Identify all plugins to replace and confirm replacement SDKs (Stripe JS, Airtable API, Supabase JS)
- Set SEO baseline — WeWeb SPA likely has zero indexed pages; document current GSC state
Frontend rebuild (React/Next.js)
Weeks 2–8- Scaffold Next.js App Router project with TypeScript and Tailwind CSS
- Rebuild pages and components using WeWeb editor screenshots and live app as UX reference
- Wire Server Components to existing Supabase/Xano backend (minimal changes on backend side)
- Implement SEO fundamentals: metadata API, sitemap.xml, structured data — WeWeb SPA had none of these
- Rebuild WeWeb microservice plugin integrations using official SDKs (Stripe, Airtable) via API Routes
Auth migration and user re-onboarding
Weeks 6–10- Set up Supabase Auth with the same auth methods WeWeb used (email/password, OAuth)
- Export user email list from existing auth provider before cutover
- Build magic-link re-registration flow for WeWeb Auth users
- Plan re-registration email campaign with clear communication and migration deadline
Watch out: WeWeb Auth users cannot be migrated with passwords — all must re-register. Give users at least 2 weeks' notice and multiple reminder emails.
Cutover and SEO launch
Weeks 10–12- Deploy Next.js app to Vercel with custom domain; set up redirects for any changed URL paths
- Submit updated sitemap to Google Search Console immediately on launch
- Monitor GSC for indexing progress — server-rendered pages should begin indexing within days
- Run Lighthouse audit on the new Next.js app to confirm mobile score improvement
- Send re-registration campaign to all former WeWeb Auth users
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 + significant time
4–8 months part-time
Fits
Technical founders with Vue or React experience who can manage a full frontend rewrite alongside running the product. Best for smaller apps (under 10 WeWeb pages) with a Supabase or Xano backend already in place.
Risks
Vue-to-React is not a mechanical translation — SPA-to-SSR data-fetching patterns require clear understanding of Next.js Server Components. The SEO setup (metadata API, sitemap, structured data) is additional scope often underestimated. WeWeb Tables Postgres dump must be handled correctly before any account lapse.
Freelancer
$4K–$10K
6–12 weeks
Fits
Apps with under 15 WeWeb pages, a single external backend (Supabase or Xano already in place), and no complex microservice plugin dependencies. Works well when the WeWeb visual design can be recreated in Tailwind without a Figma-first design phase.
Risks
Scope creep on the Vue → React rewrite is the main risk — frontend work almost always takes longer than estimated. Verify the freelancer has Next.js App Router (not Pages Router) experience and understands ISR/SSR patterns.
Agency (RapidDev)
Done-for-you$13K–$25K fixed
6–12 weeks
Fits
Production apps with multiple WeWeb pages, WeWeb microservice plugin dependencies (Stripe, WeWeb Auth), WeWeb Tables data, or SEO as a primary requirement. Fixed price covers discovery, data extraction, full frontend rebuild, backend reconnection, auth migration, SEO setup, and cutover.
Risks
Minimal — fixed price includes a free scoping call to confirm scope before any commitment. RapidDev has handled the Vue-to-React rewrite and WeWeb plugin replacement pattern across multiple clients.
The real risks — and how to defuse them
The 'code export' false expectation
Mitigation: Set expectations early using WeWeb's own documentation quote: the export is 'structured by a machine for a machine… not feasible to maintain independently outside the platform.' Budget the frontend as a full rebuild from the WeWeb editor UI — not a port of the compiled export.
Vue → React paradigm shift
Mitigation: WeWeb is Vue.js; Next.js is React. There is no direct porting path from the compiled artifact. Budget the frontend as a ground-up React rebuild using WeWeb screenshots and the live app as the UX spec. Plan at minimum 2–3 sprints for the frontend work alone.
WeWeb plugin breakage
Mitigation: Identify all plugins in use before migration and flag which ones route through WeWeb microservices (Airtable connector, Stripe connector, WeWeb Auth). These break in self-hosted export and must be replaced with direct SDK integrations (Stripe JS, Airtable API, Supabase JS) via Next.js API Routes.
WeWeb Auth user loss
Mitigation: WeWeb Auth is microservice-dependent and breaks on export. Export the user email list before migration begins. Plan a magic-link re-registration campaign to Supabase Auth and give users a minimum 2-week notice window.
WeWeb Tables data loss
Mitigation: WeWeb Tables is a managed Postgres with no documented self-serve backup UI. Run pg_dump as the very first migration step, before any plan changes or account modifications. Verify the dump is restorable into a new Supabase project before proceeding.
SEO starting from zero
Mitigation: WeWeb SPAs are client-rendered; organic search pages are likely not indexed. Document the current GSC baseline (probably zero) before migration so the Next.js SSR launch shows a clear improvement signal. Submit the new sitemap immediately on launch and monitor GSC weekly.
Should you actually migrate?
Migrating is a real project. Sometimes staying is the right call — here is the honest split.
Stay if
- Your app is an authenticated dashboard or internal tool where SEO is irrelevant — WeWeb's Vue SPA model is well-suited for these use cases and the visual editor accelerates iteration
- Your dev team is comfortable with Vue.js and the 'export as deploy artifact to Vercel/Netlify' deployment model fits your workflow — WeWeb is honest that this is the expected exit path
- WeWeb AI and the visual editor are accelerating feature development faster than a custom stack would; stay until a specific hard blocker (SEO, code ownership, plugin independence) surfaces
- You have not yet hit the SEO wall or plugin ceiling — WeWeb is a healthy platform with active engineering; there is no urgency to migrate before you need to
Migrate if
- Organic search (SEO) matters for your app — WeWeb is a client-rendered SPA and SSR is explicitly off the 2026 roadmap; this is a structural constraint, not a fixable configuration
- You exported the WeWeb app and discovered the code is not maintainable outside the editor — this is the platform's documented behavior; migrate when you need to own the codebase
- WeWeb microservice plugins (Stripe connector, WeWeb Auth, Airtable connector) are central to your app and you want a self-hostable, independent stack not tied to WeWeb's microservice infrastructure
- Your team wants a single, standard stack (Next.js + Supabase + TypeScript) rather than WeWeb front-end assembled with a separate Supabase or Xano backend
Our honest verdict
WeWeb is the most honest exporter in its category — it explicitly documents that the code export is a deploy artifact, not maintainable source. Migrate when SSR/SEO, true code ownership, or plugin independence becomes a hard requirement. The platform is healthy and actively developing; this is a capabilities migration, not a rescue.
Do this today: pre-migration checklist
Whatever path you choose, protect yourself first. Work through this before you touch a line of code.
Run pg_dump on WeWeb Tables managed Postgres immediately
WeWeb Tables is the highest-risk data asset — no documented self-serve backup, and data is lost if the account lapses before export
Export all external backend data (Supabase, Xano, Airtable) as a pre-migration snapshot
Confirms your data baseline and creates a rollback point before any migration steps touch the live backend
Export the WeWeb compiled ZIP (Essential plan+ required)
Not usable as a code base, but invaluable as a visual/UX reference artifact alongside editor screenshots during the React rebuild
Screenshot all WeWeb pages, component states, and workflow logic in the editor
The editor view is your migration specification — once the account changes, this reference is gone
List all WeWeb plugins and mark which ones route through WeWeb microservices
Microservice-dependent plugins (WeWeb Auth, Airtable connector, Stripe connector) break on export — they must be replaced with direct SDK integrations before cutover
Export the user email list from your auth provider
WeWeb Auth users cannot migrate credentials — you need the email list for the re-registration campaign at cutover
Document your current GSC SEO baseline
WeWeb SPA pages are likely not indexed; confirming zero baseline before migration shows clear pre/post improvement when Next.js SSR launches
Frequently asked questions
Can I export my WeWeb app code?
Yes, WeWeb exports a compiled Vue.js SPA (ZIP file) on the Essential plan or above. However, WeWeb's own documentation states the exported code is 'structured by a machine for a machine and is not organized like a human developer would organize it… not feasible if you're planning to maintain it independently outside the platform.' It is a deploy artifact for Vercel/Netlify — not editable source you can hand to a developer and maintain independently.
How long does migrating from WeWeb to code take?
Plan 6–12 weeks for a production migration. The frontend is a full Vue-to-React rewrite (not a port), which is the largest time driver. If your external backend (Supabase or Xano) is already in place, the backend work is minimal — primarily reconnecting to Next.js. Apps with WeWeb Tables data, multiple plugins, and WeWeb Auth users land in the 10–12 week range; simpler apps with external backends can move faster.
What happens to my users and their passwords after migration?
If your users authenticate through Supabase or Xano, their accounts and password hashes live in your backend and migrate cleanly. If users authenticate through WeWeb Auth (the built-in microservice-dependent auth), those credentials are tied to WeWeb's infrastructure and break on export. WeWeb Auth users will need to re-register — plan a magic-link invitation campaign and give users at least 2 weeks' notice before cutover.
Is WeWeb shutting down?
No. WeWeb is active, well-funded, and actively developing as of 2026 — it launched WeWeb Tables in April 2026 and has an AI feature in beta. There are no shutdown signals. The reason to migrate is capabilities (SSR, code ownership, plugin independence), not platform survival.
Does WeWeb support SSR or server-side rendering?
No. WeWeb is a client-rendered Vue.js SPA. The CEO explicitly confirmed in the 2026 roadmap post that SSR will not be part of the 2026 roadmap (weweb.io/blog/our-2026-roadmap). If organic SEO matters for your app, this is a structural constraint that cannot be resolved within WeWeb.
What happens to my WeWeb Tables data when I migrate?
WeWeb Tables uses a managed Postgres database. Export your data using pg_dump before initiating any migration steps or making account/plan changes. There is no documented self-serve backup UI in WeWeb's interface as of 2026, which makes the pg_dump step the highest-priority action at the start of any migration. Once you have the dump, restore it into a new Supabase PostgreSQL instance.
Can I use the WeWeb exported ZIP as a starting point for my new codebase?
No — and WeWeb explicitly says so in its documentation. The compiled export is machine-generated, minified, and not organized for human editing. Use it as a visual reference (open in browser to see how the app looks) alongside your WeWeb editor screenshots. Your actual codebase starts as a new Next.js project that you build to match the WeWeb app's UX.
How much does it cost to migrate a WeWeb project, and can RapidDev help?
DIY with AI tools is possible for small apps (under 10 pages, simple external backend): budget significant part-time hours over 4–8 months. A freelancer typically charges $4K–$10K for mid-size apps. RapidDev offers fixed-price migrations from $13K–$25K covering data extraction, full Next.js frontend rebuild, backend reconnection, auth migration, SEO setup, and cutover — with a free scoping call to confirm scope before any commitment.
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.