Kärnstacken
Frontend: WeWeb, pixelperfekt UI, ansluter till valfri backend, driftsätts på din egen domän via Cloudflare CDN.
Databas + Auth: Supabase, PostgreSQL, Row-Level Security, realtidsprenumerationer, fillagring.
Affärslogik + API: Xano, REST API-byggare, anpassad affärslogik, tredjepartsintegrationer, webhooks.
Betalningar: Stripe, prenumerationer, fakturor, webhooks tillbaka till Xano.
E-post: Resend eller SendGrid, transaktionella e-postmeddelanden utlösta av Xano.
Denna stack hanterar 10 000 MAU utan att svettas. Vi har kört den på 50 000 MAU utan infrastrukturändringar. För svenska SaaS-bolag som riktar sig mot nordiska B2B-kunder är detta en beprövad och vältestad grund.
Multi-tenancy med Supabase RLS
Varje tabell har en workspace_id-kolumn. Alla Row-Level Security-policyer filtrerar på workspace_id = auth.jwt() ->> 'workspace_id'.
Användare tillhör arbetsplatser via en workspace_members-tabell med en rollkolumn (owner, admin, member). När en användare loggar in innehåller JWT deras workspace_id och roll, Supabase tillämpar detta automatiskt på databasnivå.
Detta är det viktigaste arkitekturbeslutet i en B2B SaaS. Gör det rätt från dag 1. Vi har sett bolag som skippat detta i valideringsfasen och sedan behövt en fullständig databasmigrering när de fick sina första företagskunder, en kostsam process som App Studio gärna hjälper dig undvika.
Faktureringsarkitektur med Stripe
I Xano skapar du en webhooks-endpoint som tar emot Stripe-händelser. Hantera: checkout.session.completed (skapa prenumerationspost), customer.subscription.updated (uppdatera plan), invoice.payment_failed (begränsa åtkomst).
Lagra prenumerationsstatus i en workspace_settings-tabell. I WeWeb kontrollerar du prenumerationsstatus innan premium-funktioner renderas, och i Supabase RLS-policyer för databegränsningar.
Lita aldrig på frontenden för fakturerings-gates. Verifiera alltid i databasen. För svenska kunder som faktureras i SEK: Stripe stöder SEK-prissättning och automatisk momshantering för svenska moms (25 %), vilket förenklar redovisningen avsevärt.
Prestandaoptimering
Indexstrategi: indexera varje främmande nyckel, varje status/typ-kolumn som används i filter och varje kolumn du sorterar efter. I Supabase tar detta 2 minuter i SQL-redigeraren.
Paginering: alla listendpoints måste paginera. Returnera aldrig obegränsade frågor. Använd markörsbaserad paginering för realtidsdata (oändlig scroll) och offset för admintabeller.
Caching: Xano stöder svarscaching för endpoints som returnerar samma data för alla användare (offentligt innehåll, uppslagstabeller). Använd det aggressivt. En välcachad Xano-endpoint kan hantera tusentals anrop per sekund utan att belasta Supabase.
Övervakning och felhantering
Lägg till Sentry i din WeWeb-anpassade kod för frontend-fel. Xano loggar alla API-begäranden, exportera dem till Datadog eller använd Xanos inbyggda felövervakning.
För kritiska bakgrundsjobb (faktureringswebhooks, e-postutlösare), lägg till felnotiser till Slack via Make. Du bör veta om fel innan dina användare gör det.
Databas-övervakning: Supabase tillhandahåller insikter om frågerestanda. Granska långsamma frågor varje vecka. En vanlig orsak till prestandadegradation i tillväxtbolag är frågor som fungerar bra vid 100 rader men är katastrofalt långsamma vid 100 000, tidig indexering eliminerar detta problem.
Multi-tenancy-mönster: delad kontra isolerad databas
Det finns tre multi-tenancy-modeller: delad databas med RLS (alla kunder i samma tabeller, isolerade genom policyer), delad databas med separata scheman (varje kund har sitt eget PostgreSQL-schema), och separata databaser per kund. Den stora majoriteten av SaaS-appar med 10 000 användare eller färre bör använda den första modellen, delad databas med RLS. Den är enklast att bygga, billigast att driva, och Supabases RLS gör den genuint säker.
Separata scheman per kund (ofta kallat "schema-per-tenant") blir relevant när kunder har legitimt olika datastrukturer, sällsynt i praktiken. Separata databaser per kund är en enterprise-funktion som används när kunder kräver kontraktuella garantier för datalokalisering eller egna databasuppgifter. På App Studio implementerar vi modellen med delad databas och RLS för alla SaaS-produkter tills en kund har ett specifikt kontraktuellt krav på starkare isolering.
Den kritiska implementeringsdetaljen: varje INSERT måste explicit sätta workspace_id, och dina RLS WITH CHECK-policyer måste säkerställa att workspace_id matchar den autentiserade användarens arbetsplats. Om du missar detta på ens en endpoint kan en användare infoga data i en annan kunds arbetsplats. Vi validerar detta med en säkerhetstestsvit som skapar två testarbetsplatser och verifierar dataisolering över alla 50+ endpoints.
Principer för databasdesign i no-code SaaS
Databasschemat är grunden som allt annat vilar på. Dåliga schemabeslut i månad 1 orsakar eskalerande problem i månad 12. Den viktigaste principen: designa för dina frågor, inte för teoretisk normalisering. Om du alltid kommer att fråga projekt tillsammans med deras tillhörande arbetsplats och ägare, lagra workspace_id och owner_id direkt på projects-tabellen istället för att koppla via workspace_members varje gång.
Använd databasnivåbegränsningar som ett andra valideringslager. Foreign keys (project.workspace_id refererar till workspaces.id), not-null-begränsningar på obligatoriska fält, och check-begränsningar för enum-liknande värden (status IN ('active', 'paused', 'cancelled')). Dessa begränsningar fångar buggar i applikationslagret innan de korrumperar din data. Supabase upprätthåller dessa nativt, lägg till dem när du skapar dina tabeller, inte som en eftertanke.
För SaaS-fakturering, använd en dedikerad subscription-tabell istället för att lagra plandata direkt på workspace-tabellen. En prenumeration har en livscykel (trialing, active, past_due, cancelled) med tidsstämplar för varje tillståndsövergång. Att lagra detta som en separat entitet gör faktureringslogiken ren och ger dig en komplett granskningslogg, väsentligt för att lösa faktureringstvister och felsöka intäktsavvikelser.
Cachingstrategi: vad ska cachas och var
Caching i en no-code SaaS-stack fungerar på tre nivåer: Xano endpoint-caching (svarsnivå), Supabase materialiserade vyer (frågenivå), och WeWebs klientsidestillstånd (UI-nivå). Var och en tjänar ett annat syfte och har olika krav på ogiltigförklaring.
Xano endpoint-caching är lämpligt för data som är densamma för alla användare och sällan ändras: uppslagstabeller (landlistor, branschkategorier), offentliga prisplaner, feature flag-konfigurationer. Sätt en TTL på 5-60 minuter beroende på hur ofta datan ändras. Detta minskar databasbelastningen betydligt för endpoints som anropas vid varje sidladdning.
Supabase materialiserade vyer är rätt verktyg för dyra aggregeringsfrågor: användningsmått på arbetsplatsnivå, månadsrapportdata, topplistberäkningar. Uppdatera dem enligt ett schema (var 15:e minut för nästan realtidsdashboards, en gång per dag för faktureringsrapporter) med Supabases cron-tillägg. Vi har minskat laddningstiden för dashboards med 10x på analystunga SaaS-appar genom att flytta aggregeringar till materialiserade vyer.
WeWebs klientsidescaching via dess inbyggda variabellager minskar redundanta API-anrop inom en session. Cacha den nuvarande användarens arbetsplatsinställningar, prenumerationsstatus och feature flags vid inloggning, dessa behövs på varje sida och ändras inte under sessionen. Ogiltigförklara cachen vid utloggning och planuppgradering.
Bakgrundsjobb: mönster för asynkron bearbetning
Varje operation som tar mer än 500ms bör vara asynkron. I en no-code SaaS-stack körs bakgrundsjobb i Xanos task queue, utlösta via Make.com- eller n8n-schemaläggare, eller via Supabase Edge Functions utlösta av databasändringar.
De vanligaste bakgrundsjobben i SaaS-produkterna vi bygger: bearbetning av prenumerationsförnyelse (kontrollera alla arbetsplatser med förnyelser som förfaller idag, debitera Stripe, uppdatera prenumerationsstatus, skicka kvittomejl), generering av dataexport (användaren begär en CSV-export, jobbet genererar den och mejlar en nedladdningslänk, blockera aldrig UI:t för detta), tredjepartssynkronisering (skicka nya CRM-kontakter till HubSpot, synkronisera kalenderhändelser till Google Calendar), och användningsmätning (aggregera API-anrop eller funktionsanvändning per timme för fakturering).
Felhantering för bakgrundsjobb kräver mer omsorg än synkrona endpoints, det finns ingen användare som väntar på ett svar. Varje jobb bör: logga sin start och sitt slut, fånga alla fel och skriva dem till en job_errors-tabell, skicka en Slack-notis vid fel, och implementera exponentiell backoff-återförsökslogik för tillfälliga fel (nätverksfel, rate limits). Xanos task queue hanterar återförsök nativt; för Make.com-utlösta jobb, implementera återförsökslogik i scenariot.
Övervaka en no-code SaaS i produktion
Produktionsövervakning utan ett DevOps-team kräver att man väljer rätt verktyg och automatiserar larm. För stacken vi använder är den minimala fungerande övervakningsuppsättningen: Sentry för frontend-fel (WeWeb-anpassad kodintegration), Xanos inbyggda begäranloggar med felnotifiering, Supabases insikter om databasprestanda och övervakning av connection pool, samt Stripes dashboard för betalningsfelfrekvenser.
Utöver felövervakning, spåra affärsnivåns hälsomått: dagligen aktiva användare (fråga Supabase), fördelning av API-svarstid (exportera Xano-loggar), misslyckade inloggningsförsök (potentiella säkerhetshändelser), och prenumerationsbortfall (Stripe-webhooks → Supabase → en enkel rapporteringsvy). Sätt upp veckovisa automatiserade rapporter som mejlar dessa mått till grundaren, de flesta problem blir synliga som trendförändringar innan de blir kriser.
För SaaS-appar över 5 000 MAU, lägg till drifttidsövervakning via Better Uptime eller Pingdom på dina kritiska endpoints (inloggning, kärnarbetsflöde). Larma till Slack inom 2 minuter efter driftstopp. Vid denna användarmängd genererar även ett 10-minuters avbrott under kontorstid en betydande supportvolym. Kostnaden för drifttidsövervakning (20-50 €/månad) är trivialt motiverad.