Greetings! Fellow WeWebbers!(if thats a thing lol)
I’ve been in the no-code arena for a year now building internal tools for clients but i also wish to build a direct consumer facing app of my own which can scale. I’ve built apps on google app sheet and Glideapps but they have limitations. I’m now looking to switch to a ‘better’ platform because up until now i haven’t found the following features :-
Scalable backend which ensures the app doesn’t slow down as data grows
Version control/Branching so that bug fixing and upgrades can be done independently without disturbing the main production branch
Predictable costing (unlike Bubble’s WU system) at scale
Automated Backups
As per my research all 7 get checked for weweb + Supabase(as backend).
Please guide/correct me if i’m wrong on the above 7 features about weweb.
Things i haven’t been able to figure on weweb :-
How do we transfer apps if we are not on the agency plan? I don’t want to wait on the support team to do it for us. Can i just handover the account details of both weweb and supabase when done with each project ? - Is that something freelancers do here?
Since hosting is via weweb and via supabase, and i don’t have a preference due to any client level constraints, is it better to go with weweb or supabase ? Which is more optimal ? For example i’m on a “pro” seat plan with “Grow” hosting plan on weweb vs supabase’s “pro” plan ?
What is the meaning of the “unlimited app sessions” & “400 GB bandwith” ? How does this translate to no. of users and rows of data ?(Assume text heavy with mild media like photos pdf etc.) ?
How many published/unpublished apps can i have on each plan ?(Apart from the agency plan)
Hi Ruak, welcome to our community
ready to become a Wewebber?
I’m glad you started doing your research and I’d love to help you organize your findings.
Let me try to answer your questions as best as I can:
For app transferring, being in the partner/agency plan is the easiest choice, but you could of course ask your clients to create an account, work on it and deliver it back after you are done.
Since WeWeb and Supabase host different pieces of your stack, you don’t really “pick one”; you use both together. WeWeb hosts and serves your front‑end (the web app UI, routing, assets, etc.), while Supabase hosts your backend services (database, auth, storage, edge functions), so a typical production app will have a WeWeb hosting plan for the frontend and a Supabase project/plan for the backend communicating via API or a plugin.
On the backend side, WeWeb doesn’t store your app data or limit your database rows – WeWeb only hosts the frontend. Your limits on rows, storage, and queries will come from Supabase (or whichever backend you plug in), while the “unlimited app sessions” and “400 GB bandwidth” numbers on our side only describe how much traffic your WeWeb‑hosted frontend can handle, not how much data you can keep in your database.
You can have unlimited unpublished apps in your WeWeb account; drafts and prototypes do not consume hosting slots. Once you publish an app or connect a custom domain to it, it needs to be attached to a hosting plan, so each live app you serve to end users will use one hosting slot/plan even though they can all talk to the same Supabase backend if you want.
Hope this helps!
PS- Now, all things considered and just to gently add one more layer to your frontend/backend confusion, we’re also about to launch our own backend, so in the near future you’ll be able to choose between using WeWeb’s backend or connecting your own like Supabase or Xano.
In any case, feel free to keep the questions coming here as you explore, happy to help you untangle the stack piece by piece.
Thank you @Agustin_Carozo for the detailed reply. I think i’m going to the Weweb way!
I’m still a little unclear on the 400 GB bandwith front end limit. Like how do i tie this/ visualize it in terms of restrictions when things scale? Like when does this limit max out(e.g. how many users/ or query etc.). Could you expand a little on this?
400 GB is the total amount of data your frontend can send to all users in a month (pages, scripts, images, etc.).
How fast you reach that limit depends mainly on:
How “heavy” your pages are in MB (lots of images/files vs a light dashboard).
How many page views your users generate per month.
For most early‑ and mid‑stage apps with reasonably optimized pages, 400 GB comfortably supports many thousands of active users, and you typically only need to think about upgrading once you reach significant scale.
Awesome! I’m loving the community support here!
Could you also explain me a little on the extra carefulness i need to implement now that i’m developing apps on a splitstack platform ? For e.g. on glideapps or bubble the platform is full stack where the front end and back end are seamlessly connected. But with weweb + Supabase, we need to set up the connections/API end points etc i think. Is there a “good practises” or “Things to know” thread here or an article somewhere that can get newbies like me upto speed so we don’t screw up something obvious specially in terms of ensuring authorisation/row level security/data ownership and other such important aspects of an app.
Thank you again for all the prompt help!
Hey @Ruak I’m super happy that you are loving the community
Now, about your question, from a high level, there are two things to keep in mind:
The frontend (WeWeb) is “just the UI” and should be treated as untrusted.
All the real security and permissions live in your backend (whether that’s Xano or Supabase).
Starting point: Xano as backend
If you’re still choosing a backend, a very good “first split‑stack” experience is Xano, because it’s fully no‑code while still powerful:
You get a visual database, business logic, and auto‑generated APIs, so you don’t have to write code to create or manage endpoints.
Auth, permissions and workflows are configured through a visual interface, which makes it easier to reason about who can do what compared to wiring everything manually.
There is a full WeWeb + Xano course , so you can literally follow step‑by‑step.
Because of this, Xano often feels closer to Glide/Bubble in terms of “mental model”, but with the flexibility of a proper backend.
If you go with Supabase
Supabase is also a great option, but there are a couple of extra concepts you need to own:
Row Level Security (RLS): you must enable RLS and write policies for each table so users can only read/update the rows they are allowed to. Without solid RLS, anyone who gets your anon key could query more data than intended.
Functions and Edge Functions: more advanced logic often lives in SQL functions or Edge Functions, and these are typically called via code (HTTP requests, client libraries, etc.). They also need to be wired carefully with auth so that they either respect RLS or intentionally bypass it using service keys where appropriate.
Key management: you have to be very disciplined about where you use the public anon key vs the service_role key, making sure secrets never end up in the frontend.
So Supabase gives you a lot of power, but it also means you’re closer to “real backend engineering” concepts (policies, roles, functions, key scopes, etc.).
General “split stack” habits to develop
Regardless of backend choice, the main checks and habits are:
Treat WeWeb as untrusted: never rely on the frontend to decide “who can see or change what”, only for UX.
Centralize rules in the backend: permissions, validation and business rules should live in Xano logic or Supabase RLS/functions, not in scattered UI conditions.
Share only what’s needed: design your APIs so they return just the fields the UI needs, and keep anything sensitive (internal flags, secrets, system notes) out of frontend responses
Also, try not to stress too much about “doing everything by the book” from day one. Best practices matter, but they make a lot more sense once you’ve built a couple of real screens, connected your backend, and felt where the pain points are.
For now, focus on getting comfortable with the WeWeb + backend flow, shipping small features, and asking questions when something feels confusing. The “proper” patterns and checklists will click naturally as you go
