Fra Lovable til produksjon på 2 uker

Kunden kom til oss med noe imponerende og noe ufullstendig på én gang: en fungerende PropTech-SaaS-prototype, bygget helt i Lovable oppå React og Supabase, som så overbevisende ut i forhåndsvisningen. Det de ikke hadde, var noe som lignet på produksjon.

Ingen CI/CD — hver endring krevde en manuell utrulling. Ingen overvåkning — ingen måte å se om appen fungerte som den skulle, og ingen varsler hvis den ikke gjorde det. Fillagringen lå i Supabase Storage, som holdt på prototypenivå, men var i ferd med å treffe kostnads- og ytelsestaket i det øyeblikket ekte brukere kom inn. Ingen hadde gått gjennom koden for å se etter sikkerhetshull. Og lanseringen nærmet seg.

Spørsmålet var ikke om vi skulle bygge om. Prototypen var helt grei. Spørsmålet var hvor raskt vi kunne legge infrastruktur av produksjonskvalitet under den, slik at kunden faktisk kunne slippe inn brukere.

Utfordringen

• Fungerende prototype, ingen vei til produksjon. Appen kjørte i forhåndsvisningen i Lovable. Det fantes ingen plan for hvordan den skulle kjøre noe annet sted.
• Bare manuelle utrullinger. Hver endring krevde at noen med riktig tilgang sendte den ut for hånd — mønsteret med gründeren som infrastruktur, som vi beskriver i artikkelen vår om skjulte kostnader.
• Null overvåkning eller varsling. Hvis appen sluttet å virke, ville ingen vite det før en bruker klaget.
• Fillagring bare i Supabase Storage. Greit på prototypenivå; dyrt og skjørt når ekte brukere kommer på banen.
• Ingen sikkerhetsgjennomgang. Det var ikke gjort noen. Planen var å lansere; risikoen var ukjent.

Hva vi gjorde

To til tre uker fra første samtale til overlevering i produksjon. Vi kjørte tre spor parallelt: sikkerhetsgjennomgangen, oppbyggingen av infrastrukturen og lagringsmigreringen.

1. OWASP Top 10-sikkerhetsgjennomgang. En strukturert gjennomgang mot OWASP Top 10. Kritiske problemer ble identifisert, prioritert etter forretningsrisiko og rettet. (Vi publiserer ikke konkrete funn — de kan avsløre hvem kunden er.)
2. CI/CD-pipeline. Automatiserte tester og utrulling ved hver push. Slutt på manuelle utrullinger; slutt på flaskehalsen der alt henger på én person.
3. Oppsett av produksjonsserver. Skikkelig adskilte miljøer — staging og produksjon som hver sitt miljø, med sin egen konfig. Slutt på «appen ligger der gründerens nettleser tilfeldigvis var».
4. Overvåkning og varsling. Overvåkning av feil og ytelse døgnet rundt, med varsler som går til rett sted. Feil blir oppdaget i løpet av minutter, ikke dager.
5. Migrering til AWS S3 + CloudFront. Fillagringen ble flyttet fra Supabase Storage til S3 med et CloudFront-CDN. Billigere, raskere, og lagringstaket forsvinner.
6. Oppsett av domene, SSL og infrastruktur. Skikkelig HTTPS, DNS, miljøvariabler og en build-pipeline for produksjon — det lite glamorøse arbeidet som skiller en utrullet app fra en demo.
7. Overleveringsdokumentasjon. Skriftlig dokumentasjon til kundens team: hvordan man ruller ut, hvordan man bytter ut tilgangsnøkler, hvordan data flyter, hva som er skjørt og hvorfor. Dokumentasjonen er det som gjør den neste utvikleren de ansetter effektiv på dag én i stedet for dag tretti.

Resultater

Da oppdraget var over, var applikasjonen virkelig produksjonsklar — ikke «produksjonsklar» slik markedsavdelingen mener det, men den typen som holder når ekte brukere kommer. Konkret var det dette som endret seg:

Gründeren trengte ikke lenger være til stede for at en utrulling skulle skje. Teamet hadde varslingen på plass før de trengte den. Lagringsplanen sluttet å være en kostnadssmell som bare ventet på å inntreffe.

Hva vi ville sagt til en annen gründer i samme situasjon

Casestudier er mest nyttige når de lar seg generalisere. Hvis du sitter med en Lovable-, Bolt- eller v0-prototype som snart skal møte ekte brukere, er problemet som regel det samme i formen. En kort sjekkliste, destillert fra dette oppdraget:

• Ta sikkerhetsgjennomgangen før lansering, ikke underveis. OWASP Top 10 er et utgangspunkt, ikke et tak — men å begynne der fanger opp det meste av det som faktisk utnyttes mot ferske SaaS-produkter.
• Se på manuelle utrullinger som en gründerskatt. Hvis du er den eneste som kan levere, er du ikke bare utvikleren — du er hele utrullingssystemet. CI/CD er en investering på én uke som kjøper deg den tiden tilbake for alltid.
• Slå på overvåkning på dag null, ikke den dagen den første nedetiden inntreffer. Det er alltid en jobb på tre timer å sette opp før du trenger det. Det er en jobb på flere dager å sette opp mens noe står i brann.
• Regn med at du vil vokse fra lagring som tjeneste. Supabase Storage, Firebase Storage, Vercel Blob — alle greie å starte med, alle med et tak. Planlegg migreringsveien før du trenger den; den er ti ganger billigere enn panikkvarianten.
• Dokumenter overleveringen selv om «den du overleverer til» er deg selv senere. Den som kommer til å slite uten dokumentasjon på utrulling, er som regel en versjon av deg selv fra tre måneder tilbake.

Vil du ha den lengre versjonen av disse mønstrene, kan du lese artiklene våre om usynlige bugs i AI-generert kode og når du bør overlevere MVP-et ditt.