Roadmap Update Q1 2026

Announcements
1

Hi everyone! Here is the latest roadmap update.

TL;DR

  • March: Full-stack backend goes live with improved & new 3rd-party integrations for email, storage, and more

  • Q2: Workspace roles & permissions + a better AI with deterministic guardrails

  • Q3–Q4: Branching + performance/security/compliance audits

  • Ongoing: bug fixes and improvements

Our direction

Before diving into the details of the roadmap, I’d like to restate our vision:

At WeWeb, we are committed to building the best platform for non-coders to build serious web products without worrying about infrastructure, migrations, security, performance, or AI unpredictability.

In other words, WeWeb’s mission is to remove technical complexity without limiting product freedom.

Making complex things feel simple is at the core of everything we do.

What we’re building toward

We’re systematically removing the hardest parts of building web apps:

:white_check_mark: Reliable deployment (frontend + backend): One-click deployment of full-stack applications on managed infrastructure, or deployment to your own infra. 2026 goal: release backend in March + continuous improvement.

:white_check_mark: Environments & migrations: Automatic editor/staging/production environments, backups, one-click rollbacks, and automated migrations (blue/green approach with WeWeb tables). 2026 goal: release backend in March + continuous improvement.

:warning: Collaboration at scale: Multiple builders can already work on the same project, but we still need proper branching, workspace roles & permissions, and improved collaboration logs. This is all planned for this year. (More info below)

:tear_off_calendar: Security & compliance: We’ll introduce a programmatic audit system to detect common security mistakes and enforce configurable compliance rules. Planned for Q4 2026.

:tear_off_calendar: Performance: We’ll ship an AI performance audit that detects common issues, reports them clearly, and (when possible) offers automatic fixes. Planned for Q4 2026.

:white_check_mark: Beautiful, on-brand UI: Design systems will become more central to the WeWeb experience to ensure consistent UIs at scale. Pixel-perfect manual building, Figma import, and AI-generated UI already work pretty well and will continue to improve. 2026 goal: continuous improvement.

:white_check_mark: Advanced logic (frontend + backend): WeWeb is already strong for frontend logic (functions + workflows). We’re now bringing that same building experience to backend logic. 2026 goal: release backend logic in March + continuous improvement.

:warning: AI building with real control: We’re building a first-of-its-kind AI to JSON to App architecture (AJA architecture). It lets users delegate work to AI while keeping the fundamentals deterministic and rule-based (design system, approved APIs, workspace rules, etc.). Planned for Q2 2026.

:white_check_mark: Removing the last no-code bottlenecks: Custom coded components, code export (source or compiled), and keeping the platform open: any API, any SQL database, any storage provider, any auth system. 2026 goal: release new integrations monthly starting March 2026 + continuous improvement.

I hope this vision excites you as much as it excites us and resonates with all of you. We have been working on this for many years and we are now very close to having all the pieces in place.

2026 roadmap (high-level)

With that in mind, here is the high level roadmap for this year:

  • Q1: Release the new full-stack experience, including improved & new integrations for storage, email, and more.

  • Q2: Release of the AI to JSON to App agentic system, bringing roles & permissions at workspace level, enabling agentic access to WeWeb (i.e. external AI agents will be able to use WeWeb).

  • Q3–Q4: Release branching + audit features (performance, security, compliance).

  • Ongoing: Bug fixes and improvements based on feedback.

A note on SSR and GPT/MCP apps

SSR won’t be part of the 2026 roadmap. We believe it will make sense for WeWeb long-term to unlock more use cases, but we want to stay focused and ship the full-stack + branching + workspace roles & permissions + audit foundation + AJA architecture first.

GPT Apps / MCP Apps are also out of scope for now due to limited demand and bandwidth.

Now let’s dive into the details for this quarter:

The full-stack experience

We will offer the following out-of-the-box features:

  • A scalable database with a scale-to-zero option, automatic database migrations when deploying to production, and a great UI to manage tables, filtered views, and many-to-many relationships

  • A scalable server to run any kind of serverless functions (backend logic), with a clean UI to configure backend workflows, define API endpoints, and review your Swagger

  • An authentication system

  • A storage system (and new third-party integrations)

  • An email system (and new third-party integrations)

