Aplicație Lovable gata de producție: ce se strică, ce repari întâi și o listă de verificare

Ca o aplicație Lovable să fie gata de producție, închizi golurile cu care un prototip poate trăi, dar utilizatorii reali nu: fiecare tabel din baza de date protejat cu Row Level Security, nicio cheie secretă trimisă în browser, verificări pe server pentru tot ce atinge bani sau date personale, plăți confirmate prin webhookuri, backupuri și alerte pornite. De cele mai multe ori e vorba de întărire, nu de rescriere.

Ordinea contează mai mult decât lungimea listei. Repari întâi expunerea datelor, apoi secretele, apoi plățile, apoi tot ce ține aplicația în funcțiune. Mai jos găsești ordinea, o listă de verificare cu pași concreți, punctele GDPR relevante pentru utilizatorii din România și UE, ce costă aplicația live și o părere sinceră despre când continui cu prompturi și când chemi ingineri.

Testul de producție în patru întrebări

Un demo merge când dai tu click prin el. O aplicație de producție merge și când o folosesc străini în moduri pe care nu le-ai prevăzut. Un test util are patru întrebări:

• Poate un al doilea utilizator, logat cu contul lui, să vadă sau să modifice datele tale? Răspunsul trebuie să fie nu.
• Poate cineva care deschide uneltele de dezvoltator din browser să găsească o cheie care îi dă mai multe drepturi decât unui utilizator obișnuit? Tot nu.
• Dacă o plată eșuează, e reîncercată sau falsificată, baza de date mai spune adevărul?
• Dacă aplicația cade la 2 noaptea, afli tu înaintea clienților?

Dacă nu poți răspunde sigur la toate patru, aplicația nu e pregătită, oricât de bine ar arăta.

Problemele care apar primele

Cea mai frecventă problemă nu e exotică: o bază de date pe care o poate citi oricine. Un cercetător a scanat 1.645 de aplicații din vitrina publică Lovable și a găsit 170 cu tabele Supabase citibile doar cu cheia publică, vulnerabilitate înregistrată ca CVE-2025-48757. Cheia publică e menită să fie publică; protecția ar trebui să vină din politicile Row Level Security de pe fiecare tabel.

Adesea, protecția lipsește. O analiză de securitate afirmă că Lovable creează tabele fără să activeze Row Level Security sau să creeze politici și numește lipsa RLS principala vulnerabilitate a aplicațiilor Lovable. Indiferent dacă proiectul tău a urmat tiparul acesta, trebuie să verifici singur fiecare tabel.

Alți suspecți obișnuiți:

• Secrete în front-end. Cheile pentru plăți, e-mail sau AI puse în codul client ajung în pachetul pe care îl poate descărca oricine.
• Validare doar în browser. Un formular care verifică prețul sau rolul în browser poate fi ocolit cu o singură cerere modificată.
• Fără limitarea cererilor. Înregistrarea, logarea și orice endpoint care cheamă un API plătit pot fi bombardate până explodează factura sau inboxul.
• Un singur mediu. Testarea modificărilor direct pe baza de date live e felul în care se șterg date reale.

Ordinea de triaj: ce repari întâi

Listele publicate merg de la cele nouă remedieri ale unui inginer senior (secrete pe server, RLS, autentificare reală, CORS, rate limits, CI/CD, observabilitate și scalarea bazei de date) la o listă de 47 de puncte în nouă domenii și 12 verificări înainte să vină utilizatori reali. Se suprapun mult, dar le tratează pe toate ca egale. Când ai timp limitat, lucrează după risc:

Lista de întărire

Baza de date și autorizarea

• Găsește tabelele neprotejate. În editorul SQL al proiectului Supabase rulează select tablename from pg_tables where schemaname = 'public' and rowsecurity = false;. Orice rând întors e un tabel fără RLS.
• Activează Row Level Security pe fiecare tabel, inclusiv pe cele pe care le crezi nefolosite.
• Scrie politici care leagă fiecare rând de proprietarul lui: un utilizator citește și modifică doar rândurile unde coloana proprietarului e egală cu ID-ul lui autentificat. Fă politici separate pentru citire, inserare, modificare și ștergere.
• Testează cu două conturi reale: intră ca utilizatorul B și încearcă să încarci înregistrările lui A schimbând ID-uri în URL sau în cerere.
• Verifică la fel bucket-urile de stocare pentru fișiere încărcate; au propriile reguli de acces.
• Ține acțiunile de administrator în spatele unei verificări de rol pe server, nu al unui buton ascuns.

Secrete și logică pe server

• Caută în cod orice seamănă a cheie secretă (prefixe ca sk_, cuvinte ca secret sau service_role) și mut-o în funcții de server sau variabile de mediu.
• Schimbă orice cheie care a stat vreodată în codul client, chiar și scurt. Presupune că a fost copiată.
• Recalculează prețuri, totaluri și permisiuni pe server. Nu te baza pe ce trimite browserul.
• Restrânge CORS. În funcțiile de server, înlocuiește antetul Access-Control-Allow-Origin: * cu adresa exactă a domeniului tău, plus adresa de staging. Verifică apoi din consola browserului, de pe alt domeniu, că o cerere către funcție e respinsă.

Plăți

• Dă acces doar când un webhook de la procesatorul de plăți confirmă plata, nu când utilizatorul ajunge pe pagina de succes.
• Verifică semnăturile webhookurilor și fă handlerele sigure la rulare dublă: salvează ID-ul evenimentului și ignoră-l dacă vine a doua oară.
• Testează carduri respinse, rambursări și abonamente anulate, plus fluxul în care banca cere o confirmare suplimentară în aplicația ei (3D Secure). Plata trebuie să rămână în așteptare până la confirmare, nu să acorde acces între timp.

