Så undviker du inlåsning när du bygger med en AI-appbyggare

Frågan att ställa innan du börjar

Frågan som spelar roll är inte vad en byggare kan skapa, utan vad du sitter kvar med om du slutar betala. Gott om verktyg producerar imponerande resultat som bara existerar inuti verktyget. Det duger för en prototyp och är farligt för ett företag.

Fyra frågor skiljer de två fallen åt.

1. Kan du exportera, och vad kommer faktiskt ut?

"Export" betyder väldigt olika saker i olika verktyg. Vissa ger dig en egen projektfil som bara går att öppna i samma produkt. Vissa ger en statisk ögonblicksbild av det visuella med logiken bortskalad. Det du faktiskt vill ha är den kompletta, fungerande källkoden – uppmärkningen, designen och logiken som får det att fungera.

2. Vilket format har den exporterade koden?

Här är delen folk missar. Källkod du inte kan förstå eller underhålla är knappt bättre än ingen källkod. En ZIP med standard-HTML, vanlig JavaScript och CSS kan öppnas av vilken utvecklare som helst, i vilken editor som helst, för alltid. En ZIP som kräver en viss ramverksversion, ett eget byggsteg eller en körmiljö bara leverantören distribuerar är inlåsning med en exportknapp på.

3. Var kan den köras?

Testa konkret: kan du ta exporten, lägga den på hosting du redan betalar för, och få den att fungera? En app som bara fungerar på leverantörens domän, eller som går sönder så fort den serveras någon annanstans, är inte portabel oavsett vad marknadsföringssidan påstår. Att kunna koppla en egen domän spelar roll av samma skäl – dina användare ska nå ditt varumärke, inte en subdomän du inte kontrollerar.

4. Vad händer med datan?

Portabel kod utan portabel data är en halv lösning. Fråga var databasen ligger, om du kan koppla en egen, och om du kan exportera posterna. Ett verktyg där datan bor i ett konto du inte kan koppla loss binder dig till plattformen även om koden är fri att lämna.

De fyra frågorna tillämpade på den här plattformen

Det vore billigt att skriva frågorna ovan och sedan inte svara på dem. Så här är vad en NorthernGo-export faktiskt är, inklusive de delar som inte klarar provet helt.

Åtgärden Ladda ner ZIP på ett projektkort ger ett projekt i Capacitor-format: hela din app som www/index.html, ett www/manifest.json, en minimal www/sw.js, ett capacitor.config.json som pekar på www, och en package.json vars enda beroenden är @capacitor/core och @capacitor/cli.

På fråga två står den sig bra, och av ett strukturellt skäl snarare än ett stilistiskt. Genererade appar är medvetet monolitiska: ett HTML-dokument som innehåller uppmärkningen, Tailwind-klasserna och all JavaScript i en vanlig <script>-tagg. Inga ES-moduler, inga imports, inga externa lokala resurser, inget byggsteg. Det är ett krav i genereringsreglerna och ingen tillfällighet, och det betyder att filen öppnas i vilken editor som helst och renderas genom att du dubbelklickar på den. Det finns ingen ramverksversion att matcha och ingenting att kompilera.

På fråga ett är det ärliga förbehållet att exporten är en betalfunktion. Gratisplanen har ingen källkodsexport alls, så om kodägande är skälet till att du är här är gratisnivån en provperiod snarare än ett hem.

Där exporten slutar vara fristående

Det här är den del en sida som den här är skyldig att säga rakt ut om sin egen plattform.

Den exporterade HTML-filen innehåller fortfarande anrop till det injicerade plattforms-SDK:t – window.NorthernGoDB för data och inloggning, window.NorthernGoAI för text-, bild- och röstfunktioner, window.NorthernGo för e-post och export till CSV eller Word, och window.NorthernGoShopify om appen är en butik. De globala objekten pratar med NorthernGos backend. Öppna den exporterade filen på egen hosting och layouten, formgivningen och all logik på klientsidan fungerar direkt; dataanropen fortsätter peka hit tills du byter ut dem.

Det korrekta påståendet är alltså inte "exporten är helt oberoende". Det är "exporten är en komplett, läsbar kopia av din applikation i standardformat, vars backend-anrop är begränsade till fyra dokumenterade globala objekt". Det är ett märkbart bättre läge än en egen projektfil, och det är inte samma sak som noll beroenden. Den som säger att deras export har noll beroenden medan appen fortfarande har ett inloggningssystem är inte uppriktig mot dig.

Offline-beteendet följer inte heller med: www/sw.js i ZIP-filen är en stump som skickar anropen vidare till nätet, inte den cachande service workern som används på hostade appar. Den skillnaden och vad du gör åt den behandlas i guiden om offline och PWA.

