While transferring the app built on a partner plan (free hosting) + Supabase free plan, i have a few doubts :-
When we transfer the app to the client’s workspace, what all will break/have to be rebuilt ? What i mean is that since the back end is on supabase and since that will be transferred to the client independently via transferring it to the client’s supabase organization, will that result in API end points breaking or workflows breaking or API keys getting reset, basically since the connection between weweb + Supabase was established on the developer account, when transferred to a client’s account do “some of those connections” need rebuilding due to this account transfer or is it seamlessly transferred?
Given my first doubt, is there a standard “weweb expert” way of building and transferring an app to a client? Like Build on the partner plan with free hosting + Supabase free plan v/s Build on a plan that the client will be using and handover the weweb and supabase account details once app is developed so nothing is rebuilt/transferred ? Although here how would the developer retain a copy of the app for further use with other clients ?
If you move the WeWeb project from your partner workspace to the client’s workspace and move the Supabase project into the client’s Supabase organization, things will keep working as long as the connection details stay the same (URL, project ID, database schema).
For handover, a good pattern is: build in your own workspace and Supabase during development, then before go‑live create the client’s workspace + Supabase project, migrate the DB there, transfer the WeWeb project, and finally update the Supabase keys in the client’s project.
Thank you for the clarity.
Also, in continuation to this :-
Can i keep a copy of the app in my partner account + the database schema in supabase ? Objective is to reuse the app for other clients
Once the app is live for my client, which weweb plan do they need to be on so that i can :-
2a) Keep Backups of the app and data incase something breaks
2b) Have Staging/branching for bug fixes and future upgrades so that i can fix/upgrade app without disturbing the live app and then just “push” the changes without having to manually redo them on the live app?
Thanks again @Agustin_Carozo for the wonderful prompt help! Its really getting me up to pace to start development for the new client i have. Excited to develop here!
You can keep a copy of the WeWeb app in your partner workspace and reuse it as a base for other clients, and you could also keep a copy of the Supabase schema in your own project to reuse that structure for future builds, though the exact rules might depend on how you and your client handle IP and licensing in your contract.
And about your second question, for clients, an Essential (for export/backups) or Pro (for collaboration) tier plus proper Supabase backups and a duplicated staging project is usually a solid setup for the workflow you described.
Just keep in mind that WeWeb doesn’t have branching yet, so staging changes would still need to be manually applied to the live project when you’re ready to go live.
We don’t support branching yet, but here’s what most partners do:
Duplicate the entire WeWeb project for staging. Connect it to a staging version of your backend (Supabase staging schema or a separate Xano branch), test there, then manually apply changes to the live project once approved.
If they’re using Xano, they leverage Xano’s native branching, which works great alongside WeWeb. For Supabase, using separate schemas (one for production, one for staging) is the cleanest approach.
