Koden kan I som regel få med. Det er resten, der kræver arbejde. Et produkt bygget på en app-bygger består af kode, database, brugere, filer, nøgler, login-opsætning og domæne, og de dele flytter ikke af sig selv på én gang. Lovable og Bolt tilbyder begge at hente koden og at forbinde den til GitHub, og for begge gælder, at databasen er en særskilt sag. Lav flytningen til en øvelse, før I har brug for den. Så ved I, om I reelt ejer jeres produkt. Beskrivelsen nedenfor bygger på leverandørernes egne sider, som de så ud i november 2026, og den kan hurtigt blive forældet.
De syv dele, I skal have styr på
Teknisk ejerskab betyder, at I kan køre produktet videre uden platformen. Gennemgå hver del:
- Koden. Ligger den i et repository, altså et versionsstyret kodelager, I selv ejer?
- Databasen. Kan struktur og indhold hentes ud i et almindeligt format?
- Brugerne. Følger konti med, og kan folk beholde deres adgangskoder?
- Filerne. Billeder og dokumenter, kunderne har lagt op, ligger ofte for sig.
- Nøglerne. Hemmelige nøgler følger ikke med en kodeeksport, og det er med vilje.
- Forbindelserne. Betaling, mail, AI-tjenester og login med fx Google er sat op et sted.
- Domænet. Står det i virksomhedens navn og hos en registrator, I har adgang til?
Den mere generelle tjekliste for ejerskab står i ejer I koden og kontiene.
Sådan ser det ud i Lovable
Ifølge Lovables dokumentation kan et projekt forbindes til GitHub, så ændringer løber begge veje på den aktive gren, og repositoriet er som standard privat. Uden GitHub kan koden hentes med funktionen Download codebase på betalte abonnementer. Afbryder I forbindelsen, bliver projektet liggende i Lovable.
Bruger I den indbyggede backend, er databasen en særskilt eksport. Ifølge dokumentationen indeholder den databasens struktur og indhold samt brugernes konti med adgangskoderne i hashet form, altså omregnet, så de ikke kan læses. Den indeholder ikke filer, serverfunktioner, hemmeligheder, opsætning af login-udbydere eller projektets nøgler. De skal flyttes særskilt. Dokumentationen peger på Supabase, enten som tjeneste eller selv hostet, som destination, og AI-kald, der går gennem platformen, skal skiftes til jeres egen konto hos en udbyder. Planlagte kørsler skal oprettes igen.
Læg mærke til rækkefølgen, hvis I fjerner backenden: dokumentationen advarer om, at data bør hentes først.
Sådan ser det ud i Bolt
Bolts hjælpesider beskriver, at et projekt kan hentes som en zip-fil, og at et GitHub-repository kan forbindes til backup og versionsstyring. Bolt har også en indbygget database. Her skriver Bolt, at der for tiden ingen understøttet måde er at flytte en eksisterende Bolt-database til Supabase på, men at databasen kan overtages i jeres egen Supabase-konto under avancerede indstillinger, og at rækkedata kan eksporteres. Beskrivelsen af fremgangsmåden er kort, så prøv det i praksis, og tjek den aktuelle hjælp.
Vilkårene hos Bolt lykkedes det os ikke at få læst, så slå dem selv op.
Rettigheder er en anden sag
Teknisk adgang og rettigheder er to forskellige ting. Ifølge vilkårene hos Lovable tilhører projekterne og det genererede output jer, dog sådan at tredjemand kan have rettigheder. Den retlige stilling for kode skrevet af en AI er endnu uafklaret, og vi kender ingen dansk myndighed, der har udtalt sig. Tag spørgsmålet med til en advokat, især hvis produktet skal bære virksomhedens værdi. Hvordan rettigheder i øvrigt fordeles mellem ansatte og freelancere, står i hvem ejer koden.
Når det gælder andre komponenter, som værktøjet har trukket ind, skal licenserne kendes, se open source-licenser i produktet.
Lav en prøveflytning
Det eneste bevis er at gøre det. En prøveflytning kan laves, uden at noget slukkes:
- Hent koden til et repository i virksomhedens egen konto.
- Hent en kopi af databasen og filerne.
- Få en udvikler til at starte produktet et andet sted, med en kopi af data og nye testnøgler.
- Log ind som testbruger, og gennemfør kerneflowet.
- Skriv ned, hvad der ikke virkede, og hvad der var afhængigt af platformen.
Listen fra punkt 5 er den egentlige gevinst. Den viser, hvor bundet I er, og hvad der skal ændres. Mange finder kode, som kalder tjenester, der kun findes inde på platformen, eller opsætning, der aldrig blev skrevet ned. En ikke-teknisk stifter har brug for hjælp til punkt 3, og I får et godt indblik i kodens tilstand, når en udvikler prøver at køre den.
Hvornår skal I flytte?
At kunne flytte betyder ikke, at I skal gøre det nu. En platform kan sagtens bære produktet et stykke tid. Disse tegn taler for at flytte:
- Kunderne stiller krav om, hvor data ligger, eller hvem der behandler dem.
- Udviklere skal arbejde i koden, og to måder at ændre den på støder sammen.
- Krav til drift, logning eller test kan ikke opfyldes på platformen.
- Forretningen ville stå stille, hvis platformen ændrede vilkår.
Hvor produktet så skal køre, er beskrevet i cloud og hosting til SaaS.
Det skal I lade være med
· At slette noget i værktøjet, før alt er hentet og prøvet. Følg rækkefølgen i leverandørens vejledning.
· At antage, at en kodeeksport er hele produktet. Data, nøgler og opsætning følger ikke med.
· At genbruge gamle nøgler i det nye miljø. Lav nye.
· At vente, til et abonnement udløber. Flytning under pres giver fejl.
Det skal I kræve af den eksterne
- ☐ Et overblik over de syv dele og over, hvor hver af dem ligger.
- ☐ En plan for prøveflytning og for, hvem der udfører den.
- ☐ En liste over afhængigheder af platformen.
- ☐ Et råd om, hvornår en flytning giver mening, og hvornår den kan vente.
Kilder
- Lovable: GitHub-integration og Lovable: backup og eksport af database.
- Lovable: Hosting og ejerskab og Lovable: Terms.
- Bolt: Manage projects og Bolt: Database.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Lovable, Bolt, Cursor eller Claude Code · Kan I genskabe produktet?
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
