No-Code SaaS Architecture That Scales to 100K Users

Most no-code SaaS tutorials show you how to build a prototype. This post shows you how to build a production SaaS that scales to 100K monthly active users — with the same no-code stack. The architecture decisions are different. Here is what they are.

The Core Architecture: Separation of Concerns

The biggest mistake in no-code SaaS is using an all-in-one platform (Bubble, Glide) where your frontend and backend are tightly coupled. This causes three problems at scale: performance degrades because you can't independently scale the frontend and backend, your data is locked inside the platform, and you can't optimise each layer independently.

The right architecture separates concerns:
- Frontend: WeWeb (CDN-delivered, independently scalable)
- Business Logic: Xano (horizontally scalable API)
- Database: Supabase (managed PostgreSQL, scales to billions of rows)
- Automation: Make or n8n (async jobs, webhooks, notifications)

The Database Layer: PostgreSQL with RLS

Your data model is the most important architectural decision. Get it right and scaling is easy. Get it wrong and you'll rebuild.

Key principles for a scalable no-code SaaS database:
1. Every table has created_at, updated_at, and a primary key (bigserial)
2. Multi-tenancy via workspace_id foreign key on every table
3. Row-Level Security policies on every user-facing table
4. Indexes on workspace_id, user_id, status, created_at
5. Never store computed values in the database — compute in Xano

Supabase PostgreSQL handles this beautifully. RLS policies mean your API endpoints can't accidentally return another tenant's data — the database enforces isolation.

The API Layer: Xano Business Logic

Xano sits between your frontend and database. Every user action goes through a Xano endpoint, not directly to Supabase. This gives you:
- Input validation before hitting the database
- Business logic (pricing calculations, state machines, permission checks)
- Third-party integrations (Stripe, SendGrid, Twilio) in one place
- Audit logging at the API layer

Structure your Xano endpoints RESTfully. GET /workspaces/:id/projects, POST /projects, PATCH /projects/:id. Avoid RPC-style endpoints. Keep endpoints small and composable.

The Frontend Layer: WeWeb Performance

WeWeb generates a proper web app: static HTML/CSS/JS delivered via CDN, with dynamic data fetched via REST API calls. This means:
- First load is fast (CDN-cached static assets)
- Data loads asynchronously (no server-side rendering bottleneck)
- The frontend scales infinitely (it's just files on a CDN)

For performance at scale: paginate all list queries (max 50 items per page), use WeWeb's built-in caching for static data, and lazy-load heavy components.

Authentication & Multi-Tenancy

Use Supabase Auth for user authentication (it's battle-tested and free). The flow:
1. User signs up / logs in via Supabase Auth
2. Supabase issues a JWT with user_id and workspace_id
3. WeWeb stores the JWT, sends it with every Xano API request
4. Xano validates the JWT and extracts the user context
5. Database RLS policies use auth.uid() to enforce row-level isolation

For multi-tenancy: create a workspaces table, a workspace_members table (user_id, workspace_id, role), and pass workspace_id in every API request. Xano verifies membership before any operation.

When to Upgrade to Custom Code

This architecture scales comfortably to 100K MAU for most SaaS types. Beyond that, specific bottlenecks may emerge:

- Very high write throughput (>1000 writes/second): Supabase's managed PostgreSQL may need dedicated compute
- Complex real-time features (multiplayer, live collaboration): you may want custom WebSocket infrastructure
- Custom LLM inference: self-hosted models need custom infrastructure

For 95% of SaaS products, this architecture is more than sufficient at any scale. And when you do need to migrate a layer, you can — your data is in standard PostgreSQL, your API is REST, your frontend code is your own.