Urgent Concern: Production Breaking Changes & Platform Stability

Ask us anything
1

Hi everyone,

I need to express significant concern about Weweb updates repeatedly breaking our production applications. We build our applications and, once in a working production state, we often leave them untouched. However, bugs are consistently being introduced without us making any changes to the project itself.

We’ve recently faced critical issues, like a select component update that removed scrollability and causes the selected value to sometimes vanish from the DOM, leading to downstream errors (e.g., missing IDs in database queries).

Fixing these breaks isn’t fast; it means extensive, costly manual rework throughout our applications. More importantly, simply providing workarounds isn’t sufficient when core components break like this. Often, the “fix” offered is a workaround, which doesn’t resolve the underlying issue and unfortunately causes technical debt for us down the line. As developers, we need a platform where the fundamental “basis of design” is properly maintained and reliable.

Frankly, the “low code” speed benefit is being completely cancelled out by the significant downstream costs and effort required to manage constant, unpredictable breaking changes in production. It feels like updates are pushed without adequate testing, and deprecated components shouldn’t just stop working in a way that breaks live apps.

In the past months, I’ve gone from a Weweb “die hard” pushing people to use the platform to someone warning others not to use it because of these glaring, unresolved issues. This lack of stability is now forcing us to seriously evaluate migrating our applications off Weweb entirely. For agencies and businesses running live applications, predictable stability is essential.

We need Weweb to genuinely listen to these concerns and address the root cause of this instability.

Could anyone, especially the Weweb team, shed light on:

  1. Weweb’s process for managing updates and preventing critical breaks, particularly with core components or deprecations?
  2. What strategies can we use as users running production apps to genuinely mitigate the risk of updates causing catastrophic failures, beyond applying reactive workarounds and incurring technical debt?

We need confidence and a reliable path forward for building and maintaining production applications on Weweb.

5 Likes
2

Undoubtedly, it’s a real concern for any of us who want to take their project and business to the “Next level”.

3

Hi @bradley_gibson, I’m really sorry to hear about that.
Do you still have issues that are unresolved now? If yes please let me know here.

As for your question:

  1. On our update and QA processes

We have a thorough release process in place, which includes:

  • automated testing,
  • manual QA by multiple team members,
  • and testing updates against production applications we maintain internally.

That said, unfortunately issues can still slip through. The issue with the select component was a significant oversight and had internal consequences. We aim to move fast, and while this sometimes affects stability in the editor environment, production stability is non-negotiable. Breakages in live apps are rare, we actively monitor them, but if they do occur, we obviously take action and treat them as critical and work to resolve them as quickly as possible.

2. On mitigating the risk for production apps

To minimize risk on your end, we recommend:

  • closely following our release notes,
  • testing your apps whenever core components / features are mentioned as updated or changed,
  • and holding off on publishing new versions of your application until you’ve validated that things work as expected.

We understand that reactive fixes are not enough and we’re working on strengthening guarantees around stability, especially through new hires and processes we put in place after mistakes are made.

I know this might not solve your loss in confidence, but I hope you trust that we are doing our best to avoid these kind of problem to happen again.

2 Likes
4

Hi @tomerer2000, same as for Bradley, please do let me know if you still have issues that are unresolved now.

5

As a relatively noob in web development, is it safe to assume that if I were to export my app code and self-host, that WeWeb updates would not effect the self-hosted app until I re-published?

6

Yes, but that’s also true for weweb hosting. The published app is not affected by Weweb updates, only when you republish from editor.

1 Like
7

Same. I avoid WeWeb for personal projects.

8

Hi everyone,

I think we’re overlooking a key part of the conversation. To clarify and make sure we’re aligned, I have a couple of follow-up questions:

@bradley_gibson — Can you confirm that your production app broke due to a change introduced by WeWeb, without you publishing a new version?

@Raphael — The mitigation advice you gave seems to focus on risks when we publish changes. Just to be clear: is it WeWeb’s position that any change made to the platform should never affect a production app unless a new version is explicitly published by the developer?

As an agency, we fully understand the need to test before deploying updates. But a production app breaking on its own—without any publish action—is, as you’ve acknowledged, a dealbreaker.

Could you help us understand what caused this issue from a technical point of view, and what steps are being taken to prevent something like this from happening again?

When we look at the apps we’ve published, we don’t see any shared components being loaded. Everything appears to be compiled into the specific version we published. So if a platform-level change on WeWeb altered the behavior of a live app, I’d really like to understand how that’s technically possible.

2 Likes
9

I don’t think it’s possible.

10

Hello @ginkelb, thanks for your question. I confirm that once an application is deployed, no update coming from our side can affect the apps in production, wether hosted with WeWeb or elsewhere.

Your apps live in isolation from the editor environment and from WeWeb as a whole, so the production is safe by design. As an example, we have a few customers who built apps on WeWeb that are now running on servers with no access to internet - which shows that there is no depencies between WeWeb and the apps once they are deployed.

When you said “As an agency, we fully understand the need to test before deploying updates”, I agree, but also we want to make your lives as easy as possible and in an ideal world, you don’t have to, but it is indeed safer to do it in case we missed something while running our manual and automated tests.

11

Here’s what happened.

First Incident:
I got a call from a very annoyed employee at a client’s dispatch (we only use Weweb for them). They couldn’t scan stock out anymore. This backed up all their orders, messing up deliveries and staffing that were already scheduled.

We use barcode scanners for stock. The problem was the input fields for the scanners weren’t clearing after each scan; they just kept adding the new scan to the old one.

It should go: Focus input → Scan → Send to Xano → Clear input → Refocus.
What happened was: Focus input → Scan → Send to Xano → Clear input → Refocus.
It just skipped the clearing part, which used to work fine.

