Why we have moved away from weweb

Ask us anything
1

I am the tech lead in my company and were asked to investigate and prototype some no-code/low-code builders. We have had a lot of initially positive experience with weweb. Unfortunately after spending quite some time on it we have hit many roadblockers and also started to doubt the direction weweb is heading

Weweb is an amazing tool for building MVPs, but is nowhere close to support real production webapps that require proper dev workflows.

I just want to share our experience here so it might help to improve the tool in the future

  1. Wewebs Export Functionality - The promise of exporting your project and hosting it in your own environment is awesome. However the exported code is basically a non-readable mess. Weweb says this is on purpose so it runs smoothly. We as a company have same obligations to do proper QA on everything that gets pushed to production, this also includes security scans on a source code level. Its basically impossible to run and address issues that were found by such scans. For compliance reasons why could not move any of the prototypes we have built into production
  2. Wewebs poor Editor performance - There has been endless experiences where the editor takes ages to load, doesnt load at all or just gets stuck. When our POC was small this did not happen, however as the application got bigger, this became a daily concurrence. For a business its just not feasible that devs are just locked out of their “IDE” for random reasons
  3. Missing SOC2 or ISO certification - I think i dont need to go into much detail here. Its a big no-go
  4. Buggy Plugins and no options to fix it - Whilst all plugins seem very useful at first, most of them are just incomplete (in terms of missing crucial functionality) and some are even bugged. We have raised some of those issues before with documented screenshots and absolutely no action was taken. Big dealbreaker here is weweb does not allow to introduce custom plugins, only for “selected partners”. Some of the bugs could be fixed within 10 minutes but without an option to use our own fixed plugin, that doesnt matter.
  5. No version branching - This was already raised by the community in 2023(!!!) and still gets kicked down the road, release after release. Again big no-go
  6. Roadmap Planning - The current roadmap planning just seems odd. There seems to be a big focus on AI driven development + a backend builder(???). We initially focused on weweb because it gave us full frontend component control, if we wanted to use AI, we would use any other the many other well-built, bigger funded apps. The backend builder is in my opinion is just something nobody has asked for. I think weweb would profit from actually listening to their community more. There is still no SSR support, no branching, a poor and underdeveloped marketplace, no styling framework support (tailwind, shadn, …)
  7. Weweb’s company outlook - Compared to other no-code/low-code builder the development and improvements of weweb are incredibly slow. Upon checking we see that their are only 20 employees of whom not all of them are technical. Also overall funding seems very low compared to other tools. All of this makes us concerned that even if we would decide to use weweb for a production app, and weweb runs out of money, we would get handed over poor source code without any IDE that previously many devs would have worked with, ultimately forcing businesses to potentially needing to rebuild the entire app

We still believe WeWeb is a great platform with a lot of potential. However, users should be aware of its current limitations, anything beyond the MVP stage requires careful consideration to avoid unpleasant surprises later on. The community clearly wants to help WeWeb grow but with no support for custom plugins and an inactive marketplace, that collaboration is currently very limited.

11 Likes
2

Hi Simples :waving_hand:

Thank you so much for taking the time to share your candid feedback and experiences.

While I won’t be able to address your questions directly, I want you to know that your feedback matters to us and will be shared with the right people.

Thank you again for contributing to the conversation and helping us improve.

1 Like
3

Hi @Agustin_Carozo ,

What happened since your last response - saying you’re unable to answer?

I sure hope that Weweb has plans on how to address (some or all) of these points?

Weweb has had a couple of months to come up with a response. Not addressing this seems like an admission of these concerns, which I hope is a misunderstanding.

1 Like
4

Interesting.

what solution have you chosen @simples ? Code ?

5

Yeah the plugin issue is pretty bad - There’s such a HUGE difference between the amount of plugins in Bubble vs WeWeb

Still preferring WeWeb.

1 Like
6

Yeah @Toby007 but that’s also we don’t need those plugins in weweb

1 Like
7

Hi,

I completely agree that I don’t really understand the direction WeWeb is heading in. It seems to be positioning itself as a “lovable” alternative but why? That was never the reason people used WeWeb in the first place, especially given the current state of WeWeb AI.

The same applies to the WeWeb backend. I understand that relying on a third-party database isn’t ideal from WeWeb’s perspective, but WeWeb simply doesn’t have anywhere near the same resources. What would realistically make me replace Supabase with the WeWeb backend, when Supabase offers far more features and possibilities?

Not to mention the ChatGPT apps and other AI “features,” which don’t feel particularly aligned with the core value proposition.

I understand that a community shouldn’t dictate a product’s direction, but it does feel like there’s a real disconnect between why users are choosing WeWeb today and where the product seems to be heading.

That said, I’m still very happy of using WeWeb.

1 Like
8

We basically ditched weweb alltogether. Its just not feasible for any serious business and I personally got a lot of heat internally for wasting too much time on it.

Our current workflow now looks like this

  • UX/UI Designers create a figma design
  • We utilize claude code with some additional MCPs to migrate this into the frontend of our tech stack
  • Any ad-hoc changes to the UI can be done with high quality afterwards via some prompts
  • Backend is developed manually with AI assistance by claude code
  • Before anything moves into any other environment than testing, we have a seperate QA team + DAST scanners

