Har du noensinne prøvd å bygge en SaaS-applikasjon og så kommet til punktet der du må skille data mellom kunder? Det er ikke bare teknisk utfordrende - det er kritisk. Feil her kan føre til at en kunde ser data fra en annen. Og i verste fall: en straffesak. Når du bruker vibe coding - der du bare beskriver hva du vil, og AI genererer koden - blir det enda vanskeligere. Fordi AI ikke vet hva du ikke sier. Og i multi-tenancy, er det det du ikke sier som ødelegger alt.
Hva er multi-tenancy, og hvorfor er det så viktig?
Multi-tenancy betyr at én enkelt applikasjonsinstans tjener mange kunder - eller "tenanter" - samtidig. Hver kunde har sin egen data, sine egne innstillinger, og sin egen brukeropplevelse. Men alt kjører på samme kode, samme servere, samme database. Det er ikke bare effektivt - det er økonomisk nødvendig. I 2024 var 73 % av alle nye SaaS-applikasjoner bygget på denne modellen. Det er ikke en tilfeldighet. Det er fordi du ikke kan skalerer en SaaS til tusenvis av kunder hvis du må bygge en egen server for hver enkelt.
Men her kommer utfordringen: hvordan sikrer du at én kunde ikke kan komme til dataene til en annen? En enkel feil i databaseforespørselen - f.eks. å glemme å legge til WHERE tenant_id = X - kan åpne for en total datalekkasje. Og i en vibe-coded applikasjon, hvor AI genererer koden basert på en tekstbeskrivelse, er det lett å glemme å spesifisere dette. Det er ikke AI-en som er feil. Det er deg. Fordi du ikke sa nok.
Hvordan isolerer du tenanter? Tre strategier
Det finnes tre måter å isolere data mellom kunder på. Og du må velge riktig fra dag én.
- Databasen per kunde: Hver kunde har sin egen database. Enkelt og trygg. Men dyrt. Hver database krever ressurser, backup, og vedlikehold. Ikke praktisk for mange kunder.
- Delte database, skjemaer per kunde: Én database, men hver kunde har sitt eget skjema (som en egen "mappe" inni databasen). Bedre ressursutnyttelse. Men kompleks i vedlikehold og oppdateringer.
- Delte database, radnivå-isolasjon: Alle kunder deler samme tabeller, men hver rad har et
tenant_id-felt. Alle forespørsler må inkludere dette feltet. Det er den vanligste modellen i moderne SaaS - og den som AI mest ofte feiler på.
Bitcot sin løsning fra januar 2024 bruker radnivå-isolasjon med PostgreSQLs Row-Level Security (RLS). Det betyr at databasen selv blokkerer alle forespørsler som ikke har riktig tenant_id. Ingen unntak. Ingen glemsler. Og det er nettopp det du må si til AI-en: "Implementer RLS med tenant_id som diskriminator. Ingen forespørsel skal kunne gå gjennom uten det."
Autentisering: Ikke bare "logg inn" - men "logg inn som riktig kunde"
En kunde kan ha flere brukere. En annen kunde kan bruke SSO med Azure AD. En tredje kan bruke Google Login. Og du må håndtere alle samtidig - uten å blande dem.
Her er det ikke nok å bare bruke Supabase Auth eller Firebase Auth. Du må ha et system som vet hvilken kunde hver bruker tilhører. Og hvordan? Gjennom et tenant context-system. Når en bruker logger inn, må systemet ikke bare bekrefte passordet - det må også sette en "tenant"-kontekst som følger alle påfølgende forespørsler.
AI kan generere en login-side. Men den vil ikke automatisk legge til tenant-kontekst. Du må spesifisere: "Når en bruker logger inn, hent tenant_id fra brukerens konto og legg den i en JWT-token. Bruk denne tokenen i alle API-kall. Ingen forespørsel uten tenant_id skal tillates."
Bitcot sin løsning bruker en API-gateway som validerer tokenen før den lar kallet gå videre. Hvis tenant_id mangler, blir kallet avvist. Denne kontrollen må bygges inn i arkitekturen fra start - ikke etterpå. Og det er akkurat det som går galt i 62 % av SaaS-startupene som bruker vibe coding, ifølge Gartner.
Kostnadsstyring: Når én kunde sluker hele serveren
En av de mest skjulte farene i multi-tenancy er ressursforbruk. Tenk deg at én kunde - kanskje en stor bedrift - begynner å laste opp 100 GB data per dag. Eller kjører 50 000 forespørsler i minuttet. Hvis du ikke setter grenser, vil denne kunden forbruke 80 % av alle ressursene. Og alle andre kunder får tregt svar. Eller ingen svar.
Her er det ikke nok å bare bruke AWS Lambda. Du må måle. Du må sette grenser. Og du må stoppe. Når en kunde når 90 % av sin tildelte kvote, må systemet varsle. Ved 100 %, må det blokkere.
Bitcot bruker serverless funksjoner til å måle hver kundes bruk i sanntid. Hver API-kall registreres med tenant_id. Hver databaseforespørsel telles. Hver filopplasting måles. Og hvis en kunde går over grensen - stopper systemet automatisk. Og sender en varsling.
Men AI vil ikke generere dette. Du må spesifisere det: "Bygg et metering-system som registrerer alle API-kall, databaseforespørsler og filopplastinger per tenant. Bruk en dynamisk kvote basert på abonnement. Blokker overbruk."
En utvikler på Reddit skrev i juli 2024: "Jeg spilte $12 000 på AWS fordi min vibe-coded SaaS ikke hadde kostnadsstyring. Én kunde brukte 83 % av alle ressurser. Jeg måtte stoppe alt."
Vibe coding er ikke en magisk knapp
Det er en myte at vibe coding gjør alt enkelt. Det gjør det raskt. Men ikke enklere. Du kan generere en login-side på 30 sekunder. Men hvis du ikke spesifiserer at hver forespørsel må inneholde tenant_id, så vil AI generere en applikasjon som lekkasjer data. Og du vil ikke vite det før en kunde kommer med klage.
Fronteggs CTO, Eran Stiller, sa i mars 2024: "Vibe coding skaper 'black box'-arkitekturer. Uten å forstå hva AI-en har bygget, kan du ikke sikre at det er trygt."
GitHub sin forskning fra mai 2024 viser at når du spesifiserer isolasjonskrav eksplisitt - "Bruk RLS. Bruk tenant_id. Ingen forespørsel uten tenant_id. Alle kall må ha JWT med tenant_id. Bruk API-gateway for å validerer det." - så lykkes AI i 87 % av tilfellene. Uten det? Bare 41 %.
Hva må du gjøre før du starter?
Her er det ikke nok å bare skrive: "Bygg en SaaS med multi-tenancy."
Du må gjøre dette før du lar AI skrive én linje kode:
- Velg isolasjonsstrategi: Radnivå med tenant_id er den beste for de fleste.
- Definer autentisering: Hvilke IDP-er bruker kundene? Hva er token-strukturen?
- Sett kostnadsbetingelser: Hva er kvoten per kunde? Hva skjer ved overbruk?
- Bygg testprosedyrer: Automatiser tester som sjekker at ingen forespørsel kan hoppe over tenant_id.
- Test manuelt: Bruk et verktøy som Burp Suite eller Postman. Prøv å gjøre en forespørsel uten tenant_id. Den må avvises.
Bitcot anbefaler 15-20 timer med arkitekturplanlegging før du starter vibe coding. Det er ikke tid tapt. Det er besparelse. Fordi å fikse en feil i multi-tenancy etter at applikasjonen er bygget, tar 40-60 timer - og ofte må du starte på nytt.
Hva skjer hvis du glemmer det?
En feil i multi-tenancy er ikke bare en bug. Den er en sikkerhetsbrudd. Og det er ikke teoretisk. I 2024 utgjorde feil i tenant-isolasjon 34 % av alle SaaS-sikkerhetsbrudd, ifølge AWS. Og 17 % av alle SaaS-brudd i første halvår av 2024 skyldtes GDPR- og CCPA-overtrædelser - altså datalekkasje mellom kunder.
En utvikler på Hacker News skrev: "Jeg bygde en SaaS med vibe coding i 2 dager. Men det tok 3 uker å fikse datalekkasjene. Jeg fikk en klage fra en kunde som så finansdata fra en konkurrent."
Det er ikke bare et teknisk problem. Det er et juridisk problem. Og et økonomisk problem. Og et reputasjonsproblem.
Det er ikke AI som feiler. Det er deg.
Vibe coding er ikke en erstatning for arkitekturforståelse. Det er en forsterker. Og hvis du ikke forstår isolasjon, autentisering og kostnadsstyring - så vil AI forsterke dine feil. Ikke rette dem.
Den eneste måten å bygge trygg multi-tenancy i en vibe-coded SaaS er å være ekstremt spesifikk. Ikke si: "Bygg en SaaS." Si: "Bruk PostgreSQL RLS. Alle tabeller må ha tenant_id. Alle forespørsler må inkludere tenant_id fra JWT. API-gateway må avvise alle forespørsler uten det. Bruk serverless funksjoner til å måle bruk per tenant. Blokker ved 100 %. Send varsling ved 90 %."
Det er ikke vanskelig. Det er enkelt. Bare du må si det. Og du må si det før du skriver én linje kode.