Kan een no-code-stack echt 10.000 actieve gebruikers verwerken?

Ja. WeWeb + Supabase + Xano zijn geen prototype-tools, het is productie-infrastructuur. WeWeb wordt geserveerd via Cloudflare CDN, Supabase is gebouwd op PostgreSQL met professionele schaalbaarheid en Xano schaalt automatisch zonder infrastructuurbeheer. We hebben apps gedraaid met 50.000 MAU op deze stack zonder architectuurwijzigingen te hoeven maken.

Hoe implementeer je Stripe-betalingen voor Nederlandse klanten die in euro's worden gefactureerd?

Stripe ondersteunt EUR-prijzen en automatische BTW-verwerking voor Nederlandse BTW (21%). Stripe-webhooks worden verwerkt in Xano, je luistert naar events zoals checkout.session.completed en customer.subscription.updated en werkt je Supabase-database realtime bij. Stripe verwerkt ook BTW-rapportage automatisch voor Europese klanten, wat de boekhouding aanzienlijk vereenvoudigt.

Welke indexen moet je instellen in Supabase om prestatieproblemen bij groei te voorkomen?

Indexeer altijd elke foreign key (workspace_id, user_id), elke status- of typekolom die wordt gebruikt in filters en elke kolom waarop je sorteert (created_at). In Supabase SQL-editor duurt dit letterlijk 2 minuten. Zonder deze indexen zijn queries die goed werken bij 100 rijen vaak rampzalig langzaam bij 100.000, een probleem dat typisch optreedt rond 500-1.000 actieve klanten.

Hoe structureer je een no-code SaaS zodat het verkoopbaar is bij een exit?

De stack die we beschrijven, WeWeb + Supabase + Xano, is overdraagbaar. Data woont in standaard PostgreSQL, de API is REST en de frontend is gehost op je eigen domein. Voor een overname, zoals een Benelux techbedrijf of private equity-fonds, is dit een schone technische overdracht. In tegenstelling tot propriëtaire platforms als Bubble, waar data is opgesloten, is de overdraagbaarheid een duidelijk due diligence-argument.

No-Code SaaS Architectuur

De kernstack

Frontend: WeWeb, pixel-perfecte UI, verbindt met elke backend, gedeployed op je eigen domein via Cloudflare CDN.

Database + Auth: Supabase, PostgreSQL, Row-Level Security, realtime-subscriptions, bestandsopslag.

Bedrijfslogica + API: Xano, REST API-builder, aangepaste bedrijfslogica, integraties met derden, webhooks.

Betalingen: Stripe, abonnementen, facturen, webhooks terug naar Xano.

E-mail: Resend of SendGrid, transactionele e-mails geactiveerd door Xano.

Deze stack verwerkt 10.000 MAU zonder moeite. We hebben hem gedraaid op 50.000 MAU zonder infrastructuurwijzigingen. Je kunt een WeWeb-ontwikkelaar inhuren die gespecialiseerd is in precies deze stack.

Multi-tenancy met Supabase RLS

Elke tabel heeft een workspace_id-kolom. Alle Row-Level Security-beleidsregels filteren op workspace_id = auth.jwt() ->> 'workspace_id'.

Gebruikers behoren tot workspaces via een workspace_members-tabel met een rolkolom (owner, admin, member). Wanneer een gebruiker inlogt, bevat de JWT hun workspace_id en rol, Supabase past dit automatisch toe op databaseniveau.

Dit is de belangrijkste architectuurbeslissing in een B2B SaaS. Doe het goed vanaf dag 1.

Factureringsarchitectuur met Stripe

In Xano maak je een webhooks-endpoint dat Stripe-events ontvangt. Verwerk: checkout.session.completed (maak abonnementsrecord aan), customer.subscription.updated (bijwerken plan), invoice.payment_failed (toegang beperken).

Sla abonnementsstatus op in een workspace_settings-tabel. In WeWeb controleer je abonnementsstatus voordat premium-functies worden weergegeven, en in Supabase RLS-beleidsregels voor databasebeperkingen.

Vertrouw nooit op de frontend voor factureringscontroles. Verifieer altijd in de database.

Prestatieoptimalisatie

Indexstrategie: indexeer elke foreign key, elke status/type-kolom die wordt gebruikt in filters en elke kolom waarop je sorteert. In Supabase duurt dit 2 minuten in de SQL-editor.

