Bez lukru
Wady Lovable — czego nie powie ci reklama
Szukasz opinii, więc szukasz haczyka. Oto wszystkie, które znalazłem, razem z tym, jak je obejść.
Kredyty znikają szybciej, niż się spodziewasz
To najczęstszy zarzut w całym zbiorze opinii i wraca w każdej krytycznej recenzji. Mechanika jest prosta: każde wywołanie modelu kosztuje, niezależnie od tego, czy budujesz nową funkcję, czy naprawiasz coś, co samo się zepsuło. Przy większym projekcie znaczna część budżetu idzie na drugą kategorię.
Jak to obejść: pisz długie, konkretne prompty zamiast serii krótkich. Zapisuj wersję po każdej udanej zmianie — powrót jest tańszy niż naprawa. Drobne poprawki rób w edytorze wizualnym. Kiedy model zapętla się na błędzie, cofnij się i przeformułuj zamiast poprawiać w kółko.
Przy większych projektach AI gubi kontekst
Granica jest płynna, ale w opiniach wraca ten sam moment: kilkanaście–kilkadziesiąt ekranów, rozbudowana baza, kilka ról użytkowników. Wtedy zaczynają się zmiany w miejscach, o które nie prosiłeś, i regresje w działających już funkcjach.
Jak to obejść: trzymaj projekt modułowo i proś o plan przed wykonaniem zmiany. Kiedy przekroczysz tę granicę, rozsądniej jest pobrać kod na GitHuba i rozwijać go dalej w Cursorze albo oddać programiście. Lovable świetnie zaczyna projekt; nie musi go prowadzić przez całe życie.
SEO wymaga dodatkowej pracy
Aplikacje generowane przez Lovable renderują treść po stronie przeglądarki. Google sobie z tym radzi, ale wolniej i mniej niezawodnie niż ze zwykłym HTML-em. Dla panelu wewnętrznego to bez znaczenia. Dla strony, która ma zarabiać na ruchu z wyszukiwarki, to realna przeszkoda.
Jak to obejść: zadbaj o tytuły, opisy i dane strukturalne dla każdej podstrony, wystaw mapę witryny, a treści blogowe trzymaj poza aplikacją — na osobnym CMS-ie albo statycznie. Przy projekcie mocno nastawionym na SEO warto pobrać kod i wdrożyć renderowanie po stronie serwera.
Obsługa klienta i rozliczenia
Pierwszą linią wsparcia jest bot. W kilku recenzjach wraca ta sama historia: użytkownik prosi o przegląd zużytych kredytów przez człowieka i dostaje ogólne porady. Pojawiają się też pojedyncze skargi na podwójne obciążenia i utratę projektu.
Uczciwie: to mniejszość opinii, a firma odpowiada publicznie na 28% negatywnych recenzji i w części przypadków zwraca pieniądze. Ale jeśli budujesz coś, od czego zależy twój biznes, trzymaj własną kopię kodu na GitHubie. To zajmuje minutę i rozwiązuje większość z tych scenariuszy.
Dla kogo Lovable to strata pieniędzy
Aplikacje przetwarzające dane medyczne, finansowe albo inne objęte szczególnymi regulacjami. Systemy o wysokich wymaganiach bezpieczeństwa, gdzie potrzebny jest audyt kodu. Rozbudowa istniejącej, dużej aplikacji. Projekty z twardym reżimem zgodności i odpowiedzialnością kontraktową za efekt. W tych przypadkach koszt naprawy błędu przewyższy wszystko, co zaoszczędzisz na starcie.
Mimo tej listy bilans dla większości czytelników tej strony nadal wychodzi na plus. Powód jest prosty: prawie wszystkie zarzuty dotyczą długiego życia dużego projektu, a większość ludzi przychodzi tu po jeden konkretny projekt, który trzeba zrobić szybko i tanio.