Hey everyone,
I’m planning to move my app from Bubble + Xano stack to WeWeb + Xano stack and am pretty convinced about weweb right now. I still want to know any limitations or lack of features that WeWeb has to evaluate this further.
Lack of test version (preview mode isn’t test version), branches etc. is an example but I want to know all such important limitations to make a decision. Thank you!
You can pay to get staging enviroment, which is sort of branching, it’s more of a trunk style versioning. But yeah 100 bucks for branching, is kinda meh, but hey, it’s definitely worth it. Anyway, if you’re coming from bubble, I think there will be nothing stopping you to go 10x on WeWeb 
I do see tangible benefits of switching from bubble but want to understand tangible limitations that I might face as well.
Also branching and test version are very different to be honest. You can create multiple branches for each feature, but you don’t create multiple dev environments generally
Well, it is what it is, the thing I described is the closest to versioning
Thanks for setting up this thread and for the answers shared.
…I’m also interested in understanding the limits of WeWeb in terms of what it can and cannot do.
Are there any specific use cases that would struggle in WeWeb?
Has anyone wanted to build something but couldn’t using WeWeb?
Everything is possible if you want it bad enough 
Thanks @Broberto
There must be a limit somewhere, no? Are there any areas that are hard(er) to do in WeWeb vs other platforms?
…I have been looking at Plasmic which appears to provide more options to use code in it’s interface. Does that make it more powerful in terms of customisation options?
You can use your own code anywhere in weweb as well. The copilot/built in AI also are really helpfull for making JS, and helps you achieve what you want even if it is not available in nocode.
I’ve not met any limitations to what I can do yet, but I believe that previous code experience with CSS/HTML/JS and also sql backends is really helpfull to understand weweb and what it is/what it can do and how it works behind the scenes.
Thanks @thomlov !
That’s good to hear there are plenty options to add in code to WeWeb as well! What is the advantage of using WeWeb over Plasmic? They seem fairly similar aside from Plasmic being a bit more technical.
I’m still slightly dubious that WeWeb can do everything… It almost seems too good to be true!! haha
Could WeWeb handle a messaging component, similar to facebook messenger where you can message groups of people?
Does WeWeb handle roles based permission systems well? e.g. Could you control what users could have the ability to edit a document based on them being a specific role within a specific organisation within the database?
…is this more of a limitation depending on what server actions you create rather than a WeWeb constraint?
Yes to all of those- I do messaging and such in WeWeb! You just also need good foundational knowledge of how to structure your backend.
I don’t have any experience with plasmic.
Messaging component is easy using supabase realtime, built in.
Multi tenant role based system I have in my weweb app. Just as you describe. Broberto also sells a pre-built solution for supabase and role based access. His solution is cheap compared to the work you will do to make the funtionality yourself.
And yea, weweb provides frontend. Alot of functionality will demand backend work as well. I use supabase and really happy with that, but it is not nocode. If you have previous SQL experience thats a big plus if you choose supabase. But here also, AI built into supabase can be a big help. You will need to learn RLS, postgres functions and such.
Xano is a nocode backend built into weweb.
This is true 100% 
It saves like a ton of time and it’s based on the most opinionated approach around, I just extended it a little.
100% this, but ChatGPT 4o / Claude Sonnet can do wonders. Even I use it to save time to write repetitive stuff.
People who use my template (me on my partner’s projects included) find it very simple, as there are basically a lot of pre-made functions. Still, you should understand how the RLS works, at least the basics.
@_hugo if you have something specific in mind, or a project lined up, I found that people benefit a lot from having a 1:1 with me about their projects/issues, before starting to build. Whether it was to validate, choose the right stack (WeWeb with Supabase or Xano etc.), or just learn something new, I heard many times, that the few euros they spent on the hour long meeting with me saved them a lot more hours/money/stress later on.
With respect, this question is backwards. It’s not “what can weweb do and not do?” It’s “what am I trying to create and what tools and approaches let me do that with the lowest expense/effort/time-to-market?”
The answer to that latter question starts with your problem to be solved, rather than a generic evaluation of tools. The Papert framework of “floors and ceilings” for evaluating creative tools is useful in the context of both the job to be done and the person doing the job.
At State Change, we call this framework the Shopper’s Mindset. (I also made a youtube about it.)
This is important because if you start with what you want to do, you can pick more powerful tools that are easier to use in your context. For example, someone who can make JS dance (either because of internal knowledge or making ChatGPT/Claude dance) will be good with a generic javascript escape hatch in a tool, while one who is more uncomfortable with that will want more handled in the visual building environment. And someone who is not adept today but adept tomorrow will find the right tool for them changes as they gain skills.
And the job to be done matters. What features does your envisioned product require to deliver value outcomes to your customers? And then how do the tools in consideration enable those features, and with what skill prerequisites?
When you assemble these insights - product qualities, your own skills, and the job to be done - in each others’ contexts, you are able to figure out which 10% of considerations really matter, and this allows you to decide more quickly and build 10x faster as you drop the 90% that doesn’t drive your outcomes.