WeWeb Review 2026: a full look at the no-code platform for web applications

“Build an app by dragging blocks” sounds appealing right up to the moment you hit the ceiling of the builder: complex logic, a custom component, or an unusual database query. Most no-code platforms hide the real code so deep that escaping their sandbox means rewriting the project from scratch. WeWeb takes a different route: a visual interface editor that generates genuine Vue.js front end and connects to any back end — Supabase, Xano, Airtable, REST, GraphQL or your own API.

In this review we cover what WeWeb is in 2026, how its editor and logic work, who the platform suits and where the pitfalls are. We look at real build scenarios, compare plans, and give an honest verdict — including the cases where WeWeb is simply the wrong tool.

What WeWeb is

WeWeb is a French no-code platform (headquartered in Paris) for building web applications and internal tools. Its key difference from builders like Bubble or Softr is an architectural, frontend-only philosophy. WeWeb handles only what the user sees: layout, state, interaction logic, routing and client-side data. The database, authentication and server-side business logic stay with your back end — whichever one you already use or choose.

What you get out is not a proprietary “engine” that lives only inside the platform, but a Vue.js application. Vue is one of the most widely used front-end frameworks in the world, and WeWeb is honest about it under the hood: you can inspect the generated component code, drop in your own JavaScript or Vue component, and export the whole project.

The platform targets three groups:

• Startup founders and product managers who need a working MVP in a week to show investors and first users.
• Agencies and freelancers building client apps and admin panels at volume.
• Internal teams that need operational dashboards and tools without pulling developers off product work.

Distribution is a SaaS subscription per workspace with per-seat pricing and separate limits on published apps. There is no self-hosted version — a fundamental difference from ToolJet or Appsmith, which are open source.

How the editor works

The WeWeb interface is built around three panels: page and layer tree on the left, visual canvas in the middle, properties of the selected element on the right. The editing model feels close to working in Figma, except every element is not a picture but a live component with state and data bindings.

Components and structure

The library holds several hundred ready components: containers and grids, forms, buttons, tables, lists, charts, modals, sliders, navigation, authentication elements, payment forms. Any element can be turned into a reusable component with its own props — the core mechanic for large projects: build a product card or a header once, use it in ten places, and change behaviour through props.

Layout runs on flexbox and grid with visual controls. At the same time a custom CSS mode is available, and you can add your own styles for fine tuning. That is rare in no-code: usually it is either visual or code — WeWeb lets you mix both.

Data sources: connecting to any back end

Data sources are the heart of the platform. Here you define collections and REST/GraphQL requests that are reused across the whole app. Native connectors ship for Supabase, Xano, Airtable, Google Sheets, Notion, PostgreSQL, MySQL, OpenAI and dozens more; everything else connects through generic REST or GraphQL with configurable headers, auth and parameters.

An important detail: WeWeb does not store your data. It runs requests from the user’s browser (or through Supabase/Xano server functions), so security and access rules are your back end’s responsibility. That is both a plus — no vendor lock-in on data — and a minus: if your back end is not ready for a public API, you will have to think about protection yourself.

Workflows: logic without code

Workflows are a visual behaviour builder. Each workflow is a chain of steps: “on button click → check a condition → send a request → show a notification → update a variable”. Conditions, loops, delayed actions, array and object handling, variable access and data actions are all available.

For typical tasks — authentication, creating a record, updating a status, filtering a list — visual blocks are enough. When logic turns unusual, you can drop in custom JavaScript inside a step or move the computation into a formula. WeWeb formulas are a separate expression language, similar to JavaScript but with access to the app context; they support ternaries, array and string methods, and date handling.

State and reactivity

WeWeb uses the same reactive model as Vue: app variables, page variables and local component state. Changing a variable automatically re-renders everything that depends on it. This makes behaviour predictable: you do not “press a button to refresh a table”, you change the data and the interface follows.

Global variables (the current user, the selected branch) are easy to push into request filters, which simplifies multi-tenant apps.

Custom code and components

When the built-in library is not enough, WeWeb lets you add your own Vue component: upload the code, describe the props, and it appears in the element list alongside native ones. npm libraries can be connected too — charts, maps, editors, specialised widgets. This layer removes the main objection to no-code: “what if I need something that does not exist”.

Publishing, domains and performance

An app is published with one click to a *.weweb.io domain or your own domain with SSL. A staging environment is available, so changes can be checked before production — critical for teams. Pre-rendering (SSG) modes exist for marketing pages, which matters for SEO if you are building not just an internal tool but a public site.

Performance depends on the back end and asset weight. The WeWeb Vue front end is fast, but heavy queries against a slow API are felt more than in server-rendered apps.

Pricing

WeWeb is sold as a subscription with per-seat pricing. The 2026 structure looks like this:

• Free — a plan for learning and prototypes: limited pages and publications, WeWeb branding on the app, no custom domain.
• Starter — a base subscription for a single project: custom domain, branding removed, reasonable member limits.
• Growth / Scale — team tiers: roles and permissions, more workspaces, priority support, higher limits.
• Enterprise — custom terms: SSO, legal guarantees, SLA, onboarding support.

App publishing is billed separately: every published project is a slot, and how many you get depends on the plan. Keep that in mind when planning — five internal tools will not fit on Starter.

On economics: WeWeb is the most expensive part of your stack, but not the only one. The subscription is joined by the back end: Supabase from zero with a free tier, Xano from a few dozen dollars a month, your own server by real cost. A project on WeWeb + Xano for a three-person team easily passes a hundred dollars a month, and that is a normal number for a tool replacing a couple of months of front-end work.

Pros and cons

Pros:

