Kärnarkitekturen: separation of concerns

Det största misstaget i no-code SaaS är att använda en allt-i-ett-plattform (Bubble, Glide) där frontend och backend är tätt kopplade. Det orsakar tre problem i skala: prestanda försämras eftersom du inte kan skala frontend och backend oberoende av varandra, din data är inlåst i plattformen, och du kan inte optimera varje lager separat.

Rätt arkitektur separerar ansvarsområden: - Frontend: WeWeb (CDN-levererat, oberoende skalbart) - Affärslogik: Xano (horisontellt skalbart API) - Databas: Supabase (hanterad PostgreSQL, skalar till miljarder rader) - Automatisering: Make eller n8n (asynkrona jobb, webhooks, notifikationer)

Detta är samma separation som används av tekniska team som bygger SaaS på AWS eller GCP — men med no-code-verktyg istället för custom-kod. För svenska SaaS-bolag som riktar sig mot enterprise-kunder är denna arkitektur också ett starkt argument i säkerhetsgranskningar: varje lager kan granskas och valideras oberoende, och data lagras i standard PostgreSQL utan proprietär inlåsning.

Databaslagret: PostgreSQL med RLS

Din datamodell är det viktigaste arkitekturbeslutet. Gör det rätt och skalning är enkelt. Gör det fel och du måste bygga om.

Nyckelprinciper för en skalbar no-code SaaS-databas: 1. Varje tabell har created_at, updated_at och en primärnyckel (bigserial) 2. Multi-tenant via workspace_id-främmande nyckel på varje tabell 3. Row-Level Security-policyer på varje användarvänlig tabell 4. Index på workspace_id, user_id, status, created_at 5. Lagra aldrig beräknade värden i databasen — beräkna i Xano

Supabase PostgreSQL hanterar detta utmärkt. RLS-policyer innebär att dina API-endpoints inte av misstag kan returnera en annan tenants data — databasen upprätthåller isolering. Ur ett GDPR- och Schrems II-perspektiv är detta ett kraftfullt argument för svenska B2B-kunder: dataåtkomstkontroll är garanterad på databasnivå, inte bara på applikationsnivå, vilket är ett krav som många svenska företags DPO:er (dataskyddsombud) ställer vid leverantörsutvärderingar.

Suddiga gränsdragningar i datamodellen är den vanligaste orsaken till ombyggnader. Investera tid i att modellera din data korrekt innan du bygger ett enda API-endpoint.

API-lagret: Xano affärslogik

Xano sitter mellan din frontend och databas. Varje användaråtgärd går genom ett Xano-endpoint, inte direkt till Supabase. Det ger dig: - Inmatningsvalidering innan databashit - Affärslogik (prisberäkningar, tillståndsmaskiner, behörighetskontroller) - Tredjepartsintegrationer (Stripe, SendGrid, Twilio) på ett ställe - Granskningsloggning på API-nivå

Strukturera dina Xano-endpoints RESTfully: GET /workspaces/:id/projects, POST /projects, PATCH /projects/:id. Undvik RPC-stil-endpoints. Håll endpoints små och kompositbara.

Ett mönster vi konsekvent använder: skapa "utility"-funktioner i Xano per extern tjänst — t.ex. "Skicka Stripe-debitering" eller "Skicka välkomstmail via Brevo". Anropa sedan dessa utilities från din affärslogikstack. Det håller koden ren och underlättar uppdateringar. För svenska SaaS-bolag är vanliga integrationer Fortnox (bokföring), Visma, BankID (via proxy-API), Kivra och Swish — Xano hanterar alla dessa utan specialkod.

Frontendlagret: WeWeb-prestanda

WeWeb genererar en riktig webbapp: statisk HTML/CSS/JS levererad via CDN, med dynamisk data hämtad via REST API-anrop. Det innebär: - Första inladdning är snabb (CDN-cachade statiska tillgångar) - Data laddas asynkront (ingen server-side rendering-flaskhals) - Frontend skalar oändligt (det är bara filer på ett CDN)

För prestanda i skala: paginera alla listfrågor (max 50 objekt per sida), använd WeWebs inbyggda caching för statisk data och lazy-ladda tunga komponenter.

Ett underskattat fördeldraget: WeWeb genererar riktig HTML, vilket innebär att dina marknadsföringssidor och publika sidor indexeras korrekt av Google. För svenska SaaS-bolag som förlitar sig på SEO för kundförvärv — en vanlig strategi på den nordiska marknaden där annonspriser är höga — är detta en avgörande fördel jämfört med Bubble vars Lighthouse-poäng på mobil typiskt landar på 40-55. WeWebs CDN-leverans ger också märkbart snabbare laddningstider för användare i Norden och Europa, vilket påverkar konverteringsfrekvensen positivt.

Autentisering och multi-tenancy

Använd Supabase Auth för användarautentisering — det är battle-tested och gratis på Free-nivån. Flödet: 1. Användare registrerar sig/loggar in via Supabase Auth 2. Supabase utfärdar en JWT med user_id och workspace_id 3. WeWeb lagrar JWT:n, skickar den med varje Xano API-förfrågan 4. Xano validerar JWT:n och extraherar användarkontexten 5. Databas-RLS-policyer använder auth.uid() för att upprätthålla rad-nivå-isolering

För multi-tenancy: skapa en workspaces-tabell, en workspace_members-tabell (user_id, workspace_id, roll) och skicka workspace_id med varje API-förfrågan. Xano verifierar medlemskap innan varje operation.

Glöm inte att hantera kantfall: vad händer om en användare är medlem i flera workspaces? Hur hanterar du e-postinbjudningar? Dessa mönster är välkända och dokumenterade — återuppfinn dem inte. Supabase har officiell dokumentation för multi-tenant-mönster med RLS som täcker de vanligaste scenarierna.

När ska du uppgradera till custom-kod?

Denna arkitektur skalar bekvämt till 100 000 MAU för de flesta SaaS-typer. Utöver det kan specifika flaskhalsar uppstå:

- Mycket högt skrivflöde (>1 000 skrivningar/sekund): Supabase hanterade PostgreSQL kan behöva dedikerad compute - Komplexa realtidsfunktioner (multiplayer, live-samarbete): du kanske vill ha anpassad WebSocket-infrastruktur - Anpassad LLM-inferens: självhostade modeller kräver anpassad infrastruktur

För 95 % av SaaS-produkter är denna arkitektur mer än tillräcklig i vilken skala som helst. Och när du behöver migrera ett lager kan du göra det — din data är i standard PostgreSQL, ditt API är REST, din frontend-kod är din egen.

Detta är ett viktigt argument för svenska SaaS-bolag som planerar att sälja till Nordic Capital, EQT, Northzone eller liknande investerare som ställer tekniska due diligence-frågor. Arkitekturen har ingen proprietär inlåsning — varje lager kan bytas ut oberoende, och data kan exporteras till valfri relationsdatabas utan konvertering.