Från Lovable till produktion på 2 veckor

Klienten kom till oss med något imponerande och något ofullständigt, sida vid sida: en fungerande PropTech-SaaS-prototyp, byggd från början till slut i Lovable ovanpå React och Supabase, som såg övertygande ut i förhandsvisningen. Vad de inte hade var något som liknade produktion.

Ingen CI/CD — varje ändring krävde en manuell deployment. Ingen övervakning — inget sätt att se om appen mådde bra, och ingen varning om den inte gjorde det. Fillagringen låg i Supabase Storage, vilket fungerade i prototypskala men var på väg att slå i kostnads- och prestandataket så fort riktiga användare dök upp. Ingen hade tittat på koden för säkerhetsfrågor. Och lanseringen stod för dörren.

Frågan var inte om vi skulle bygga om. Prototypen var okej. Frågan var hur snabbt vi kunde lägga infrastruktur av produktionsklass under den, så att klienten faktiskt kunde släppa in användare.

Utmaningen

• Fungerande prototyp, ingen väg till produktion. Appen kördes i Lovables förhandsvisning. Det fanns ingen plan för hur den skulle köras någon annanstans.
• Endast manuella deploys. Varje ändring krävde någon med rätt åtkomst som tryckte ut den för hand — grundare-som-infra-mönstret beskrivet i vår artikel om dolda kostnader.
• Noll övervakning eller varningar. Om appen gick sönder skulle ingen veta förrän en användare klagade.
• Fillagring enbart i Supabase Storage. Helt okej i prototypskala; dyrt och skört när riktiga användare kommer in.
• Ingen säkerhetsgranskning. Ingen hade gjorts. Planen var att lansera; risken var okänd.

Vad vi gjorde

Två till tre veckor från första samtalet till produktionsöverlämning. Vi körde tre spår parallellt: säkerhetsgenomgången, infrastrukturbygget och lagringsmigreringen.

1. OWASP Top 10-säkerhetsgranskning. En strukturerad genomgång mot OWASP Top 10. Kritiska problem identifierade, prioriterade efter affärsrisk och fixade. (Specifika fynd publiceras inte — de skulle kunna avslöja vem klienten är.)
2. CI/CD-pipeline. Automatiserade tester och deployment vid varje push. Inga fler manuella deploys; inga fler enpersons-flaskhalsar.
3. Produktionsserverkonfiguration. Tydlig miljöseparation — staging och produktion som separata miljöer, var och en med sin egen konfiguration. Slut på "appen finns där grundarens webbläsare råkar vara just nu."
4. Övervakning och varningar. 24/7-övervakning av fel och prestanda, med varningar som går till rätt ställe. Fel upptäcks på minuter, inte dagar.
5. AWS S3 + CloudFront-migration. Fillagringen flyttad från Supabase Storage till S3 med ett CloudFront-CDN. Billigare, snabbare, och lagringstaket försvinner.
6. Domän-, SSL- och infrastrukturkonfiguration. Korrekt HTTPS, DNS, miljövariabler och produktions-build-pipeline — det oglamorösa arbetet som skiljer en deployad app från en demo.
7. Överlämningsdokumentation. Skriftlig dokumentation för klientens team: hur man deployar, hur man roterar nycklar och lösenord, hur datan flödar, vad som är skört och varför. Dokumentationen är det som gör nästa ingenjör de anställer produktiv från dag ett i stället för dag trettio.

Resultat

I slutet av uppdraget var applikationen verkligen produktionsklar — inte "produktionsklar enligt marknadsavdelningen", utan den sortens produktionsklar som håller när riktiga användare kommer. Det här ändrades konkret:

Grundaren behövde inte längre vara med för att en deploy skulle bli av. Teamet hade varningar på plats innan de behövde dem. Lagringsupplägget var inte längre en kostnadssmäll som låg och väntade.

Vad vi skulle säga åt en annan grundare i samma situation

Fallstudier är mest användbara när de går att generalisera. Tittar du på en Lovable-, Bolt- eller v0-prototyp som snart ska möta riktiga användare, ser problemet oftast likadant ut. En kort checklista, destillerad ur det här uppdraget:

• Gör säkerhetsgenomgången före lansering, inte under. OWASP Top 10 är en startpunkt, inte ett tak — men att börja där fångar det mesta av det som faktiskt utnyttjas mot unga SaaS-produkter.
• Behandla manuella deploys som en grundarskatt. Om du är den enda som kan leverera är du inte bara ingenjören — du är deploysystemet. CI/CD är en investering på en vecka som köper tillbaka den tiden för alltid.
• Slå på övervakning dag noll, inte dagen för det första avbrottet. Det är alltid en tretimmarsuppgift att sätta upp innan du behöver det. Det blir en flerdagarsuppgift att sätta upp medan något redan brinner.
• Utgå från att du kommer att växa ur hanterad lagring. Supabase Storage, Firebase Storage, Vercel Blob — alla helt okej att börja med, alla med ett tak. Planera migreringsvägen innan du behöver den; den är tio gånger billigare än panikvarianten.
• Dokumentera överlämningsytan även om "överlämningen" sker till framtida-du. Personen som kommer att kämpa utan deploy-dokumentation är oftast en version av dig själv från tre månader tillbaka.

För den längre versionen av dessa mönster, se våra artiklar om osynliga buggar i AI-genererad kod och när du ska lämna över din MVP.