En ekte backend, født med appen din
Database, innlogging, filer, funksjoner, secrets, e-post – hver Kliv-app starter med alt sammen, opprettet og administrert av AI-en mens du bygger. Ingenting å provisjonere, ingenting å koble opp, ingenting å holde synkronisert.
Skybackend
Ikke en backendtjeneste du kobler opp
De fleste AI-byggere genererer en frontend og gir deg en sjekkliste: registrer deg for en database her, en autentiseringsleverandør der, lim inn nøklene, skriv limet. Hver skjøt i den stacken blir din å vedlikeholde. Klivs backend fødes med appen – ett system, der samme samtale som bygger sidene dine også skriver migreringene og tilgangsreglene dine, og reglene holder overalt.
Hva hver app fødes med
Dette er ikke en funksjonsliste du slår på del for del. Det er standardutstyret under hver Kliv-app – dette kjører før du er ferdig med å beskrive side én.
En database med egne regler
Dataene dine bor i din egen database, og personvernet håndheves på raden: en regel som «kunder leser bare sine egne prosjekter» er en egenskap ved dataene, sjekket på hver spørring – ikke en if-setning noen må huske å skrive på hver side.
Innlogging og identitet
Kontoer, økter, roller og organisasjoner finnes før den første siden din gjør det. Brukerne dine kan være enkeltpersoner eller hele selskaper – og innlogging går langt forbi passord, noe som får sin egen del nedenfor.
Et fillager med tilgangsregler
Opplastinger, bilder og dokumenter bærer egne regler: private, delt per organisasjon eller gated bak et kjøp. En videresendt lenke åpner ingenting reglene ikke tillater – deling er en beslutning, ikke en URL-ulykke.
Server-side-funksjoner, typet
Når logikk må kjøre på serveren – en beregning, et callback inn i et annet verktøy, en nattlig jobb – skriver AI-en ekte TypeScript mot et typet SDK som kompilatoren sjekker. Funksjoner kjører på forespørsel, på hendelser eller etter en tidsplan.
Secrets i et hvelv
API-nøkler og innloggingsopplysninger bor i et hvelv, aldri i kode nettleseren kan se. Funksjoner leser dem ved runtime, og ingenting sensitivt havner i kildekoden din.
E-post som bærer navnet ditt
Levering og maler er en del av backenden – e-posten appen sender er brandet som appen din, skrevet én gang og sendt uten en tredjeparts e-posttjeneste å konfigurere.
Administrert mens du bygger
Delen ingen backendtjeneste gjør: AI-en vedlikeholder alt dette som en sideeffekt av byggingen. Beskriv en funksjon, så kommer skjemaendringen som en ordnet, sporet migrering; tilgangsreglene utvikler seg med sidene som trenger dem. Backenden følger appen, fordi de aldri var separate.
Standardutstyret
Seks deler, ett system – hver del allerede koblet til de andre.
Din egen database
Sikkerhet på radnivå håndhevet på hver spørring – personvern per bruker er en egenskap ved dataene, ikke en vane koden din må holde.
Innlogging og identitet
Kontoer, organisasjoner og roller – pluss innlogging med Google og Facebook, passkeys og tofaktor for brukerne dine.
Fillageret
Filer med egne tilgangsregler – private, per organisasjon eller bak et kjøp. Lenker alene åpner ingenting.
Typede server-side-funksjoner
Ekte TypeScript mot et SDK kompilatoren sjekker – på forespørsel, på hendelser eller etter en tidsplan.
Secrets-hvelvet
Nøkler og innloggingsopplysninger ut av koden din og ut av nettleseren – funksjoner leser dem ved runtime.
E-postlevering
Maler og levering innebygd – e-post som bærer appens navn, ikke en leverandørs.
Innlogging, innebygd
De fleste byggere gir deg e-post og passord og kaller det identitet. Kliv gir appens brukere innloggingen de forventer av ekte produkter – og den tilhører appen din: din flyt, din branding, dine poster.
E-post og passord
Kontoer, verifisering og tilbakestilling – det grunnleggende, håndtert skikkelig.
Logg inn med Google og Facebook
Innlogging med ett trykk med kontoene brukerne dine allerede har.
Passkeys
Phishing-resistent innlogging med Face ID, Touch ID eller en sikkerhetsnøkkel – ikke noe passord å stjele.
Tofaktorautentisering
TOTP-koder fra hvilken som helst autentiseringsapp, for brukere som vil ha en ekstra lås på døren.
Organisasjoner og roller
Team, roller og organisasjonsvegger – strukturen databasens regler skrives mot.
Dine brukere, dine poster
Hver konto er en rad i din egen database – segmenter dem, eksporter dem eller slett én på forespørsel. Relasjonen er din.
Vanlige spørsmål
Er backenden en separat tjeneste jeg må administrere?
Nei – det er poenget. Den fødes med appen og administreres gjennom den samme samtalen som bygger den. Det finnes ikke noe dashboard å provisjonere, ingen nøkler å lime inn på dag én og ikke noe andre system som glir ut av synk med koden din.
Hvem skriver databasemigreringene?
AI-en gjør det, som en sideeffekt av byggingen. Beskriv funksjonen, så kommer skjemaendringen som en ordnet, sporet migrering – lesbar hvis du vil se, anvendt i rekkefølge slik at databasens historikk er like tydelig som appens.
Hvordan håndheves personvern per bruker i praksis?
På raden. Hver spørring returnerer bare det den innloggede brukeren har lov til å se, fordi regelen bor på dataene selv – så en feil på en side kan ikke lekke det databasen nekter å gi fra seg.
Kan brukerne mine logge inn med Google?
Ja – Google og Facebook, sammen med passkeys og TOTP-tofaktor. Og det er appens egen innlogging, ikke en tredjeparts widget: din flyt, din branding og brukerposter som bor i din egen database.
Hvor bor API-nøkler og innloggingsopplysninger?
I hvelvet. Funksjoner leser dem ved runtime; de vises aldri i kode nettleseren kan se, og ingenting sensitivt havner i kildehistorikken din.
Kan jeg få ut koden og dataene mine?
Ja. Appens kildekode synkroniseres begge veier til ditt eget Git-repository, og dataene er din egen database – eksporter dem når som helst. Klivs veddemål er at du blir fordi det er bra, ikke fordi det er vanskelig å dra.
Beskriv appen din. Backenden følger med.
Innebygd betyr bygget sammen: kassen, agenten og testene kjører alle på den samme backenden – ett sett regler, håndhevet overalt.