A lot has happened in the AI space and I personally dont see any future for weweb anymore. AI assistants have gotten so much more reliable and code quality has improved dramatically. Obviously like this we also have FULL FLEXIBILITY and are not locked into some buggy/incomplete infrastructure. Nowadays things like claude code are also extremely cheap (compared to wewebs odd AI tokens that give you a substandard experience)

As I said, I am not using weweb anymore, just received the email notifications for this thread here. So it might be possible weweb did a 360 and acted on community feedback

9

my point is more the ease/approach to build things = aka atm we need better examples and access to proper plugin dev.

T

10

Would you mind sharing your tech stack that replaces what you built in WeWeb? What framework is Claude coding in? Still using a DB like Supabase or Xano?

One of my projects I recently moved to self+hosting because I need SOC2, but want to start planning a full exit.

11

The beauty is that Claude Code works with any framework, so there is no limitation.

In terms of tech stack:

  • Frontend React
  • Backend AWS Api Gateway with Lambda Endpoints
  • Database on RDS

If you are aiming for SOC2 compliance, having your setup in AWS helps a lot and makes audits a breeze

1 Like
12

Hi there :waving_hand:

@thijs , we didn’t jump in right away because we felt @simples was mainly sharing his experience (which we took on board) rather than asking for an official WeWeb response, but we’re happy to add some additional context.

On code export & compliance
It’s true that we don’t have SOC 2 or ISO certification yet, and that exported WeWeb code isn’t meant to be manually edited, which can be a blocker for some compliance models. That said, WeWeb is used in production by large banks, insurance companies, and auditing firms that successfully run security scans and integrate exports into their CI/CD pipelines. So while it might not fit every organization, it has proven viable in highly regulated environments.

On editor performance
There is currently a known performance issue that can affect larger projects, with a (not ideal but effective) workaround: regularly clearing workflow logs. Beyond that, most performance issues we’ve seen have been resolved with guidance on building apps in a more scalable way, often with only small changes to project structure or workflows.

For anyone who runs into performance problems, we strongly encourage opening a support ticket and providing as much detail as possible, both when creating the ticket and when the team follows up. Performance issues can be particularly hard to reproduce without full context, and detailed information really helps us diagnose and address them faster.

On plugins & extensibility
We fully understand the frustration around not being able to create or extend plugins yet. It’s something we wish we could have made possible already, but simply couldn’t make happen given how quickly the tool is evolving. Opening plugin development at this stage would mean slowing down the rest of the platform.

That said, our upcoming fullstack experience is specifically aimed at helping us ship, improve, and maintain more integrations faster (e.g. Resend, Cloudinary, Google Sheets). Even today, integrations like Figma, Xano, and Supabase are among the most advanced in the no-code / “vibe coding” space.

On branching
Branching is a fair ask and something we 100% agree would be valuable. We explored it in 2024, but given the technical complexity of supporting it in a visual builder, and the fact that larger teams had found workable alternatives, we couldn’t prioritize it in 2025. It’s something we will work on as soon as we can, but we don’t have a clear timeline yet.

On roadmap & company direction
Again, it’s completely fair to disagree with roadmap decisions. We gather feedback from the community, in-depth user interviews and market research to guide our decisions but, of course, our choices won’t align with everyone’s expectations.

On viability
WeWeb has been profitable for several years. A smaller team doesn’t necessarily mean instability :slightly_smiling_face: We were slower than we’d have liked in 2025 due to major core changes, but we do plan to grow the team further and accelerate momentum in 2026.

All that said, we fully agree with the broader takeaway: WeWeb isn’t the right fit for every team or production setup, and it’s important to evaluate those constraints early. We try to be as open and transparent as possible through founder-led community updates and live Q&As.

You can watch the latest AMA here if you’d like to learn more about our vision for 2026:

3 Likes
13

they did not

1 Like
14

Hi @Agustin_Carozo ,

Your response helps me to put things into perspective, thanks.

I found what I was looking for in the closing comments of the video - where Weweb says its visual builder (of elements) is core and AI is supportive/subordinate to that. The only upside that I hear for AI is speed (for initial builds), but I need reliability/thorough understanding (for long term maintenance).

2 Likes
15

Yeah, that’s super important. We don’t plan to change that at all. Our focus has always been to empower builders who see value in the visual development side of things, while providing an environment that’s powerful, super flexible, and fast to build in.

AI is critical to maintain our speed promise as user behavior changes but it will always be in the context of visual development for us. It’s what sets us apart from tools like Lovable, Cursor, Claude Code, etc.

Same here. I trust (and value) AI for initial builds but I need to understand what it built and be able to edit it without writing code and, in my opinion, WeWeb has one of the best, most flexible and powerful visual editors out there to do just that.

I’m really excited for 2026. Whether people use it with Xano, Supabase, or WeWeb tables, I think the new WeWeb Unify experience is going to take visual development to a whole new level. I mean the ease of use to create secure table views is insane :grinning_face_with_smiling_eyes:

