Fra Lovable til produksjon på 2 uker

Kunden kom til oss med noe imponerende og noe ufullstendig, side om side: 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 produksjon.

Ingen CI/CD — hver endring krevde en manuell deployment. Ingen overvåkning — ingen måte å se om appen var frisk, og ingen varsel hvis den ikke var det. Fillagring lå i Supabase Storage, som var greit på prototypeskala men i ferd med å treffe kostnads- og ytelsesgrenser i det øyeblikket ekte brukere kom. Ingen hadde sett på koden for sikkerhetsproblemer. Og lanseringen var nær.

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

Utfordringen

• Fungerende prototype, ingen produksjonsvei. Appen kjørte i Lovables forhåndsvisning. Det fantes ingen plan for hvordan den skulle kjøre noe annet sted.
• Kun manuelle deploys. Hver endring krevde noen med riktig tilgang som sendte den ut for hånd — gründer-som-infra-mønsteret beskrevet i artikkelen vår om skjulte kostnader.
• Null overvåkning eller varsler. Hvis appen gikk i stykker, ville ingen vite det før en bruker klaget.
• Fillagring kun på Supabase Storage. Greit på prototypeskala; dyrt og sårbart på ekte brukerskala.
• Ingen sikkerhetsgjennomgang. Ingen hadde blitt gjort. Planen var å lansere; risikoen var ukjent.

Hva vi gjorde

To til tre uker fra første samtale til produksjonsoverlevering. Vi kjørte tre spor parallelt: sikkerhetspasset, infrastrukturbyggingen og lagringsmigreringen.

1. OWASP Top 10-sikkerhetsrevisjon. En strukturert gjennomgang mot OWASP Top 10. Kritiske problemer identifisert, prioritert etter forretningsrisiko og fikset. (Spesifikke funn publiseres ikke — de kan re-identifisere kunden.)
2. CI/CD-pipeline. Automatiserte tester og deployment ved hver push. Ikke mer manuelle deploys; ikke mer enkeltperson-flaskehals.
3. Produksjonsserverkonfigurasjon. Skikkelig miljøseparasjon — staging og produksjon som distinkte miljøer, hver med sin egen konfig. Ikke mer "appen er der gründerens nettleser tilfeldigvis var."
4. Overvåkning og varsler. 24/7-overvåkning av feil og ytelse, med varsler rutet til riktig sted. Feil blir kjent på minutter, ikke dager.
5. AWS S3 + CloudFront-migrering. Fillagring flyttet fra Supabase Storage til S3 med et CloudFront-CDN. Billigere, raskere, og lagringstaket forsvinner.
6. Domene-, SSL- og infrastrukturkonfigurasjon. Skikkelig HTTPS, DNS, miljøvariabler og produksjons-build-pipeline — det lite glamorøse arbeidet som skiller en deployet app fra en demo.
7. Overleveringsdokumentasjon. Skriftlige dokumenter for kundens team: hvordan å deploye, hvordan rotere legitimasjon, hvordan data flyter, hva som er sårbart og hvorfor. Dokumentasjonen er den delen som gjør neste ingeniør de ansetter effektiv dag én i stedet for dag tretti.

Resultater

Ved slutten av engasjementet var applikasjonen virkelig produksjonsklar — ikke "markedsavdelingens produksjonsklar," men den typen som holder når ekte brukere kommer. Hva som endret seg konkret:

Gründeren trengte ikke lenger være til stede for at en deploy skulle skje. Teamet hadde varsler på plass før de trengte dem. Lagringsplanen sluttet å være en kostnadsoverraskelse som ventet.

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

Casestudier er mest nyttige når de generaliserer. Hvis du ser på en Lovable-, Bolt- eller v0-prototype som snart skal møte ekte brukere, er formen på problemet vanligvis den samme. En kort sjekkliste, destillert fra dette engasjementet:

• Gjør sikkerhetspasset før lansering, ikke under. OWASP Top 10 er et startpunkt, ikke et tak — men å starte der fanger det meste av det som faktisk utnyttes mot unge SaaS-produkter.
• Behandle manuelle deploys som en gründerskatt. Hvis du er den eneste som kan levere, er du ikke bare ingeniøren — du er deployment-systemet. CI/CD er en enukers investering som kjøper tilbake den tiden for alltid.
• Slå på overvåkning dag null, ikke dagen for første utfall. Det er alltid en tretimers oppgave å sette opp før du trenger det. Det er en flerdagers oppgave å sette opp mens noe brenner.
• Anta at du vil vokse ut av managed-service-lagring. Supabase Storage, Firebase Storage, Vercel Blob — alle greie å starte med, alle med et tak. Planlegg migrasjonsveien før du trenger den; den er ti ganger billigere enn panikkversjonen.
• Dokumenter overleveringsflaten selv om "overlevering" er fremtids-deg. Personen som vil slite uten deploy-dokumentasjon er vanligvis en versjon av deg selv fra tre måneder tilbake.

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