• Real Vue.js output — no proprietary runtime, and you can inspect the generated code.
• Free choice of back end: Supabase, Xano, Airtable, REST, GraphQL, your own API.
• A hybrid “visual plus code” approach: CSS, JavaScript and custom Vue components at any time.
• A powerful logic editor (workflows plus formulas) without mandatory programming.
• Staging environment, custom domains, pre-rendering for SEO pages.
• Team features: roles, permissions, multiple workspaces.

Cons:

• No self-hosted version — app data and accounts live only in WeWeb’s cloud.
• Per-seat and per-publication pricing: cost grows quickly as the team scales.
• A learning curve for logic: formulas and workflows require understanding the reactive model and array handling.
• The platform handles the front end only — database, auth and access rights are entirely on you.
• Dependence on third-party uptime: a Supabase or Xano outage stops the app.

How it compares

WeWeb vs Bubble. Bubble is a full-stack builder with its own database and hosting: everything in one place, but you pay with a proprietary runtime and less integration flexibility. WeWeb gives more control over the stack and the code, but requires you to sort out the back end yourself.

WeWeb vs ToolJet. ToolJet is an open-source platform for internal tools that you can self-host. For admin panels and CRUD tools it is cheaper and safer. WeWeb wins when you need a public customer-facing product with a polished interface and fine-grained state handling.

WeWeb vs Softr / Glide. Softr and Glide build apps on top of Airtable and Google Sheets in minutes, but their complexity ceiling is low. WeWeb is the next step: a platform for projects that outgrow a simple builder but are not ready to fund a front-end team.

WeWeb vs hand-coded Vue. If you have a front-end team and an unusual product, classic development gives more freedom. WeWeb pays off where speed to market matters more than absolute flexibility.

A hands-on test: building an app

To judge the platform on something other than marketing, we ran a typical scenario — a small internal request tracker on top of Supabase. The timeline was telling.

Setup. Connecting Supabase took about ten minutes: paste the project URL and anon key, WeWeb pulls the table list and immediately offers ready collections. Authentication is enabled with a plugin — login and signup forms are generated automatically, you just wire up the pages.

Interface. The request list was built from the table component bound to a collection, plus a status filter and search. A couple of hours of work and there is a working screen with sorting and pagination. The request card was extracted into a reusable component and used in two places: in the list and in a modal.

Logic. A “take into work” button is a four-step workflow: update the record in Supabase, refresh the collection, show a notification, close the modal. This is where the learning curve showed: the first workflow had to be redone twice, because refreshing a collection is a separate step and not an automatic consequence of a request. Once the reactive model clicked, the remaining scenarios took minutes each.

What needed code. Custom date formatting, conditional row highlighting by status and an external webhook integration — all solved either with a formula or a short JavaScript step. A full Vue component was not needed, but the ability to add one removed the fear about the future.

Test verdict. A simple CRUD tool came together in about a day with zero lines of server code. Most of the time went not into layout but into data design and understanding how WeWeb handles state.

Real-world scenarios

An MVP in a week. A founder connects Supabase (auth, database, storage) and builds an account area, a request list and a create form in WeWeb. Five days later there is a demo with working authentication and live data — instead of an empty Figma prototype.

An internal tool for a department. An operations team gets a dashboard on top of an existing PostgreSQL: filters, search, export, status editing. Developers are not pulled away from the product, and changes ship without a release cycle.

A client portal for an agency. An agency builds client portals on one template: auth, account area, documents, invoices. Repeatability brings margin — a new client launches in a couple of days.

A marketing site with an app. Public pages are built with pre-rendering for SEO, while the authenticated part pulls dynamic data from an API. One project covers both marketing and product.

When WeWeb is not the right fit

It is fair to say when to look elsewhere:

• You need a self-hosted or air-gapped environment — where data cannot leave your infrastructure, WeWeb does not qualify by definition.
• The project is heavy on server logic — if business rules live in the back end and require transactions, WeWeb remains a thin client.
• A mobile app is the main goal — WeWeb builds web apps; native mobile builds are not its focus.
• A ten-person team on one app — seat costs will eat the budget, and conventional development will be cheaper.

Verdict

In 2026 WeWeb is one of the most convincing platforms in the no-code category if you need a real web application, not a block-based landing page. Its strength is architectural: Vue on the way out, a free choice of back end, and a hybrid “visual plus code” model. It does not lock you into a proprietary runtime and does not force a rewrite when built-in tools stop being enough.

The flip side is cost and responsibility. A per-seat subscription plus publications, plus a back end, plus your own work on security and API make WeWeb noticeably pricier than simple builders. And rightly so: you are paying not for “dragging a site together” but for a platform that replaces weeks of front-end development.

If you are a founder at MVP stage, an agency with a stream of client projects, or an internal team that needs fast tools on top of a ready API — WeWeb deserves a test on the free tier, judged on build speed for a real task. If you need a self-hosted environment, maximum cheapness, or full control of the stack, look at open-source alternatives or classic development.

FAQ

Can you export an app from WeWeb? Yes — you can view and export the generated Vue code, which reduces frontend-level vendor lock-in.

Do you need to program to work in WeWeb? For simple apps, no. But understanding the reactive model, array handling and API requests will speed things up considerably and unlock formulas and custom components.

Is there a free tier? Yes. The free plan suits learning and prototypes but limits publications and domains. Production needs a paid subscription.

Which database should you choose? Supabase is the fastest start with auth and permissions out of the box. Xano if you need powerful server logic without writing a back end. Airtable or Google Sheets for simple internal tasks on small data volumes.

Is WeWeb good for SEO sites? Partly: it supports pre-rendering and custom domains, but for content projects with thousands of pages a classic CMS is usually better value.

How safe is the data? WeWeb does not store your data — it stays in your back end. Security therefore depends entirely on the access rules you configure in Supabase, Xano or your own API.