It won’t be for everyone. Developer teams will likely continue to favor AI-first tools because they’re faster for generating and editing code, and those teams are comfortable owning DevOps. But for non-coders and hybrid teams who value both speed and understanding, I think it’ll be a game-changer :slight_smile:

5 Likes
16

I think it’s important to offer a counterpoint to the conversation above. I’m Zakk, and my team and I have spent the last six months building a two-sided Transportation Management System (TMS) entirely in WeWeb. While WeWeb isn’t perfect, I genuinely believe it’s the only solution of its kind in the no-code/low-code space.

When I started this project, I was using Bubble as a solo developer building a tool for my own trucking company. It worked adequately for internal use, but when I decided to take the product to market, I quickly realized the platform’s severe limitations. As we expanded the team and continued development, we hit roadblock after roadblock, constraints that ultimately forced us to abandon our work on Bubble entirely.

We faced a critical decision: pivot to a low-code solution or commit to full-code development. That’s when we discovered WeWeb, and we haven’t looked back since.

Does WeWeb have limitations? Absolutely. Every platform and every programming language has its own quirks and constraints. For example, I still haven’t found a way to trigger component actions via JavaScript, something that would streamline certain workflows. But these are the kinds of nuances you encounter with any development environment, whether it’s React, Vue, or traditional backend frameworks.

The key difference is how you architect around these limitations.

We use WeWeb exclusively as our front-end layer, with some lightweight workflow automation. Everything else (our entire business logic, data processing, and complex operations) runs through APIs connected to our custom-built backend infrastructure. This architectural decision gives us the best of both worlds: WeWeb’s rapid UI development capabilities combined with the flexibility and control of a custom backend.

We deliberately avoid WeWeb’s built-in AI features and have no plans to use the new WeWeb Tables. That’s not a criticism of those features. They’re likely excellent for smaller applications, internal tools, or personal projects. Many WeWeb users are building solutions that will never face public scrutiny: internal business tools, family management apps, personal productivity systems. For those use cases, the integrated features make perfect sense.

As for the plugin comment, our plugin usage is intentionally minimal. We rely on just two: the REST API plugin and Supabase. Everything else is custom-coded within WeWeb itself. This approach is a critical feature of our system, not a limitation. It gives us complete visibility into and control over how our application behaves.

Yes, WeWeb’s core system isn’t fully controllable, but the fact that they expose as much as they do is remarkable. Most no-code platforms are complete black boxes. WeWeb’s transparency allows us to understand exactly what’s happening under the hood, debug effectively, and build with confidence.

Could we have built this in pure code? Of course. But the development velocity we’ve achieved with WeWeb, combined with the ability to integrate our own backend systems, has allowed us to iterate and ship features at a pace that would have been impossible with traditional development, especially with our team size and resources.

WeWeb isn’t trying to be everything to everyone. It’s a front-end builder that excels when used as part of a thoughtful, well-architected system. For teams willing to invest in proper backend infrastructure and treat WeWeb as what it is (a powerful UI layer), it’s an incredibly capable platform for building production-grade applications.

WeWeb has enabled us to build a complex, market-ready TMS that handles real-world logistics operations. That’s not something I could say about our previous platforms. Every tool has limitations; the question is whether those limitations prevent you from shipping quality software. In our experience, they don’t.​​​​​​​​​​​​​​​​

12 Likes
17

@ZakkeryBock that’s good to being back some valeance in this discussion

how many simultaneous weweb developers were on the project ?

18

I am the primary weweb developer, most of the team works on backend. However when I started the project I, being solo, was able to build an awesome foundation. Takes time but utilizing Chromes console to learn how weweb works was an absolute lifesaver.

1 Like
19

I share the same sentiments, I am quite unhappy with Weweb recently cos I think they’ve let bugs creep in to the editor and for big projects those bugs go from trivial to super annoying real quick, but as someone who has now built a production-used Laboratory Information Management System with realtime machine integration as a solo fullstack dev all off a weweb frontend and careful backend infra, I 100% agree with this sentiment. I built this idea in Bubble, Toddle.dev, Flutterflow before finally doing it in Weweb, and NONE of the others came close to being as robust as what weweb offered, NONE. So while I won’t shield weweb from valid criticism, I want to point out clearly for other users that you can build anything in weweb and it will be fast, and reliable, provided you take care of your backend, and build the frontend with discipline ( a few rules I came to learn eventually. Rule 1: reuse everything as MUCH as possible - sections, components, pages etc, rule 2: DON’T USE weweb’s loop actions EVER, just don’t I can’t even begin to explain, just try some other logic unless you absolutely have to loop. rule 3: do the logic backend, always, it’s tempting to do logic in weweb since “it’s just right there“, DON’T, let your weweb workflows be as simple and straightforward as possible and move the complex logic to the backend either as a postgres function, edge function or plain old coded API, rule 4: on pageload actions are your enemy, I am serious it is always better to not have any and run the workflows onmounted than on page load, the performance difference is not trivial at all). Just writing this to buttress Zakk’s point. I hope someone finds it useful.

8 Likes