This problem popped up on a random day. We hadn’t touched anything related to this input or even that page. If Weweb pushed an update, we didn’t know.

I contacted support. After hours of waiting (while their warehouse was at a standstill), they basically said, “Yep, it’s a bug,” and gave a temporary workaround.
Now, to clear the input, we had to add an extra step everywhere: hide the input box, then show it again on every single scan.

Second Incident:
A couple of weeks later (so the client was already tense), I got another call: “We can’t scan out. The dropdowns for warehouse locations aren’t working.”

I checked Weweb and found the select component we used was now deprecated. So, staff couldn’t pick the warehouse IDs they needed for Xano.

I hit up support. While waiting, I couldn’t figure out what was wrong.
Support eventually said they’d “fixed” a Firefox scrolling bug, but this meant we now had to manually toggle a setting to make our dropdowns scrollable.

We use these dropdowns everywhere. So we had to go through every page and update this “deprecated” (but somehow still updated) component to make it scrollable.

To answer your question, @ginkelb: people might have worked on the system then, but I know for a fact nobody touched these specific parts. We could have pushed updates at the same time Weweb did. I have no way of knowing if Weweb pushes an update while I’m in the editor.

So now I have to ask: Do we really need to do a full system QA test every single time I hit “publish,” even if I just changed some padding on a table or a button color?

Setting up a whole QA team to test the entire app once or twice a day wasn’t on my 2025 bingo card.

2 Likes
12

Do we really need to do a full system QA test every single time I hit “publish,” even if I just changed some padding on a table or a button color?

This one hits hard. I’ve been delaying some deploys on my app for 3 weeks now because of the Bug on Input field. I also have an Under development ticket since April 18th on that issue. No ETA.

@Raphael If editor stability isn’t granted, can’t we version that as well? I have no idea how WeWeb works internally and by no means believe this would be simple, but being able to stick to a “stable” version of the editor could work. That’s what we do in regular web development, freezing all package versions to avoid surprises. Wouldn’t that make sense?

13

Just came across this post and all feels VERY concerning

14

This is how it feels right now. You have to check all functionality each and every time.

Maybe each component released should have it’s own update path. So when there’s an update to the input element for example, we should get notified of a new update available, and actively make the choice to upgrade that element. Then we also know we need to check the functionality of the input element in our app again.

15

I’ve experienced the same issues with some of the updates. Definitely concerning for production dependability. If updates to elements are going to impact existing functionality in any way, a new version of the element should be pushed and the old one should be deprecated, but not touched.

16

The thing is, that’s what testing in classical development is for. You usually wanna do (ideally) automated tests before publishing to prod. This is hard in WeWeb. Unfortunately I think we won’t get this any soon.

17

In any tech stack unless you’ve coded everything yourself and I mean EVERYTHING. You always have a chance to have things break. You could be using an NPM package that changes and it breaks what you were doing. Weweb is a tool that is constantly updating if you can’t manage things breaking then you probably shouldn’t be building this way, its actually expected that things are going to break. Yes they can be frustrating but this is part of software development. The only reliable way to have things “never” break ( i say that with quotations cause there’s so many ways something could still break without being touched ) is to code the whole project yourself.

18

The issue is we do not have any control over the core WeWeb components.

If you’re using NPM, you have full control over versioning. If you want to update your input to v1.2, you have the option to manually define that. If you don’t want to update it, you also have that choice.

WeWeb even allows this exact approach for libraries. I have a pretty massive component library that I manage, with many others using it. If I make a bad update, you can rollback the whole component library so everything still works. However you do not get this ability with WeWeb’s native components.

If you did, there may still be complaints, but at least the user would have the power to fix the issue in a timely manner.

I personally was lucky that I have my own components library, as the bad input update only broke one input in my app. However it would have been brutal if I hadn’t been using all my own custom components.

I opened a bug ticket on 2025-04-17 and posted on the forum much earlier about the issue, and still have no heard back. Absolutely wild to push a broken update to one of the most used functions in WeWeb and it not be fixed for almost a month.

Also have another bug ticket open since 2025-04-11 for memory leaks- still haven’t heard back.

It’s hard to shake the feeling that WeWeb AI was the worst thing to happen to the platform. From my perspective the focus has been AI over everything else → AI over the user experience, AI over the platforms stability, AI over customer support.

It’s so difficult to pitch this platform to anyone anymore. All the other AI solutions are so much better. And what made WeWeb amazing-- the editor, is just being ruined by worse AI functionality.

The previous minor inclusion of AI in the formula editor was something I used almost daily. Now I haven’t used AI more than 3 times in the past 3 months. And every time I use it, it’s just not useful.

7 Likes
19

Definitely agree with what you said, my main gripe is I guess my own personal opinion I can’t fathom having a set a forget attitude to software development. I’m always retesting stuff when I’m going through different parts of the app, even though I tested it 100 times, I’ve found a few niche edge cases doing this. I’ve gone back and refactored working stuff because I didn’t like the way I originally developed it and want something that’s easier to understand for future developers, which I know isn’t really a good practice “why fix what isn’t broken” sort of thing.

But as I said just my own personal gripe. There’s so many ways something could break ,stop working or even be improved for developers and/or users. I’ve experienced it in so many different types of software I’ve used. Unless your app is simple it’s highly unlikely there’s no bugs in a first release either and no matter what you do, users will always seem to find a way to break things.

Also are you still having memory issues? I remember something got mentioned to me around the start of the year about it being fixed and we haven’t had any issues since.

20

@Yaj

I understand that any tech stack has its potential for issues, especially with third-party dependencies. However, suggesting that this frequency of core functionality breaking is just “expected” and something to simply “manage” feels like a bit of a cop-out, especially for a platform positioned as a builder.