What "No-Code Stack" Means for SaaS

A "stack" is the collection of tools that, together, constitute your entire application. In traditional software development, this means choosing a frontend framework (React, Vue), a backend language (Node, Python), and a database (PostgreSQL, MySQL). Each layer is distinct, and engineers write code to connect them.

In no-code SaaS development, the same architectural principle applies — but each layer is a visual tool instead of raw code. You still need a frontend builder, a data layer, and a logic layer. What changes is that configuration and visual design replace hundreds of lines of boilerplate code.

The mistake many founders make is assuming that "no-code" means "one tool." It doesn't. Single-tool platforms like Bubble force all three layers into one product, which creates lock-in, performance ceilings, and scaling problems. A properly composed no-code stack separates concerns exactly as a code-based stack would.

Why Frontend-Backend Separation Matters

Separation of concerns is one of the oldest principles in software engineering, and it applies with full force to no-code SaaS. When your frontend and backend are the same tool (as they are in Bubble), you can't independently scale, update, or replace either layer.

In our stack, WeWeb is purely the UI layer. It knows nothing about business logic or data storage. Supabase handles data persistence and auth. Xano handles complex backend workflows. Each layer can be upgraded, replaced, or scaled without touching the others. If a better frontend tool emerges in two years, we migrate the UI without rewriting the database. If Xano's pricing changes, we swap the logic layer without rebuilding the frontend.

This independence also means your team can work in parallel. A designer iterates on WeWeb layouts while a backend engineer builds Xano endpoints. With Bubble, every change touches the same system, creating merge conflicts and deployment risk.

WeWeb Explained: The Frontend Layer

WeWeb is a visual frontend builder that outputs production-quality web applications. Unlike page builders such as Webflow (which generates mostly static HTML), WeWeb is built specifically for data-driven interfaces. Every element can be bound to live data from an API, a Supabase table, or a Xano endpoint.

WeWeb's key strengths for SaaS: native Supabase authentication integration (email/password, magic link, OAuth), conditional rendering based on user roles, repeating components that map over API data, and real-time Supabase subscriptions for live-updating dashboards. It exports clean Vue.js code, which means you can always hand the project off to a developer if you outgrow the visual builder.

WeWeb is also certified by its own partner programme, which App Studio holds. This matters because WeWeb's capabilities are complex — a certified agency will use advanced features (custom components, plugin extensions, proper data binding patterns) that an uncertified builder will miss, resulting in performance issues and brittle UIs.

Supabase Explained: The Database and Auth Layer

Supabase is an open-source Firebase alternative built on PostgreSQL — the world's most battle-tested relational database. Unlike Firebase's document model (which makes relational queries painful), Supabase gives you full SQL with foreign keys, joins, views, and stored procedures. This matters enormously for SaaS, where your data model is usually relational.

Supabase provides three critical services in our stack: (1) PostgreSQL database with a visual table editor, (2) Row-Level Security for multi-tenant data isolation, and (3) GoTrue authentication handling JWTs, sessions, and OAuth providers. You get all three in a single service that's SOC 2 Type II certified, offers EU data residency, and has a generous free tier.

Critically, Supabase is open-source and self-hostable. Your client data never has to leave EU jurisdiction. For European SaaS founders, this is non-negotiable for GDPR compliance. Firebase, by contrast, stores data in Google's US infrastructure by default — a legal grey area for EU user data that we've seen cause issues in due diligence.

Xano Explained: The Business Logic Layer

Xano is a no-code backend builder that lets you create REST APIs with complex business logic through a visual workflow editor. Where Supabase handles data storage and simple CRUD operations, Xano handles the rules that govern your application: pricing calculations, approval workflows, third-party API integrations, data transformation pipelines, and webhook handling.

Think of Xano as your backend engineer who never sleeps and never complains about complex requirements. You build a "Function Stack" — a visual sequence of operations that run when an API endpoint is called. Each step can query a database, call an external API, run conditional logic, loop over arrays, send emails, or transform data. No JavaScript required.

For simpler SaaS products (under ~100 endpoints, minimal business logic), Supabase Edge Functions can replace Xano entirely. We recommend introducing Xano when: you have complex workflows that span multiple systems, your logic involves more than 3-4 steps, or you need a non-technical team member to be able to read and modify the logic without touching code.

How the Three Tools Work Together

The data flow in production works like this: A user opens your WeWeb app in their browser. WeWeb authenticates them against Supabase Auth, which returns a JWT. For data reads, WeWeb queries Supabase directly via its JavaScript client — this is fast, direct, and doesn't add latency. Supabase's Row-Level Security policies ensure the user only sees their own organisation's data, enforced at the database level.