Så skulle du faktiskt klippa banden

Eftersom appen bara anropar de globala objekten och aldrig bygger om dem – återigen en regel i genereringsprompterna snarare än en konvention – är det ett avgränsat arbete att byta backend. Du skriver om de globala objekten så att de pekar på din egen tjänst och lämnar resten av applikationen orörd.

window.NorthernGoDB = {
  save: (kollektion, data) =>
    fetch(`/api/${kollektion}`, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(data),
    }).then((r) => r.json()),

  get: (kollektion) => fetch(`/api/${kollektion}`).then((r) => r.json()),

  delete: (kollektion, falt, varde) =>
    fetch(`/api/${kollektion}?${falt}=${encodeURIComponent(varde)}`, { method: 'DELETE' }),
};

Behåll metodnamnen och formen som returnerar ett promise och ingenting i appen behöver veta något. Det är hela skälet till att ett API som bara är fyra metoder brett är värt att ha: en smal yta är en kort migrering.

Testa utgången innan du behöver den

Det mest användbara du kan göra åt inlåsning tar tjugo minuter och nästan ingen gör det.

Exportera projektet, packa upp det, öppna www/index.html direkt från filsystemet och titta i webbläsarkonsolen. Det som renderas är det du äger rakt igenom. Det som kastar fel är din beroendelista, punkt för punkt, gratis. Gör det en gång i början av ett projekt i stället för under en kris, och du vet exakt vad det kostar att lämna i stället för att gissa.

Upprepa det efter varje större ändring. En app som var portabel i mars kan tyst ha skaffat sig beroenden i juni.

Portabel data, konkret

Den inbyggda databasen är en delad Supabase-instans i PostgreSQL som nås via window.NorthernGoDB. Det finns ingen databasdump med ett klick i arbetsytan, och att låta påskina något annat skulle vara precis den sorts påstående den här sidan finns för att varna för.

Vad som finns är tillräckligt för att få ut datan utan en. Inuti din egen app returnerar window.NorthernGoDB.get(kollektion) posterna och window.NorthernGo.exportCSV(poster, 'export.csv') skriver dem till en fil, så en dold adminvy med en exportknapp är ett bygge på tio minuter. Vill du ha en löpande kopia snarare än en ögonblicksbild speglar inställningen Egen Databas varje skrivning till en HTTP-endpoint du äger, som JSON – vilket är en spegling och ingen ersättning, och databasguiden förklarar varför den skillnaden spelar roll.

Hosting och själva adressen

En app är inte portabel om adressen inte är din. Det finns tre vägar att nå en publicerad app här, och de rangordnas rent.

En egen domän på Pro är det portabla alternativet: appen är hela webbplatsen på en adress du själv registrerat, så att byta hosting senare är en DNS-ändring och ingen migrering. En adress på formen <subdomän>.northerngo.com på Premium eller Pro duger för interna verktyg och testmiljöer, men är inget du bör trycka på ett visitkort. Reservvägen northerngo.com/?app=<projektId> som projekt på gratisplanen använder är den minst portabla av de tre, eftersom domänen, sökvägen och identifieraren alla är våra.

Spelar appen roll: koppla din egen domän med SSL tidigt. Det kostar en CNAME-post och tar bort en hel kategori av framtida ånger.

Mobilfrågan

Eftersom ZIP-filen redan har Capacitor-form – webDir satt till www, Capacitors CLI i package.json – är det npx cap add snarare än en omskrivning att göra exporten till native-projekt för iOS och Android. De projekten byggs sedan i Xcode och Android Studio som vilken app som helst, vilket betyder att vägen till app-butikerna inte hänger på att plattformen fortsätter existera. Guiden om Capacitor-export går igenom det.

Hur andra byggare svarar på samma fyra frågor

De fyra frågorna är bara användbara om du faktiskt ställer dem till allt du överväger, inklusive verktyg som är bättre än det här på saker det här inte gör.

Vi har jämförelsesidor som går igenom exakt dessa frågor i stället för att räkna funktioner. Väger du det här mot Lovable, Bolt.new eller Bubble börjar du där – och läs dem med samma skepsis du bör lägga på den här sidan, eftersom vi skrivit båda.

En rimlig standard

Du ska kunna ladda ner en komplett fungerande kopia av din applikation, öppna den i valfri kodeditor, ungefär förstå vad den gör, hosta den någon annanstans och ta med dig din data. Något mindre betyder att appen inte riktigt är din – du hyr den. Den skillnaden spelar sällan roll dag ett och enormt stor roll den dag priset ändras, prioriteringarna skiftar eller produkten läggs ner.