Users will be able to use these features à la carte. This will unlock powerful combinations, such as using Supabase or Airtable as the database while relying on the WeWeb server for backend logic, authentication (no RLS headaches), and overall security. Or using the WeWeb database and backend together with an external storage provider, and so on.

And of course: all of this is optional. WeWeb will still fully support frontend-only projects.

We originally planned to release the WeWeb backend in January, but we expanded the scope to make it significantly more powerful and useful. Go-live is now planned for March.

The AI experience: vibe coding under control

We’re working hard on it, and we will release it as soon as we can. We’ve committed to Q2, and our goal is early Q2 (April/May).

The AJA architecture will enable what we call “vibe coding under control” and give you much more granularity and control when building with AI thanks to deterministic guardrails. We are also entirely revamping our agentic system to get (much) better outputs.

The AI will be full-stack, able to build both the UI and the backend.

As always, let us know what you think and feel free to share any questions or feedback in this thread!

18 Likes
WeWeb - update on what we are working on at the moment
2

Bravo @Raphael and Bravo to the team for this roadmap and the clear direction WeWeb is taking in 2026.

Given the current landscape, especially with the rise of vibe coding and increasing competition, this focus feels absolutely right. Concentrating on the full-stack foundation, branching, roles & permissions, audits, and controlled AI building shows a strong commitment to long-term product maturity rather than chasing trends.

It’s great to see the team doubling down on the essentials while still pushing innovation forward.

5 Likes
4

Hi Raphael, thank you for the update.

Can you provide any information on the new elements that were in the development (Gantt chart)?

1 Like
5

Would have been nice to see SSR this year, but we at least have branching planned.

I think I might have mentioned this to Matt and Flo on Office Hours, but with AI, it would be good to have the following:

  • Define the Design System that the AI should use
  • A way to see what variable/workflows/formulas etc have been created/edited by the AI (probably a naming conversion rule..?)
  • AI Audit: A way to get a summary of variables/components/workflows etc that are not used anywhere
  • Define AI Task: Design Only/Build Workflow/ Design and Build
  • Design Options: Ideally I would like to be able to say: Give me 3 design options for feature x. I now have a dev page where I vibe some ideas, then move them to the main page
  • Dependency analysis. Give it a component and ask it to provide a list of dependancies across the app etc
  • Estimated token usage
1 Like
6

@Raphael I’m not sure if this is something that was asked or ever discussed, or even something you want to discuss openly, but I was wondering why can’t WeWeb develop everything on the roadmap in 3 months?

The reason I was asking is that it seems that a lot of startups raise a bunch of $$$$, then just hire 20-30 engineers and develop all these features in 6 months.

Is it a financial implication of funding raised, or a company culture decision on not wanting to move too fast etc

2 Likes
7

thanks for following up on this, the work on these elements will be resumed once the fullstack experience will be pushed in production, so I hope we’ll get something done in April/May with that.

2 Likes
8

Hello Emeric, thanks for asking!

We would love to be able to develop everything on the roadmap in 3 months, but the truth is that many of the things we listed above involve deep technical complexity that can’t simply be solved by throwing more people or money at it. Adding engineers doesn’t scale linearly and, in fact, beyond a certain point, it can actually slow things down (coordination overhead, onboarding, architectural alignment, etc.).

Also, I do want to think that our shipping rate is more than decent compared to industry standards, but I’ll let everyone be their own judge on this.

That said, it’s true that with more developers we could ship certain things faster, like new elements, integrations, connectors, and we are currently hiring more developers and leveraging AI more and more to build faster. But we’re not talking 4x faster for the whole roadmap unfortunately.

Hope that helps!

2 Likes
9

Haha i bet the features are not as easy for sure.

Still looking forward to the new wave of updates.

:+1:

2 Likes
10

