Kan een no-code SaaS-architectuur echt 100.000 maandelijks actieve gebruikers verwerken?

Ja. WeWeb + Xano + Supabase PostgreSQL is ontworpen voor deze schaal. Supabase PostgreSQL verwerkt miljarden rijen; Xano schaalt horizontaal; WeWeb wordt via CDN geleverd. Het kritieke punt is juiste datamodellering met indexen en Row-Level Security vanaf dag één — de architectuur zelf is niet de bottleneck.

Waarom is separation of concerns belangrijker in een no-code-stack dan in een traditionele stack?

In alles-in-één platforms zoals Bubble zijn frontend en backend strak gekoppeld, waardoor het onmogelijk is de lagen onafhankelijk te schalen. Met WeWeb + Xano + Supabase kun je de API-laag schalen zonder de frontend aan te raken, de database wisselen zonder bedrijfslogica te herschrijven, en één laag tegelijk migreren — precies zoals enterprise-architectuur op AWS of GCP, maar met no-code tools.

Hoe leg je de no-code architectuur uit aan technische investeerders zoals Peak Capital of Endeit Capital?

Benadruk dat het standaard PostgreSQL is (geen propriëtaire lock-in), REST API's (industriestandaard), en dat elke laag onafhankelijk kan worden vervangen. WeWeb kan worden vervangen door een React-frontend, Xano door een Node.js-backend, Supabase door elke PostgreSQL-host. Data wordt geëxporteerd met standaard SQL-dump. Dit is een antwoord dat sterk aanslaat bij technisch onderlegde investeerders.

Welke Nederlandse bedrijfsintegraties moeten in de Xano-laag voor een B2B SaaS?

De meest gevraagde voor de Nederlandse markt: Exact Online en Afas (boekhouding), BankID via proxy-API (authenticatie), iDEAL via Mollie (betalingen), en Brevo of SendGrid (transactionele e-mail). Door al deze integraties in Xano te houden als aparte utility-functies kun je ze onafhankelijk bijwerken zonder de frontendcode aan te raken.

No-Code SaaS Architectuur voor 100.000 Gebruikers

De kernarchitectuur: separation of concerns

De grootste fout in no-code SaaS is het gebruik van een alles-in-één platform (Bubble, Glide) waarbij frontend en backend strak gekoppeld zijn. Dit veroorzaakt drie problemen op schaal: prestaties verslechteren omdat je frontend en backend niet onafhankelijk kunt schalen, je data zit opgesloten in het platform, en je kunt elk onderdeel niet afzonderlijk optimaliseren.

De juiste architectuur scheidt verantwoordelijkheden: - Frontend: WeWeb (CDN-geleverd, onafhankelijk schaalbaar) - Bedrijfslogica: Xano (horizontaal schaalbaar API) - Database: Supabase (beheerde PostgreSQL, schaalt naar miljarden rijen) - Automatisering: Make of n8n (asynchrone taken, webhooks, notificaties)

Dit is dezelfde scheiding die technische teams gebruiken die SaaS op AWS of GCP bouwen — maar met no-code tools in plaats van custom code. Voor Nederlandse SaaS-bedrijven die enterprise-klanten targeten is deze architectuur ook een sterk argument in beveiligingsaudits: elk onderdeel kan onafhankelijk worden geaudit en gevalideerd, en data is opgeslagen in standaard PostgreSQL zonder proprietaire lock-in.

De databaselaag: PostgreSQL met RLS

Je datamodel is de belangrijkste architectuurbeslissing. Doe het goed en schaling is eenvoudig. Doe het fout en je moet herbouwen.

Kernprincipes voor een schaalbare no-code SaaS-database: 1. Elke tabel heeft created_at, updated_at en een primaire sleutel (bigserial) 2. Multi-tenancy via workspace_id foreign key op elke tabel 3. Row-Level Security-policies op elke gebruikergerichte tabel 4. Indexen op workspace_id, user_id, status, created_at 5. Sla nooit berekende waarden op in de database — bereken in Xano

Supabase PostgreSQL verwerkt dit uitstekend. RLS-policies zorgen ervoor dat je API-endpoints niet per ongeluk de data van een andere tenant kunnen retourneren — de database dwingt isolatie af. Vanuit een AVG-perspectief is dit een krachtig argument voor Nederlandse B2B-klanten: toegangscontrole is gegarandeerd op databaseniveau, niet alleen op applicatieniveau — een vereiste die veel DPO's (functionarissen voor gegevensbescherming) stellen bij leveranciersevaluaties.

