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 var frisk, och ingen varning om den inte var det. Filstorage satt i Supabase Storage, vilket var okej vid prototypskala men på väg att slå i kostnads- och prestandagränser när riktiga användare anlände. 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 produktionsklass-infrastruktur under den, så att klienten faktiskt kunde släppa in användare.

Utmaningen

• Fungerande prototyp, ingen produktionsväg. Appen kördes i Lovables förhandsvisning. Det fanns ingen plan för hur den skulle köra 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.
• Filstorage enbart på Supabase Storage. Okej vid prototypskala; dyrt och bräckligt vid riktig användarskala.
• 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äkerhetspasset, infrastrukturbygget och lagringsmigrationen.

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 kan åter-identifiera klienten.)
2. CI/CD-pipeline. Automatiserade tester och deployment vid varje push. Inga fler manuella deploys; inga fler enpersons-flaskhalsar.
3. Produktionsserverkonfiguration. Korrekt miljöseparation — staging och produktion som distinkta miljöer, var och en med sin egen konfiguration. Inte mer "appen är där grundarens webbläsare råkar vara."
4. Övervakning och varningar. 24/7-övervakning av fel och prestanda, med varningar dirigerade till rätt ställe. Fel blir kända på minuter, inte dagar.
5. AWS S3 + CloudFront-migration. Filstorage 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. Skriftliga dokument för klientens team: hur man deployer, hur man roterar referenser, hur data flyter, vad som är bräckligt och varför. Dokumentationen är den del som gör nästa ingenjör de anställer effektiv dag ett istället för dag trettio.

Resultat

I slutet av uppdraget var applikationen verkligen produktionsklar — inte "marknadsavdelningens produktionsklar," utan den sort som håller när riktiga användare anländer. Vad som ändrades konkret:

Grundaren behövde inte längre vara närvarande för att en deploy skulle ske. Teamet hade varningar på plats innan de behövde dem. Lagringsplanen slutade vara en kostnadsöverraskning som väntade.

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

Fallstudier är mest användbara när de generaliserar. Om du tittar på en Lovable-, Bolt- eller v0-prototyp som snart ska möta riktiga användare, är problemets form vanligtvis densamma. En kort checklista, destillerad från detta uppdrag:

• Gör säkerhetspasset 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 vad som faktiskt exploateras 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 deploymentssystemet. CI/CD är en enveckas investering som köper tillbaka den tiden för alltid.
• Slå på övervakning dag noll, inte dagen för första avbrottet. Det är alltid ett treriams uppgift att sätta upp innan du behöver det. Det är en flerdagars uppgift att sätta upp medan något brinner.
• Anta att du kommer växa ur managed-service-lagring. Supabase Storage, Firebase Storage, Vercel Blob — alla okej att börja med, alla med ett tak. Planera migrationsvägen innan du behöver den; den är tio gånger billigare än panikversionen.
• Dokumentera överlämningsytan även om "överlämning" är framtida-du. Personen som kommer kämpa utan deploy-dokumentation är vanligtvis 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.