Paginering: alle lijst-endpoints moeten pagineren. Retourneer nooit onbeperkte query's. Gebruik cursor-gebaseerde paginering voor realtime-data (oneindig scrollen) en offset voor admintabellen.

Caching: Xano ondersteunt respons-caching voor endpoints die dezelfde data retourneren voor alle gebruikers (openbare inhoud, opzoektabellen). Gebruik dit agressief.

Monitoring en foutafhandeling

Voeg Sentry toe aan je WeWeb aangepaste code voor frontend-fouten. Xano logt alle API-verzoeken, exporteer ze naar Datadog of gebruik Xano's ingebouwde foutmonitoring.

Voor kritieke achtergrondtaken (facturering webhooks, e-mailactivators) voeg foutmeldingen toe aan Slack via Make. Je moet op de hoogte zijn van fouten voordat je gebruikers dat zijn.

Databasemonitoring: Supabase biedt inzichten in queryprestaties. Bekijk langzame queries elke week.

Multi-tenancy patronen: gedeelde vs geïsoleerde databases

Er zijn drie multi-tenancy-modellen: een gedeelde database met RLS (alle tenants in dezelfde tabellen, geïsoleerd via policies), een gedeelde database met aparte schema's (elke tenant heeft zijn eigen PostgreSQL-schema), en aparte databases per tenant. De overgrote meerderheid van SaaS-apps met 10.000 gebruikers of minder zou het eerste model moeten gebruiken: een gedeelde database met RLS. Het is het eenvoudigst te bouwen, het goedkoopst in gebruik, en de RLS van Supabase maakt het oprecht veilig.

Aparte schema's per tenant (vaak "schema-per-tenant" genoemd) wordt relevant wanneer tenants legitiem verschillende datastructuren hebben, in de praktijk zeldzaam. Aparte databases per tenant is een enterprise-functie die wordt gebruikt wanneer tenants contractuele garanties voor dataresidentie of hun eigen databasecredentials vereisen. Bij App Studio implementeren we het model van een gedeelde database met RLS voor alle SaaS-producten, totdat een klant een specifieke contractuele vereiste heeft voor sterkere isolatie.

Het cruciale implementatiedetail: elke INSERT moet workspace_id expliciet instellen, en je RLS WITH CHECK-policies moeten afdwingen dat workspace_id overeenkomt met de workspace van de geauthenticeerde gebruiker. Mis je dit op ook maar één endpoint, dan zou een gebruiker data kunnen invoegen in de workspace van een andere tenant. We valideren dit met een securitytestsuite die twee testworkspaces aanmaakt en data-isolatie verifieert over alle 50+ endpoints.

Principes voor databaseontwerp bij no-code SaaS

Het databaseschema is het fundament waarop al het andere rust. Slechte schemabeslissingen in maand 1 veroorzaken oplopende pijn in maand 12. Het belangrijkste principe: ontwerp voor je queries, niet voor theoretische normalisatie. Vraag je altijd projecten op samen met hun bijbehorende workspace en eigenaar, sla dan workspace_id en owner_id direct op in de projects-tabel in plaats van elke keer via workspace_members te joinen.

Gebruik constraints op databaseniveau als een tweede validatielaag. Foreign keys (project.workspace_id verwijst naar workspaces.id), not-null-constraints op verplichte velden, en check-constraints voor enum-achtige waarden (status IN ('active', 'paused', 'cancelled')). Deze constraints vangen bugs in je applicatielaag op voordat ze je data corrumperen. Supabase handhaaft dit native, voeg ze toe zodra je je tabellen aanmaakt, niet als bijgedachte achteraf.

Gebruik voor SaaS-facturering een aparte subscriptions-tabel in plaats van plandata direct op de workspace-tabel op te slaan. Een abonnement heeft een levenscyclus (trialing, active, past_due, cancelled) met tijdstempels voor elke statusovergang. Dit als aparte entiteit opslaan houdt de factureringslogica overzichtelijk en geeft je een compleet audit trail, essentieel voor het oplossen van factureringsgeschillen en het debuggen van omzetafwijkingen.

Cachingstrategie: wat je waar cachet

Caching in een no-code SaaS-stack werkt op drie niveaus: Xano endpoint-caching (op responsniveau), Supabase materialized views (op queryniveau), en WeWeb client-side state (op UI-niveau). Elk niveau dient een ander doel en heeft andere invalidatievereisten.

