What WeWeb Is and Why It's Different
WeWeb is a visual web application builder — but it's not a website builder like Webflow, and it's not a general-purpose no-code platform like Bubble. The distinction matters. WeWeb is built specifically for web applications: data-driven interfaces where users log in, interact with records, and take actions. Think dashboards, CRMs, client portals, and internal tools — not marketing sites.
Compared to Bubble, WeWeb takes a front-end-first approach. Bubble bundles a proprietary database and backend together with its UI layer. WeWeb is database-agnostic: you connect it to any backend via REST API, GraphQL, or its native Supabase connector. This means your data lives in a real, portable database (PostgreSQL via Supabase) rather than locked inside a platform. For developers who may eventually want to switch frontends, this is a critical architectural advantage.
Compared to Webflow, WeWeb handles dynamic data and user authentication natively. Webflow excels at static and CMS-driven marketing sites. WeWeb handles the authenticated, per-user dynamic data that defines a web application. If your product needs user accounts, data that changes based on who's logged in, or CRUD operations — WeWeb is the right tool. You can explore how it compares in more detail on the WeWeb tool page.
Setting Up Your WeWeb Project
Sign up at weweb.io and create a new project. You'll start with a blank workspace. The WeWeb editor has three core concepts: Pages (routes in your app), a responsive Grid layout system, and a Component Library. Spend 10 minutes exploring the editor before building — drag a container, resize it across breakpoints, and add a few elements to understand how the grid works.
Create two pages to start: a Login page and a Dashboard page. WeWeb uses a page-based routing system similar to Next.js — each page has its own URL and can have its own layout. Set the Login page as your default (unauthenticated) route. You'll protect the Dashboard with an auth guard later.
The responsive grid uses a 12-column layout with configurable breakpoints: desktop, tablet, and mobile. Get in the habit of checking every layout you build at all three breakpoints before moving on. WeWeb shows a breakpoint toggle in the top toolbar — use it constantly. Responsiveness fixed after the fact takes 3× longer than building responsive from the start.
Connecting Your Supabase Database
WeWeb has a built-in Supabase connector. In the left sidebar, open the Plugins panel and add the Supabase plugin. You'll need two values from your Supabase project: the Project URL and the public anon key — both found in your Supabase dashboard under Settings > API. Paste them into WeWeb's connector and save.
Once connected, WeWeb can read from and write to any Supabase table, call RPC functions, and listen to real-time subscriptions — all without writing code. The connector also integrates with Supabase Auth, meaning WeWeb can handle sign-up, login, and session management through the same plugin. This is the integration that makes the WeWeb + Supabase stack so powerful for beginners: one connector gives you data, auth, and real-time in a single setup step.
Test the connection by creating a simple data collection in WeWeb that fetches rows from one of your Supabase tables. If the rows appear in the collection preview, you're connected. If you see an authentication error, double-check that Row Level Security is enabled and that you have an appropriate policy for the anon role on the table you're testing.
Building Your Data Model in Supabase
Before building any UI, design your database schema. For a beginner tutorial, let's build a simple task management app. In Supabase, navigate to the Table Editor and create a tasks table with these columns: id (int8, primary key, auto-generated), user_id (uuid, references auth.users), title (text, not null), status (text, default 'pending'), created_at (timestamptz, default now()), and updated_at (timestamptz).
Relationships matter even in simple apps. The user_id column is a foreign key linking each task to the user who created it. This is the foundation of data isolation — you only want users to see their own tasks. Enable Row Level Security on the tasks table and add a SELECT policy: USING (user_id = auth.uid()). Add matching INSERT, UPDATE, and DELETE policies with WITH CHECK (user_id = auth.uid()). These four policies are the minimum for a secure single-user data model.
For more complex apps, you'd add a workspaces table and a workspace_id foreign key to enable multi-tenancy — but for your first WeWeb app, single-user RLS is the right place to start. The Supabase tool page has more on advanced data modelling patterns when you're ready to go further.
Creating CRUD Operations in WeWeb
With your Supabase table connected, create a data collection in WeWeb for the tasks table. Set it to fetch rows where user_id equals the current user's ID (WeWeb's Supabase plugin exposes the current user object as a variable). Bind a repeating list component to this collection — each item in the list renders one task row.
For creating tasks, add a form with a text input and a Submit button. In the button's click workflow, add a Supabase Insert action: table = tasks, data = { title: form.title, user_id: currentUser.id, status: 'pending' }. After the insert succeeds, trigger a collection refresh so the new task appears in the list immediately. This pattern — form submission → insert → refresh — is the core create workflow in WeWeb.
Update and delete follow the same pattern. For update, bind an input field to the selected task's title, and on save, run a Supabase Update action filtering by the task's id. For delete, add a button with a Supabase Delete action and an id filter. These three workflows — create, update, delete — combined with your list view give you full CRUD in about 30 minutes of editor work. If you'd like this built professionally for a real product, our team has delivered 50+ no-code apps in production using exactly this stack.
Adding Authentication
In WeWeb, the Supabase plugin's Auth section handles sign-up, login, and session management. On your Login page, create a simple form with email and password inputs and two buttons: Log In and Sign Up. Bind the Log In button to the Supabase Auth "Sign In with Email" action and the Sign Up button to "Sign Up with Email". After successful login, add a navigation action that redirects to your Dashboard page.
To protect the Dashboard page from unauthenticated access, open the page settings and enable Auth Guard. Select "Redirect to Login if not authenticated" and point it at your Login page. WeWeb will automatically redirect unauthenticated visitors before the page renders — no extra logic needed.
For a production app, also add a Sign Out button to your navigation. Bind it to the Supabase Auth "Sign Out" action followed by a redirect to the Login page. Test the complete flow: sign up with a new email, verify the redirect to Dashboard, refresh the page to confirm the session persists, then sign out and confirm the redirect back to Login. Authentication in WeWeb with Supabase takes about 45 minutes to implement end-to-end.
Styling and Responsiveness
WeWeb uses a design variables system similar to CSS custom properties. Define your brand colours, font sizes, border radii, and spacing values as variables in the Design System panel. Once defined, apply them throughout your app rather than hardcoding values. This means changing your primary brand colour later requires a single update — not hunting through 200 components.
For responsiveness, WeWeb's grid collapses naturally across breakpoints, but you'll need to adjust column spans, hide elements, and change spacing at tablet and mobile sizes. Use the breakpoint override system: every style property can be overridden per breakpoint. A rule of thumb: design desktop first, then check tablet (usually minor adjustments), then mobile (usually requires intentional column stacking and font size reduction).
Reusable components are your biggest productivity multiplier. If a pattern appears more than twice — a card layout, a status badge, a modal structure — turn it into a WeWeb component. Components are defined once and updated everywhere. This is especially important for navigation bars and sidebars that appear on every page. Building your nav as a component from the start saves hours of repetitive work as your app grows.
Publishing Your WeWeb App
When you're ready to go live, click Publish in the WeWeb top bar. You can publish to WeWeb's built-in subdomain (yourapp.weweb.io) for free, or connect a custom domain on any paid plan. To add a custom domain, go to Project Settings > Domains, enter your domain, and follow the DNS instructions — WeWeb provisions SSL automatically via Cloudflare.
For SEO settings, each page in WeWeb has a dedicated SEO panel where you set the page title, meta description, and Open Graph image. For public-facing pages, also configure the canonical URL to match your custom domain. WeWeb's published output is server-rendered HTML — pages are crawlable by search engines and score well on Core Web Vitals out of the box.
After publishing, run through your complete user flow one final time in a private browser window to confirm the production build behaves identically to the editor preview. Check that authentication redirects work, that CRUD operations succeed with a real user account, and that the app looks correct on mobile. Congratulations — you've built and published your first WeWeb app.