Medii și lansare

• Creează un proiect separat de staging, cu bază de date și chei proprii.
• Pune codul într-un depozit Git pe care îl controlezi, ca modificările să fie urmărite și reversibile.
• Protejează ramura principală: nimic nu ajunge acolo fără o cerere de integrare pe care ai citit-o.
• Automatizează lansarea în doi pași: fiecare integrare în ramura principală se publică întâi pe staging; producția primește doar ce ai verificat acolo.
• Rulează modificările bazei de date ca fișiere de migrare păstrate în depozit, aplicate întâi pe staging, niciodată prin editări manuale în tabelele live.

Backupuri, monitorizare și limite

• Confirmă că backupurile există și, mai important, exersează o restaurare într-un proiect separat.
• Adaugă urmărirea erorilor atât în front-end, cât și în funcțiile de server, ca să vezi și erorile pe care utilizatorul nu le raportează.
• Creează un endpoint simplu de verificare a stării, care face o interogare mică în baza de date, și pune un serviciu de monitorizare să-l apeleze regulat. Alertele trebuie să ajungă pe telefon, nu doar într-un e-mail citit a doua zi.
• Setează o alertă și pe creșteri bruște de erori de server, nu doar pe căderea completă.
• Limitează cererile la logare, înregistrare, resetarea parolei și orice endpoint care cheamă un serviciu plătit.
• Jurnalizează cine ce a făcut la acțiunile sensibile, fără parole sau date de card.

GDPR pentru utilizatorii din România și UE

Dacă ai utilizatori în România sau în altă țară din UE, regulile privind datele personale se aplică de la prima înregistrare. Punctele practice:

• Locația datelor. Verifică în ce regiune rulează proiectul bazei de date. Dacă poți alege, o regiune din UE îți scurtează lista de întrebări despre transferuri de date în afara Uniunii.
• Acorduri cu procesatorii. Orice serviciu care atinge datele utilizatorilor (bază de date, hosting, e-mail, plăți, analiză, AI) e un procesator. Semnează sau acceptă acordurile lor de prelucrare și trece-i în politica de confidențialitate.
• Politică de confidențialitate și cookie-uri. Spune ce colectezi, de ce și cât timp. Pentru cookie-uri și trackere care nu sunt strict necesare, cere consimțământul înainte să le încarci.
• Drepturile utilizatorilor. Asigură-te că poți exporta și șterge la cerere datele unui utilizator, inclusiv fișierele încărcate, și spune cât le păstrează backupurile.
• Pregătirea pentru incidente. Notează dinainte cine decide ce faci dacă descoperi date expuse. Dacă găsești un gol RLS care a stat deschis cât aplicația avea utilizatori, cere imediat părerea unui specialist despre eventualele obligații față de ANSPDCP și față de utilizatori.

Acesta nu e un sfat juridic; pentru domenii reglementate, ca sănătatea sau finanțele, vorbește cu un specialist.

Costurile după lansare

La nivel de noiembrie 2026, Lovable are un plan gratuit, iar planurile plătite încep de la 25 $/lună pentru Pro, cu 100 de credite, cu un nivel Business deasupra; fiecare plan include 20 de credite Cloud pe lună pentru găzduirea backendului, iar domeniile proprii cer un plan plătit. Planul gratuit dă 5 credite pe zi, plafonate la 30 pe lună. Tot planul gratuit afișează insigna Lovable pe aplicație, fără reportarea creditelor sau reîncărcări, iar Pro adaugă domenii proprii, eliminarea insignei, reportare și reîncărcări.

Pentru o aplicație live, bugetează mai mult decât constructorul: un plan plătit pentru domeniu și insignă, consumul bazei de date și al hostingului pe măsură ce crește traficul, un nume de domeniu, trimiterea de e-mailuri, urmărirea erorilor și comisioanele de plată. Prețurile sunt în dolari, deci socotește-le la cursul zilei și citește suma finală afișată la plată, nu doar prețul din pagina de planuri.

Repari singur sau predai unor ingineri

Poți parcurge o mare parte din listă cu prompturi dacă știi să citești codul generat, să rulezi testul cu două conturi și să înțelegi de ce funcționează o politică. Doar prompturile devin riscante când unealta spune că a reparat ceva și tu n-ai cum să verifici. Regula mea: orice reparație de securitate o confirmi cu un test pe care îl rulezi tu, nu cu mesajul unealtei.

Cheamă ingineri când e adevărat oricare dintre acestea:

• Lucrezi cu date medicale, financiare sau despre copii.
• Încasezi plăți sau ai abonamente.
• Ai găsit o problemă de RLS sau de secrete și nu știi câte mai sunt.
• Investitori, un client corporate sau o achiziție publică îți vor pune întrebări de securitate.
• Vrei să deții și să muți codul fără să depinzi de o singură unealtă.

Dacă preferi un cost cunoscut în locul unei facturi de agenție fără capăt, NOWWWA Studio construiește software de producție cu ingineri seniori și sistemul de agenți NOWWWA. Un MVP la preț fix costă 8.000 €, stabilit de la început, e livrat în aproximativ două săptămâni, iar codul e integral al tău. Pentru lucru continuu, abonamentul de dezvoltare costă 4.000 €, facturat la fiecare două săptămâni. Dacă vrei să vezi direcția înainte să te angajezi, Prototipul rapid pornește cu un avans de 99 €, scăzut din prețul construcției.

Indiferent ce alegi, începe cu testul cu două conturi și cu interogarea pentru tabelele fără RLS: îți arată repede cât de departe e aplicația de producție.