Xano endpoint-caching is geschikt voor data die voor alle gebruikers hetzelfde is en zelden verandert: opzoektabellen (landenlijsten, branchecategorieën), openbare prijsplannen, feature-flag-configuraties. Stel een TTL van 5-60 minuten in, afhankelijk van hoe vaak de data verandert. Dit vermindert de databasebelasting aanzienlijk voor endpoints die bij elke paginalading worden aangeroepen.

Supabase materialized views zijn het juiste gereedschap voor dure aggregatiequery's: gebruiksstatistieken op workspace-niveau, maandelijkse rapportagedata, leaderboard-berekeningen. Vernieuw ze volgens een schema (elke 15 minuten voor bijna-realtime dashboards, eenmaal per dag voor factureringsrapporten) met de cron-extensie van Supabase. We hebben de laadtijd van dashboards bij analytics-zware SaaS-apps met een factor 10 verminderd door aggregaties naar materialized views te verplaatsen.

WeWeb client-side caching via de ingebouwde variabelenopslag vermindert overbodige API-aanroepen binnen een sessie. Cache de workspace-instellingen, abonnementsstatus en feature flags van de huidige gebruiker bij het inloggen, deze zijn nodig op elke pagina en veranderen niet halverwege de sessie. Maak de cache ongeldig bij uitloggen en planupgrade.

Achtergrondtaken: patronen voor asynchrone verwerking

Elke operatie die langer dan 500ms duurt, zou asynchroon moeten zijn. In een no-code SaaS-stack draaien achtergrondtaken in de taakwachtrij van Xano, geactiveerd via Make.com- of n8n-schedulers, of via Supabase Edge Functions die worden geactiveerd door databasewijzigingen.

De meest voorkomende achtergrondtaken in de SaaS-producten die wij bouwen: verwerking van abonnementsverlengingen (controleer alle workspaces met verlengingen die vandaag verschuldigd zijn, belast Stripe, werk de abonnementsstatus bij, stuur een ontvangstbevestiging), het genereren van data-exports (gebruiker vraagt een CSV-export aan, de taak genereert deze en e-mailt een downloadlink, blokkeer de UI hier nooit voor), synchronisatie met derden (nieuwe CRM-contacten pushen naar HubSpot, agenda-events synchroniseren met Google Agenda), en gebruiksmeting (API-aanroepen of functiegebruik per uur aggregeren voor facturering).

Foutafhandeling voor achtergrondtaken vereist meer zorgvuldigheid dan synchrone endpoints, er is geen gebruiker die op een reactie wacht. Elke taak moet: het begin en einde loggen, alle fouten opvangen en wegschrijven naar een job_errors-tabel, een Slack-melding sturen bij fouten, en exponential-backoff-retrylogica implementeren voor tijdelijke fouten (netwerkfouten, rate limits). De taakwachtrij van Xano handelt retries native af; voor via Make.com geactiveerde taken implementeer je de retrylogica in het scenario.

Een no-code SaaS monitoren in productie

Productiemonitoring zonder een DevOps-team vereist het kiezen van de juiste tools en het automatiseren van meldingen. Voor de stack die wij gebruiken, is de minimaal noodzakelijke monitoringopzet: Sentry voor frontend-fouten (integratie via WeWeb aangepaste code), de ingebouwde requestlogs van Xano met foutmeldingen, de database-performance-inzichten en connection-pool-monitoring van Supabase, en het dashboard van Stripe voor mislukte betalingspercentages.

Volg naast foutmonitoring ook gezondheidsstatistieken op bedrijfsniveau: dagelijks actieve gebruikers (query op Supabase), verdeling van API-responstijden (export van Xano-logs), mislukte inlogpogingen (mogelijke beveiligingsincidenten), en churn-percentage van abonnementen (Stripe-webhooks → Supabase → een eenvoudige rapportageweergave). Stel wekelijkse geautomatiseerde rapporten in die deze statistieken naar de founder e-mailen, de meeste problemen worden zichtbaar als trendveranderingen voordat ze crises worden.

Voeg voor SaaS-apps boven 5.000 MAU uptime-monitoring toe via Better Uptime of Pingdom op je kritieke endpoints (login, kernworkflow). Stuur binnen 2 minuten na uitval een Slack-melding. Bij dit aantal gebruikers genereert zelfs een uitval van 10 minuten tijdens kantooruren aanzienlijk supportvolume. De kosten van uptime-monitoring (€20-€50/maand) zijn triviaal te rechtvaardigen.

No-Code SaaS Architectuur: WeWeb + Supabase + Xano