Ambitious, I can’t help but wonder what’ll actually get shipped (:

11

Can you please elaborate more on “code export (source or compiled)”?

1 Like
12

Hi, Raphael,

Thanks for sharing the roadmap — it’s always good to see the direction you’re aiming for. At the same time, I have to admit I feel a bit concerned, because from my perspective this vision doesn’t fully align with what the market is asking for right now.

I would genuinely love to see a working AI for no-coders. But in its current form it feels not only unhelpful, but sometimes even harmful: it generates Custom JavaScript instead of using no-code actions, doesn’t understand WeWeb components, and doesn’t reliably validate whether the produced code actually works.

That’s why the current focus worries me. It feels like WeWeb is trying to cover too many directions with the same team — while still losing ground in the market. And I’m honestly not sure which audience you’re prioritizing with these updates:

  • Vibe-coders (who are already strongly drawn to Lovable), or
  • Pro-builders (who choose WeWeb specifically for its visual editor and low-code extensibility).

In my opinion, it will be difficult for WeWeb to become a no-code leader, simply because it requires knowledge of JSON, handling workflow exceptions, and other concepts that are closer to low-code than true no-code. On top of that, the AI keeps producing Custom JavaScript and creates a lot of extra variables, which increases complexity rather than reducing it.

You obviously have better access to customers and can reach them directly, but if I remember correctly, in the old public roadmap (with feature voting), the community prioritized different things as the most desired improvements.

From a market positioning standpoint, the clearest opportunity still seems to be competing directly with FlutterFlow. And in that old roadmap, WeWeb had a strong PWA → native upgrade direction, which felt very aligned with that goal.

If the plan is instead to shift toward a different backend approach — that’s fine, but realistically most users will still start from Airtable or Supabase anyway.

Also, I remember the previous announcement received a lot of feedback along the lines of “we don’t need AI”, yet AI still appears to remain the central goal. This feels risky, especially since WeWeb is already one of the best builder tools on the market.

As I once told a client: “WeWeb is one of the best visual builders on the market, and one of the weakest AI-driven developer tools.” Sometimes it’s better to acknowledge a direction isn’t working, rather than pushing users to adopt it.

Of course, you’re the CEO and you have more data than I do — but my impression is that WeWeb can either focus on what it already does exceptionally well (and keep a strong, sustainable team around a great frontend builder), or risk losing the entire positioning battle to FlutterFlow and Lovable.

With best wishes — and with genuine love for the product,
Anton

5 Likes
13

hello @Widefiree, sure! What would you like to know?

14

Thanks for your message, Anton. I agree that WeWeb’s current AI integration is underwhelming. That said, it doesn’t mean we won’t make it work. It is a much harder technical problem than we initially thought, but we are getting there.

In our view, the best web app builder for non-coders will be AI-powered while still offering predictable guardrails and full visual control. We know this is technically feasible and we want to bring that capability to our users. Just as AI has become genuinely helpful for coders, it can deliver the same value for non-coders once it is properly harnessed. When that happens, we believe there won’t be the need for the distinction you suggest between vibe coders & pro builders. Pro building in visual programming will be AI driven / Agent powered - just like what’s happening in the pure code world today :slight_smile:

4 Likes
16

Hey there, and thanks for the explanation.

I have a different view on the whole AI topic that I wanted to share, coming from somebody who started with a no-code background and worked his way into a low-code background.

My background:

AI helped me a lot to understand how code and different devices work. This knowledge taught me “how to think” in terms of approaching a web-app. If I got stuck developing an idea, I could ask AI (ChatGPT) for possible reasons why my approach did not work, and I learned something new. Without AI I would have never gone down this route, and I am very thankful for this invention.

AI for coders vs non-coders:

Now the other end of the developer-spectrum. AI is very helpful for coders because it accelerates their work and they have the knowledge to check the AI results and see them in context.

Non-Coders do not have that knowledge, so they entirely have to rely on what an AI produces. Trying to bridge that gap without letting AI produce unsafe web apps or frustrating messes in code is brave.

The user journey for weweb:

Developing Weweb into a full-stack application is a great idea in my opinion. For non-coders and new users not having to learn/implement third-party apps and their pricing models and how they scale is a great benefit for the less experienced user and also for keeping users long-term. I think this part of the vision alone is valuable enough for weweb to still be the top 1 or 2 tool for building webapps.

If you then add long overdue bug fixes and proper maintenance of plugins - weweb could become not only good but great.

Your statement:

“I agree that WeWeb’s current AI integration is underwhelming. That said, it doesn’t mean we won’t make it work. It is a much harder technical problem than we initially thought, but we are getting there.”

I think this is the perfect example of what makes people uncertain about Wewebs future and vision and reminds me of the sunk cost fallacy → making bad decisions that lead to bad outcomes because we see past investments instead of present and future costs and benefits.

Just some thoughts:

What would happen if tomorrow AI gets completely removed from Weweb? Which features will be missed? Would the outlook of the company really be that bad? How much less money would the company make? Is that really a relevant part? Why not focus on other topics and make the community happy? What exactly is the measurement that tells you AI is more important than other often-requested features?

Ending:

Hope that it does not come of as offensive - just wanted to provide a more detailed critical opinion. Otherwise I love all the upcoming changes :smiley:

3 Likes
17

Tanks for the thoughtful message and for sharing your journey, great read!

I’ll answer with a question: do you think non-coders would benefit from AI as much as coders do if they could read, check and manipulate the AI’s output as well?

1 Like
18

Thank you! In short - no I don’t think so. I think this approach has some value but the problem lies in how differently qualified groups use tools.

  1. A pro uses a tool much more skillfull and specific because he knows about certain limitations or traps.
  2. A beginner uses a tool more in a unspecific, wishfull way.
  3. AI does what it’s told.

Step 3 is the reason a “generally capable and unspecified ai” is a very difficult approach.

If I ask a low-quality question, i get a low quality result.

Let’s turn this example around.

If I am a beginner at a coding job and I say “I want this to do that” - usually the answer is not “Great let’s do it”, like an AI would respond. The answers are mostly “Did you think about this or that? This problem could arise. How would you solve that Problem. No let’s try this approach.” Because my peers in this scenario have more experience, they do the most valuable think and first “educate” and second “help”.

There are Videos on youtube where a dad tells his children to write him instructions on how to make a peanut butter sandwich and then messes it up in every way possible because the instructions “prompt” were not good enough. That’s kind of my metaphor here.

1 Like
19

In response to @Raphael I agree with @adrian1 and will add the following:

“do you think non-coders would benefit from AI as much as coders do if they could read, check and manipulate the AI’s output as well?”

  • “Read” - most people won’t actually read it all, especially as attention spans have grown shorter and culture (especially in the United States) at least is all about instant gratification. And many of the younger generation have grown up with tools from major companies that are optimized to make everything so intuitive that people have grown accustomed to just clicking “next” without reading.
  • “Check”: sadly, even professionals often don’t do this with code: “96% Engineers Don’t Fully Trust AI Output, Yet Only 48% Verify It” - 96% Engineers Don’t Fully Trust AI Output, Yet Only 48% Verify It - and even if beginners did, without the knowledge to foresee how it impacts things down the road or how best practices apply to their specific use case, even if they DID check it, how valuable is that check? If a teacher in a classroom (AI) writes something and then a student (beginner) checks it, how likely is that student to be able to spot anything the teacher did wrong?
  • “Manipulate the AI’s output” - without both “read” and “check” going flawlessly, manipulation is a shot in the dark. They will continue manipulating it to get what they want in a “what you see is what you get” kind of way, because that’s what’s visible / knowable / practical. That might work sometimes for functional requirements, but not for non-functional (they probably can’t even articulate the difference between those things— I know I couldn’t when I was a no coder); so they won’t manipulate it in a way that makes it more secure, scalable, available, etc

There are of course exceptions to this, I hope a lot of people would actually want to learn and read/check/manipulate, but I doubt that’s the case especially if the system is designed in a way that less them easily circumvent the actual thought process to do that well. So practically those who do what you say well, will be the minority of people.

I used to love WeWeb because I viewed it as a tool that would help me (at the time a no-to-low-coder), learn and elevate myself to a great low-coder. And in doing so, trusting the tool would help my output be on par with what a solid developer would do themselves with code. All in a system that would help me stay within parameters of best practices and/or enable me to enforce best practices myself through design systems and building in a carefully thought out and planned way that builds something scalable and beautiful over time (not just brainstormed or bloated).

Now, every time I see my WeWeb bill come through. I feel like I am massively overpaying, frustrated that my bill increased for AI tokens that I literally haven’t consumed a single one of in six months at least, and finding myself wanting to put on my backlog figuring out how to migrate off WeWeb but sticking around because I don’t have the time or bandwith to do that and feeling resentful about it and like I have major vendor lock in to yet another tool that went AI-first instead of customer-first :pleading_face:

3 Likes
20

That really resonates with me, Matthew. It’s actually one of the reasons I love WeWeb so much :slight_smile:

It’s a tool that helps you grow. Not just ship faster, but upskill from a no/low-coder into someone who understands structure, best practices, scalability, and can trust that what they’re building is solid over time. A system that nudges you toward good architecture and best practices, instead of “brainstormed and bloated.”

But I have to say, I don’t think our work on AI changes that vision.

At the moment, yeah, our AI is definitely not where it needs to be, and it can generate some pretty questionable patterns (like 100 local workflows instead of one reusable global workflow :woman_facepalming:).

But to me that’s not an argument against AI, it’s an argument for making AI better aligned with best practices.

The goal shouldn’t be “AI that builds anything instantly.”
The goal should be “AI that builds the right way by default.”

If we do that well:

  • People who want to learn can reverse-engineer strong patterns.

  • People who don’t want to go deep are still protected by good defaults.

  • The product teaches through structure, not just documentation.

That’s still very much the philosophy of WeWeb.

For example, with the new fullstack experience, people will be able to build frontends that are secure by default on top of Airtable and GoogleSheets. Before, we would add a bunch of warnings explaining Airtable is not a state-of-the-art backend, etc. Now, all the filters will be secure backend filters by default. Instead of relying on warnings and documentation that many users don’t read, we’ll be implementing guardrails that they can’t ignore. To continue with the example of filters, if someone wants to filter in the frontend, it’ll still be possible but you’ll have to toggle on the option and be warned at the time, which is much more powerful to learn about the pros and cons of both approaches.

The security and performance audits we have planned for later this year will be another step in that direction of always trying to help people build apps that are secure, scalable, and maintainable, whether they fully understand every layer or not.

So to me, AI doesn’t replace the “learn and grow” path. It can accelerate it if we design it correctly.

And I genuinely believe we’re moving in that direction, even if it’s taken longer (and been more frustrating) than any of us would like.

21

Sure. I’m just worried about “a popular WeWeb with no AI” versus “no WeWeb at all”.

Bubble had no changes for almost 10 years and fed their marketing instead of a dev team. And now it’s obsolete, but still on top in every chart. We would be happy to have WeWeb-2024 with no whistles, but with the clients pool.

Now only the developers, which are using WeWeb, know why it’s cool, for all newcomers it’s just “another pointless and very complex AI tool”.

You own the stats and know better, but for me, the bell is ringing extremely loudly: Bubble is still in a high demand…

…and no one knows what WeWeb is.

I feel like this too, bro.

If you’re trying to beat Glide with those Google Sheets, they’re already ahead and have their market. Why focusing on slow dummy-level solutions if you already have a hammer-drill, not just a hammer?

Multitool is a tool which is bad in every field.

3 Likes
22

I have been privileged to have seen a bit of the new, full-stack weweb version and was actually quite impressed. for me working in xano+weweb, it was very easy to understand it and I guess a lot of people replying here, aren’t aware of how far weweb already is with developing this.

Sure it’ll have it’s initial limitations probably but for ‘first time’ no/low-coders the cost of entry will be so much lower. The time I had to spend figuring out, first of all how to connect xano to weweb, then how to create ‘simple’ things like a signup form that emails a token to confirm the mail address… Things that make you wonder “why in the hell do I have to build all this when it’s such a common thing”? Will be sooo easy and quick with the new full-stack experience… And of course if the AI does actually get better, that means it can create front and backend plus the interactions all at once, which as a vision I can understand that the weweb team has.

The only thing holding me back personally, is that all the things I’d want to create with it would be public facing sites like marketplaces, directories, jobboards, etc. Things that require proper SEO and SSR. Unfortunately that means I have to ignore my excitement about the full stack experience because it won’t allow for anything but saas-like apps with webflow (or whatever else) marketing/landing pages to get people to sign up for said web-app. :frowning: