Lovable - jak zrobić działającą aplikację bez pisania kodu

Pierwszy prototyp w Lovable postawiłem w kilkanaście minut. Nie napisałem ani jednej linii kodu, tylko opisałem tekstem, co ma być na ekranie, i dostałem działającą aplikację pod własnym adresem. Poniżej cały mój workflow: co robię przed promptem, jak wygląda sam prompt, co dzieje się po wygenerowaniu i w którym miejscu Lovable przestaje wystarczać.

Czytanie: ~10 min

Czym jest Lovable i co dostajesz po pierwszym promptcie

Lovable zamienia opis tekstowy w aplikację webową. Wpisujesz „chcę panel do zgłaszania usterek na budowie, lista zgłoszeń, formularz dodawania, filtrowanie po statusie" i po chwili masz to na ekranie. Klikalne, z przechodzeniem między podstronami, z formularzami reagującymi na kliknięcia.

To nie jest makieta w Figmie ani obrazek do prezentacji. Pod spodem siedzi normalny projekt w React, który możesz pobrać i rozwijać dalej we własnym edytorze. Dla mnie to ma znaczenie, bo prototyp nie ląduje w koszu po pierwszym spotkaniu.

Interfejs przypomina czat. Po lewej piszesz, co chcesz zmienić, po prawej widzisz podgląd aplikacji na żywo. „Przesuń przycisk wyżej", „dodaj kolumnę z datą", „zrób ciemny motyw" - każda taka prośba to kolejna iteracja.

Hasło „bez kodowania" w praktyce znaczy, że nie musisz znać składni. Ale musisz wiedzieć, czego chcesz. To dwie zupełnie różne rzeczy i tu wykłada się większość osób startujących z takimi narzędziami.

Dlaczego jako backendowiec zaczynam każdy prototyp od ekranu

Piszę backend w .NET od lat. Mimo to, kiedy dostaję nowy pomysł na aplikację, pierwsze co robię, to frontend w Lovable.

Powód jest prozaiczny: klient nie kupuje mojego API. Klient kupuje to, co widzi. Kiedy wysyłam opis w mailu, dostaję odpowiedź „brzmi ok, działajmy". Kiedy wysyłam link do klikalnej apki, dostaję „tu bym zmienił kolejność, przycisk daj wyżej, i brakuje mi eksportu do Excela". Druga rozmowa jest warta dziesięć razy więcej niż pierwsza.

Jest jeszcze jeden efekt uboczny, który polubiłem. Ekran wymusza decyzje. Nie da się narysować formularza bez ustalenia, które pola są obowiązkowe. Nie da się zrobić listy, nie wiedząc, co ma być w kolumnach. Prototyp wyciąga na wierzch pytania, które przy opisie tekstowym potrafią się ukrywać tygodniami.

Do tego dochodzi rzecz czysto praktyczna: w kilka minut generuję dwie albo trzy wersje graficzne tego samego ekranu i daję klientowi wybrać. Zamiast zgadywać, co mu się spodoba.

Najpierw brainstorm, dopiero potem prompt

Typowy start początkującego wygląda tak: otwierasz Lovable, wpisujesz „zrób mi CRM", klikasz enter. Dostajesz coś generycznego, potem godzinę poprawiasz drobiazgi i po dwudziestu promptach masz bałagan, w którym nic nie pasuje do niczego.

Ja robię inaczej. Zanim w ogóle dotknę Lovable, przegaduję cały pomysł z ChatGPT albo Claude. Co ta aplikacja ma robić, dla kogo, jakie ma ekrany, jakie dane trzyma, co wchodzi do pierwszej wersji, a co spokojnie może poczekać. To zwykła rozmowa, zajmuje kwadrans albo dwa.

Dopiero na końcu proszę o jedną rzecz: „przygotuj mi na podstawie tego szczegółowy prompt do Lovable". I ten prompt wklejam.

Ta zmiana kolejności robi w całym procesie największą różnicę. Im lepszy kontekst na wejściu, tym mniej poprawek później - a poprawki kosztują kredyty i cierpliwość.

Co powinno znaleźć się w promptcie

Prompt, który u mnie działa, ma zwykle 300-500 słów i zawiera:

kto jest użytkownikiem i jaki problem rozwiązuje aplikacja
listę ekranów z nazwami (dashboard, lista zleceń, szczegóły zlecenia, ustawienia)
co konkretnie znajduje się na każdym ekranie: jakie kolumny, jakie pola formularza, jakie przyciski
styl wizualny opisany słowami: kolorystyka, czy ma być gęsto czy przestronnie, do jakiego znanego narzędzia ma być podobne
dane przykładowe, żeby aplikacja nie świeciła pustkami

Ten ostatni punkt jest notorycznie pomijany. Aplikacja z pustymi tabelami wygląda martwo i nikt jej nie kupi wzrokiem. Ta sama aplikacja z dziesięcioma wierszami realnie brzmiących danych wygląda jak gotowy produkt.

Od pomysłu do klikalnego prototypu w pięciu krokach

Mój pełny przepływ:

Brainstorm z ChatGPT lub Claude. Rozmowa o funkcjach i przepływach, zakończona prośbą o gotowy prompt.
Pierwszy prompt w Lovable. Wklejam całość i czekam. Dostaję szkielet aplikacji ze wszystkimi ekranami naraz.
Iteracje na drobiazgach. Poprawiam to, co nie trafiło: układ, kolory, brakujące pola. Jedna prośba na raz, nie pięć w jednym zdaniu - przy pięciu Lovable zwykle gubi jedną i musisz i tak wracać.
Publikacja i link. Klikasz publish, dostajesz adres url. Wysyłasz go komu chcesz, a ta osoba klika aplikację w przeglądarce, bez instalowania czegokolwiek.
Synchronizacja z GitHubem. Podpinam repozytorium, ściągam kod na dysk i pracuję dalej w Claude Code albo Codexie. Tam dopinam backend, bazę i integracje.

Krok piąty możesz pominąć, jeśli chcesz tylko pokazać pomysł. U mnie jest obowiązkowy, bo prototyp prawie zawsze zostaje fundamentem właściwej aplikacji.

Przykład z życia: panel zgłoszeń zrobiony w jeden wieczór

Przy jednym z pomysłów do Budda, mojego SaaS dla firm budowlanych, potrzebowałem ekranu do rejestrowania usterek na budowie. Kierownik robi zdjęcie, opisuje problem, przypisuje do ekipy, a właściciel widzi listę i statusy.

Brainstorm z Claude zajął mi jakieś dwadzieścia minut. Wyszło z niego, że w pierwszej wersji wystarczą trzy ekrany zamiast pięciu, bo raportowanie i ustawienia mogą spokojnie poczekać. Prompt urósł do jakichś czterystu słów.

Pierwsze generowanie dało dashboard z licznikami, listę usterek z filtrem po statusie i formularz dodawania ze zdjęciem. Wyglądało lepiej niż to, co sam sklepałbym w dwa wieczory w czystym Reakcie.

Potem trzy poprawki: kolorystyka bliżej marki, dodanie kolumny z terminem, przeniesienie przycisku dodawania w prawy górny róg. Cztery kredyty, jeden wieczór, gotowy link do wysłania.

Największą wartością nie była sama apka, tylko lista pytań, których wcześniej sobie nie zadałem. Co ze zgłoszeniami bez zdjęcia? Kto zamyka usterkę? Co jeśli ekipa nie ma zasięgu na budowie? Żadne z nich nie wypłynęłoby przy rozmowie nad kartką.

Kredyty w Lovable, czyli ile realnie zrobisz za darmo

Darmowy plan daje 5 kredytów dziennie. Jeden kredyt to jedna wiadomość do Lovable, czyli jedna zmiana w aplikacji.

Brzmi mało i faktycznie jest mało, ale przy dobrze przygotowanym pierwszym promptcie na frontend prototypu zwykle wystarcza. Pierwsza wiadomość generuje całość, kolejne trzy albo cztery idą na poprawki. Następnego dnia pula się odnawia.

Schody zaczynają się, gdy chcesz przez Lovable dokładać logikę: bazę danych, logowanie, funkcje AI. Wtedy dzienna pula kończy się szybko i albo czekasz do jutra, albo płacisz. Mnie to nie boli, bo backend i tak robię u siebie, a Lovable odpowiada wyłącznie za warstwę wizualną.

Jeśli dopiero testujesz narzędzie, zostań na darmowym planie i sprawdź, ile dni potrzebujesz na pierwszy sensowny prototyp. To uczciwszy sprawdzian niż porównywanie cenników w tabelce.

Czego Lovable za Ciebie nie zrobi

Tu kończy się entuzjazm, a zaczyna uczciwość.

Nie zaprojektuje aplikacji za Ciebie. Jeśli sam nie wiesz, jakie ekrany są potrzebne, dostaniesz uśrednioną wersję tego, co narzędzie widziało tysiące razy. Zwykle wygląda porządnie i zwykle nie odpowiada na Twój problem.

Nie ogarnie skomplikowanej logiki biznesowej. Rozliczenia, reguły podatkowe, walidacje zależne od kilku warunków naraz - tu potrzebujesz kogoś, kto to napisze i przetestuje. Lovable wygeneruje coś, co wygląda, jakby działało, a to najgorszy możliwy rodzaj błędu.

Nie zadba o bezpieczeństwo Twoich danych. Prototyp z prawdziwymi danymi klientów wystawiony pod publicznym adresem to proszenie się o kłopoty. Do demo używaj danych zmyślonych, zajmuje to pięć minut.

Nie podejmie za Ciebie decyzji, co w ogóle budować. Narzędzie skraca drogę od pomysłu do ekranu. Nie skraca drogi od „mam pomysł" do „wiem, że ktoś za to zapłaci".

Kiedy no-code ma sens, a kiedy szkoda czasu

Lovable sprawdza się, gdy:

chcesz sprawdzić pomysł, zanim wydasz pieniądze na zespół
musisz pokazać coś zarządowi albo klientowi na spotkaniu za trzy dni
potrzebujesz wewnętrznego narzędzia dla kilku osób i nikt nie ma czasu tego pisać
masz gotowy backend i brakuje Ci wyłącznie interfejsu

Odpuść, gdy budujesz produkt, który od pierwszego dnia ma obsłużyć tysiące użytkowników, gdy pracujesz z danymi wrażliwymi i masz wymogi zgodności, albo gdy logika jest ważniejsza od wyglądu i tak czy inaczej wszystko trzeba napisać ręcznie.

Traktuję Lovable jak szkic architekta. Szkic nie zastąpi projektu budowlanego, ale bez szkicu nikt nie wie, czy dom ma mieć jedno piętro czy dwa.

Co zrobić z gotowym prototypem

Prototyp ma jedno zadanie: doprowadzić do decyzji. Albo pomysł się broni i budujesz dalej, albo się nie broni i oszczędzasz sobie kilku miesięcy pracy nad czymś, czego nikt nie chce.

Dlatego po wygenerowaniu apki nie zostawiam jej na dysku. Wysyłam link konkretnym osobom, które mają z tego korzystać, i proszę o jedno: przeklikaj i powiedz, czego brakuje. Feedback z klikania jest zawsze konkretniejszy niż feedback z opisu.

A jeśli pomysł się obroni, kod z GitHuba idzie prosto do dalszej pracy. Frontend gotowy, backend do napisania, ale przynajmniej wiadomo po co.

Masz pomysł na aplikację i nie wiesz, czy się obroni? Zbuduję prototyp, na którym to sprawdzisz, zanim ktokolwiek przepali budżet na pełny projekt. Napisz do mnie przez mwozniczka.net/kontakt.