WorkBook a call

Migration guide · No-code app builders

What founders get wrong about leaving WeWeb

Leaving WeWeb is usually smaller than founders fear and different from what they expect. The exported Vue build isn't source code you can maintain, but your Supabase or Xano backend and its data can stay put while the frontend is rebuilt against it, typically in four to eight weeks.

By Max Winter-LeinweberUpdated 4 min read

The exported Vue code means I own the app

Not in the way that matters. WeWeb's code export, which is tied to a paid plan, gives you a built Vue.js single page app: compiled, minified HTML, CSS and JavaScript that runs on any static host. It's the output of WeWeb's build, not the readable source a developer would work in.

Self-hosting it removes the hosting dependency, not the editor dependency. To change anything, you still open WeWeb and export again, and any hand edits to the bundle vanish the next time someone does. Two more details catch people out: some plugins route through WeWeb's own services and may stop working in a self-hosted copy, and files uploaded to WeWeb's CDN still live there.

The export is still worth having. Keep it as a fallback and as a working reference while the real codebase is built.

Leaving means rebuilding everything

Usually only the frontend gets rebuilt. WeWeb is a frontend sitting on top of a backend you connected, most often Supabase or Xano, so the data, users and much of the logic are already outside it.

With Supabase, your data, auth and storage are in a Postgres project you can connect a new app to directly; just confirm it sits in your own account. With Xano, a new frontend can call the same endpoints. The new app is built screen by screen against that same backend, in a framework your team can maintain such as Next.js or Nuxt, while the WeWeb version keeps serving users until you switch the domain.

If you used WeWeb's own newer backend features, such as WeWeb Tables and backend workflows, check the current export options before you plan around them, because they're younger than the frontend export.

If users only see their own data, the app is secure

The interface proves nothing about security. In many WeWeb and Supabase apps the browser queries the database directly, so the only thing keeping customers apart is row level security on every table. With Xano, it's whether each endpoint checks who's calling it.

Hiding a button or filtering a list in the editor protects nothing; anyone with the browser's developer tools can make the same request without the filter. Before or during the move, write and test policies or endpoint checks for every table, and move secret keys and anything that charges money onto the server.

If a list in WeWeb is filtered to the signed-in user's records but the table behind it has no policy enforcing the same rule, any user can read everyone else's records by changing a single value in the request. Fix that in the database first; it protects the WeWeb app today and the new app tomorrow.

Rebuilding the screens rebuilds the app

The screens are the easy part to see and the hard part to finish. A lot of a WeWeb app's behaviour lives in page workflows, global workflows, formulas and plugins, and none of it is visible from looking at the pages.

The classic failure is a rebuilt app that looks identical but has quietly stopped updating a record or sending an email, because that happened in a workflow nobody listed. Before rebuilding, audit every page, workflow, formula, plugin, API call and backend function, and write down what each actually does, including the edge cases users rely on. Then move business logic onto the server as you go, so it lives in one reviewed place rather than split between the frontend and the backend.

That audit also gives you something WeWeb never did: a written specification of the app. It becomes the test list for the rebuild, and the checklist you work through before switching the domain.

We should move off Xano at the same time

Rarely at the same time. Xano can export a workspace with its data and schema, and its endpoints can be read as XanoScript, but that logic only runs on Xano. Leaving means rewriting every endpoint, which is a project of its own.

Doing both at once doubles the number of things that can break on cutover day and pushes the launch back by weeks. Rebuild the frontend against Xano first, ship it, then move the data to Postgres and replace endpoints one at a time if you still want to.

Frequently asked questions

Can I export my code from WeWeb?
Yes, on a paid plan. WeWeb exports a built Vue.js app that you can host on your own servers. It's compiled output for deploying, not a source codebase meant for developers to maintain by hand, so changes still happen in the WeWeb editor.
How long does it take to move a WeWeb app to custom code?
Typically four to eight weeks, depending on the number of screens and workflows, how many user roles the app has, and whether the backend is changing as well as the frontend.
Portrait of Max Winter-Leinweber

About the author

Max Winter-Leinweber

Founder, Scryptic

Max is the founder of Scryptic and a full-stack developer with five years of experience building software for enterprise clients and startups. He builds MVPs for UK founders and takes apps made with no-code and AI builders through to production.

Ready to move your WeWeb app to production?

Walk us through what you have built on a free call. We review the app, its data and its accounts, then send a plan and a written estimate.

Book a discovery call
All 29 posts