De API-laag: Xano bedrijfslogica

Xano zit tussen je frontend en database. Elke gebruikersactie gaat via een Xano-endpoint, niet direct naar Supabase. Dit geeft je: - Invoervalidatie voordat de database wordt geraakt - Bedrijfslogica (prijsberekeningen, toestandsmachines, machtigingscontroles) - Third-party integraties (Stripe, Mollie, Exact Online, Brevo) op één plek - Auditlogging op API-niveau

Structureer je Xano-endpoints RESTful: GET /workspaces/:id/projects, POST /projects, PATCH /projects/:id. Vermijd RPC-stijl-endpoints. Houd endpoints klein en samengesteld.

Een patroon dat we consequent gebruiken: maak "utility"-functies in Xano per externe service — bijv. "Verwerk Stripe-debitering" of "Stuur welkomstmail via Brevo". Roep dan deze utilities aan vanuit je bedrijfslogicastack. Dit houdt de code overzichtelijk en maakt updates eenvoudiger. Voor Nederlandse SaaS-bedrijven zijn veelvoorkomende integraties Exact Online, Afas, iDEAL via Mollie, en BankID voor authenticatie.

De frontendlaag: WeWeb-prestaties

WeWeb genereert een echte webapplicatie: statische HTML/CSS/JS geleverd via CDN, met dynamische data opgehaald via REST API-aanroepen. Dit betekent: - Eerste lading is snel (CDN-gecachede statische assets) - Data wordt asynchroon geladen (geen server-side rendering bottleneck) - Frontend schaalt oneindig (het zijn gewoon bestanden op een CDN)

Voor prestaties op schaal: pagineer alle lijstquery's (max. 50 items per pagina), gebruik WeWeb's ingebouwde caching voor statische data, en lazy-load zware componenten.

Een onderschat voordeel: WeWeb genereert echte HTML, wat betekent dat je marketingpagina's en publieke pagina's correct worden geïndexeerd door Google. Voor Nederlandse SaaS-bedrijven die afhankelijk zijn van SEO voor klantenwerving — een veelgebruikte strategie op de Nederlandse markt — is dit een doorslaggevend voordeel vergeleken met Bubble, waarvan de Lighthouse-scores op mobiel typisch uitkomen op 40–55.

Authenticatie en multi-tenancy

Gebruik Supabase Auth voor gebruikersauthenticatie — het is bewezen betrouwbaar en gratis op het Free-niveau. De flow: 1. Gebruiker registreert/logt in via Supabase Auth 2. Supabase geeft een JWT af met user_id en workspace_id 3. WeWeb slaat JWT op, stuurt deze mee bij elk Xano API-verzoek 4. Xano valideert de JWT en extraheert de gebruikerscontext 5. Database-RLS-policies gebruiken auth.uid() om rij-niveau-isolatie af te dwingen

Voor multi-tenancy: maak een workspaces-tabel, een workspace_members-tabel (user_id, workspace_id, rol) en stuur workspace_id mee bij elk API-verzoek. Xano verifieert lidmaatschap voordat elke operatie wordt uitgevoerd.

Vergeet randgevallen niet: wat als een gebruiker lid is van meerdere workspaces? Hoe verwerk je e-mailuitnodigingen? Deze patronen zijn bekend en gedocumenteerd — heruitvind ze niet.

Wanneer upgraden naar custom code?

Deze architectuur schaalt comfortabel naar 100.000 MAU voor de meeste SaaS-typen. Daarboven kunnen specifieke bottlenecks optreden:

- Zeer hoge schrijffrequentie (>1.000 schrijfoperaties/seconde): Supabase beheerde PostgreSQL kan dedicated compute nodig hebben - Complexe realtime functies (multiplayer, live samenwerking): je wilt misschien custom WebSocket-infrastructuur - Custom LLM-inferentie: zelf-gehoste modellen vereisen custom infrastructuur

Voor 95% van SaaS-producten is deze architectuur meer dan voldoende op elke schaal. En wanneer je een laag moet migreren, kun je dat — je data is in standaard PostgreSQL, je API is REST, je frontendcode is van jou.

Dit is een belangrijk argument voor Nederlandse SaaS-bedrijven die plannen te verkopen aan Peak Capital, Endeit Capital of andere investeerders die technische due diligence uitvoeren. De architectuur heeft geen propriëtaire lock-in — elke laag kan onafhankelijk worden vervangen, en data kan worden geëxporteerd naar elke relationele database zonder conversie.