For writes that involve business logic (creating an invoice, processing an approval, triggering a third-party integration), WeWeb calls a Xano API endpoint instead. Xano receives the JWT, validates it against Supabase, executes the workflow — which might update Supabase, call Stripe, send a Postmark email, and log the action to an audit table — and returns a result to WeWeb.

The key architectural insight: reads go directly to Supabase (fast, cheap), writes with logic go through Xano (controlled, auditable). This pattern gives you the performance of a direct database connection for common operations while keeping complex mutations behind a proper API layer with validation, error handling, and observability.

Performance Benchmark: This Stack vs Bubble vs Firebase

Across the 50+ products we've shipped, WeWeb + Supabase + Xano consistently delivers sub-500ms dashboard load times once authenticated. Supabase's PostgreSQL with proper indexing handles 10,000 concurrent users on a $25/month Pro plan. Xano's API endpoints typically respond in 100-300ms for standard business logic.

Bubble, by contrast, runs all frontend rendering server-side. Every page navigation is a server round-trip. Bubble apps under moderate load (500+ concurrent users) visibly slow down — a known limitation of Bubble's architecture. The Bubble team is working on this with their new "Bubble Native" rendering mode, but it's not yet production-ready for complex apps.

Firebase is fast for simple document reads, but its lack of relational queries means complex SaaS data models require denormalization (duplicating data), which creates consistency problems. Firebase also doesn't offer EU data residency on its free and standard tiers, making it problematic for European SaaS companies from day one.

Cost Comparison Over 3 Years

For a typical B2B SaaS with 1,000 MAU, here's how the numbers stack up. WeWeb: $49-149/month depending on team size. Supabase: $25/month Pro covers most early-stage SaaS. Xano: $60-100/month. Total stack cost: ~$135-275/month, or $4,900-9,900 over 3 years.

Bubble for the same product: $349-529/month (Starter to Growth), plus $50-200/month in plugin licences that Bubble requires for features that are free in our stack. Total: $15,000-27,000 over 3 years. And Bubble pricing scales with capacity units — as your users grow, costs can escalate unpredictably.

Firebase: free at low volume, then Google Cloud pricing applies. At 1,000 MAU with active use, Firebase typically runs $50-150/month. But you'll pay more in Xano or a custom backend, since Firebase provides no business logic layer. Building that in Cloud Functions (Google's serverless) requires real development skills and ongoing maintenance costs.

Real Client Case Study: Fintech SaaS, 6 Weeks, 2,000 MAU Day One

One of our most instructive projects was a B2B expense management SaaS for European SMEs. The client had a full feature spec — multi-user organisations, expense submission workflows, approval chains, accounting software integration, and a Stripe billing layer with per-seat pricing. Previous developers had quoted 6-9 months and €120,000+.

We delivered a fully functional production app in 6 weeks for a fraction of that cost. Week 1: data model in Supabase, RLS policies, auth. Weeks 2-3: WeWeb dashboard UI — expense submission form, manager approval view, admin organisation management. Weeks 4-5: Xano workflows for approval routing, Slack notifications, Pennylane accounting API integration. Week 6: Stripe billing, QA, documentation.

Day one after launch: 2,000 MAU from the client's existing customer base. Supabase handled the load without configuration changes. Six months post-launch, the product operates with zero infrastructure incidents, and the client's team manages content updates in WeWeb without developer involvement. This is what a properly composed no-code stack delivers.

When This Stack Is NOT the Right Choice

We believe in recommending the right tool for the job, even when it means pointing clients elsewhere. This stack is not ideal in three specific scenarios.

First: real-time collaborative editing (think Figma, Google Docs). Supabase real-time handles broadcasting state changes well, but Conflict-free Replicated Data Types (CRDTs) for true simultaneous editing require specialised infrastructure. For this use case, consider Liveblocks or a custom backend.

Second: purely mobile-first consumer apps. WeWeb produces excellent web apps and PWAs, but if your primary distribution is the iOS App Store and you need hardware features (Bluetooth, NFC, background geolocation), a FlutterFlow native app is the better choice. We use FlutterFlow for these projects.

Third: very simple landing-page businesses. If you're building a glorified contact form with a CMS, WeWeb + Supabase is overkill. Webflow is faster and cheaper for content-only sites. We always right-size the tool to the actual requirements — over-engineering a simple site is as bad as under-engineering a complex one.