Platforma low-code wybrana na szybko rzadko boli w pierwszym kwartale. Boli po roku, kiedy aplikacja działa, zespół się do niej przyzwyczaił, a firma chce ją rozbudować albo przenieść. Wtedy okazuje się, że licencja liczona od każdego użytkownika rośnie razem z zespołem, logika aplikacji istnieje tylko w edytorze dostawcy, a eksport daje plik z danymi, nie działający program. W 2026 wybór jest przy tym szerszy niż dwa lata temu. Obok klasycznych platform doszli agenci AI, którzy piszą aplikację z opisu i oddają zwykły kod, oraz automatyzacje w rodzaju n8n. Ten tekst nie tłumaczy, czym jest low-code. Pokazuje, jak porównać platformy pięcioma kryteriami, zanim podpiszecie abonament. Ceny licencji podajemy z oficjalnych cenników dostawców według stanu na 26 września 2026. To nie jest cennik Devstocka.
Trzy rodziny narzędzi, między którymi wybierasz w 2026
W 2026 platforma low-code to jedna z trzech rodzin narzędzi, a dzieli je przede wszystkim to, co dostajecie na wyjściu: aplikację żyjącą u dostawcy, kod we własnym repozytorium albo przepływ danych między systemami. Od tego zależy reszta decyzji, łącznie z kosztem po roku. Przepływ danych między systemami pokazujemy na dwóch przykładach: automatyzacji księgowości i automatyzacji magazynu.
| Rodzina | Przykłady | Co zostaje u firmy | Jak się płaci |
|---|---|---|---|
| Klasyczne platformy low-code | Power Apps, OutSystems, Retool, Bubble | Aplikacja najczęściej działająca w środowisku dostawcy, u części platform także na własnej infrastrukturze | Zwykle za użytkownika albo według złożoności i zużycia |
| Agenci AI budujący aplikacje z opisu | Lovable, Claude Code, Codex | Kod aplikacji w repozytorium, a przeniesienie części serwerowej zależy od tego, gdzie działa | Za narzędzie do budowy, hosting zależnie od wybranego wariantu |
| Automatyzacje | n8n, Make, Zapier | Przepływy danych między systemami, a nie interfejs aplikacji dla użytkownika | Za wykonania albo abonament, n8n także na własnym serwerze |
Te rodziny nie konkurują ze sobą w każdym projekcie. Panel dla działu obsługi, publiczny serwis dla klientów i przerzucanie faktur między systemami to trzy różne zadania. Częsty błąd polega na tym, że firma wybiera jedno narzędzie do wszystkiego, bo zna je z poprzedniego projektu.
Przy automatyzacjach pytanie brzmi zresztą inaczej, bo ich rdzeniem są przepływy między systemami, a nie interfejs aplikacji. Porównanie narzędzi tej rodziny rozkładamy osobno w tekście n8n, Make czy Zapier. Tu skupiamy się na aplikacjach.
Pięć kryteriów wyboru platformy low-code
Platformę warto oceniać nie po liczbie gotowych komponentów, tylko po tym, co się stanie za rok. Liczy się, gdzie będą dane i kto będzie właścicielem logiki. Liczy się też rachunek przy trzy razy większym zespole, droga wyjścia na własny kod oraz to, kto odpowiada za bezpieczeństwo. Demo każdej platformy wygląda dobrze. Różnice wychodzą dopiero w tych pięciu miejscach.
Własność danych: gdzie leżą i jak je wyciągnąć
Pierwsze pytanie do dostawcy brzmi: w jakim formacie i jak często da się pobrać wszystkie dane. Eksport do CSV raz na jakiś czas to minimum, ale przy migracji liczą się też powiązania między tabelami, pliki i konta użytkowników. Warto też ustalić, w jakim regionie leżą dane i czy można je trzymać na własnej infrastrukturze. Przy danych klientów to pytanie wraca przy każdym audycie.
Własność logiki i kodu
Tu różnice między platformami są największe. Bubble pisze wprost w swojej dokumentacji o własności aplikacji, że aplikacje działają wyłącznie na jego platformie i nie da się ich wyeksportować jako kodu. Dane można pobrać, a logikę przy wyjściu trzeba zbudować od nowa. Lovable działa odwrotnie: według dokumentacji integracji z GitHubem projekt można synchronizować z repozytorium i wdrożyć poza Lovable. To samo dotyczy kodu pisanego przez Claude Code czy Codex, bo od początku powstaje w waszym repozytorium.
Ta różnica jest ważniejsza od każdej funkcji w edytorze. Własny kod można oddać innemu wykonawcy, przenieść na inny serwer albo rozbudować. Logikę zamkniętą w edytorze dostawcy trzeba dalej opłacać albo odtworzyć w nowym systemie.
Koszt przy skali użytkowników
Rachunek za platformę rośnie inaczej niż rachunek za własny kod, więc warto go policzyć przy docelowej liczbie osób, a nie przy pilotażu. Ceny poniżej to stawki katalogowe z oficjalnych cenników, odczytane 26 września 2026. Konkretne warunki zależą od umowy, a orientacyjny rachunek nie jest wyceną ani cennikiem Devstocka.
- Power Apps Premium kosztuje według cennika Microsoft 20 USD za użytkownika miesięcznie przy płatności rocznej. Przy 100 osobach to 2 000 USD miesięcznie, czyli 24 000 USD rocznie. Szczegóły planów opisujemy w tekście o Microsoft Power Apps dla firm.
- Retool Business liczy według cennika Retool 46 euro miesięcznie za osobę budującą aplikacje i 14 euro za użytkownika wewnętrznego, przy płatności rocznej. Trzy osoby budujące i 60 użytkowników to 978 euro miesięcznie.
- OutSystems nie publikuje cen, co potwierdza strona planów OutSystems. Wycena zależy od liczby ekranów, tabel i metod interfejsu w aplikacjach oraz od liczby użytkowników.
- Lovable według swojego cennika nie nalicza opłat za stanowiska. Zespół korzysta ze wspólnej puli kredytów, która obejmuje budowę, a według dokumentacji Lovable Cloud także hosting i wbudowaną część serwerową, czyli bazę i logikę po stronie serwera. Zewnętrzny hosting albo własna baza to osobny rachunek.
Model za użytkownika jest wygodny przy dziesięciu osobach i bolesny przy trzystu. Sukces aplikacji podnosi wtedy rachunek, bo każda nowa osoba w firmie to kolejna licencja. Przy kodzie we własnym repozytorium koszt zależy głównie od ruchu, infrastruktury i utrzymania, a nie od liczby kont.
Droga wyjścia na własny kod
Zanim wybierzecie platformę, zapiszcie, co zrobicie, gdy przestanie wystarczać. Przy platformie bez eksportu kodu wyjście oznacza przepisanie aplikacji od nowa, zwykle pod presją czasu, bo limit właśnie się skończył. Wtedy płacicie dwa razy: raz za platformę i drugi raz za docelowy system. Przy narzędziach oddających kod wyjście jest krótsze, ale nie zawsze bezbolesne. Kod leży w repozytorium, natomiast część serwerowa bywa różna. Jeśli aplikacja korzysta z zewnętrznego Supabase, tę bazę według dokumentacji Supabase da się uruchomić na własnym serwerze. Jeśli działa na wbudowanej części serwerowej Lovable Cloud, dokumentacja Lovable zastrzega, że przejścia na własny Supabase nie da się zrobić jednym kliknięciem. Trzeba wyeksportować dane i odtworzyć strukturę bazy.
Bezpieczeństwo: kto odpowiada za dostęp do danych
Szybkość budowy nie przenosi odpowiedzialności za dane na narzędzie. W maju 2025 opisano podatność CVE-2025-48757: w podatnych projektach budowanych w Lovable brakowało reguł dostępu na poziomie wierszy bazy danych albo były niewystarczające. W praktyce ktoś spoza aplikacji mógł sięgnąć do danych, których nie powinien widzieć. Wniosek dla firmy jest prosty. Aplikacja zbudowana z opisu działa, ale ktoś musi sprawdzić reguły dostępu, logowanie i płatności, zanim trafią do niej prawdziwi klienci.
Przy klasycznych platformach część tej pracy robi dostawca, ale nie cała. Uprawnienia użytkowników i to, kto widzi które rekordy, nadal konfiguruje wasz zespół albo wykonawca.
Jak trzy rodziny wypadają w pięciu kryteriach
Żadna rodzina nie wygrywa we wszystkich kryteriach, więc wybór sprowadza się do tego, które ryzyko jest dla was najdroższe. Poniższe zestawienie to uogólnienie. W każdej rodzinie są wyjątki: Retool i OutSystems mają warianty uruchamiane na własnej infrastrukturze, a Power Apps potrafi pracować na zewnętrznych źródłach danych.
| Kryterium | Klasyczne platformy | Agenci AI piszący kod | Automatyzacje |
|---|---|---|---|
| Dane | Eksport możliwy, zakres zależy od dostawcy i planu | W bazie, której przeniesienie zależy od wariantu części serwerowej | W systemach, które łączycie |
| Logika i kod | Często zamknięte w edytorze | Zwykły kod w repozytorium | Przepływy w narzędziu, n8n u siebie |
| Koszt przy skali | Zależnie od dostawcy: często rośnie z liczbą użytkowników, złożonością albo zużyciem | Rośnie z ruchem i utrzymaniem | Rośnie z liczbą wykonań |
| Wyjście na kod | Zwykle przepisanie od nowa | Kontynuacja na tym samym kodzie | Nie dotyczy, to nie aplikacja |
| Bezpieczeństwo | Część po stronie dostawcy | Kod i reguły aplikacji po waszej stronie, infrastruktura zależnie od hostingu | Zależne od miejsca uruchomienia |
Kiedy platforma low-code nie ma sensu
Low-code nie ma sensu wtedy, gdy koszt platformy albo koszt wyjścia z niej przewyższy to, co zyskaliście na szybkim starcie. W praktyce da się to rozpoznać po kilku sytuacjach:
- System na lata ze złożoną logiką. Dziesiątki reguł i wyjątków w edytorze wizualnym zamieniają się w plątaninę, której po roku nikt nie rozumie. Kiedy lepiej od razu zamówić własny system, rozkładamy w tekście o oprogramowaniu na zamówienie.
- Setki użytkowników przy licencji za osobę. Roczny koszt licencji staje się wtedy istotną pozycją budżetu, więc trzeba go porównać z wyceną budowy i utrzymania własnej aplikacji.
- Wrażliwe dane bez kontroli nad miejscem ich przechowywania. Jeśli prawnik albo klient wymaga danych na waszej infrastrukturze, platforma chmurowa bez takiej opcji odpada na starcie.
- Kod z AI bez właściciela. Aplikacja zbudowana z opisu, której nikt w firmie ani u wykonawcy nie przegląda i nie utrzymuje, jest długiem, a nie oszczędnością.
- Problem jest w procesie, nie w braku aplikacji. Jeśli zespół ręcznie przepisuje dane między systemami, zwykle wystarczy automatyzacja bez nowego ekranu.
Szersze tło tej decyzji, czyli kiedy low-code w ogóle się opłaca, opisujemy w przewodniku no-code i low-code dla firm.
Prototyp w dni, produkcja w tygodniach
Z agentami AI klikalny prototyp powstaje w dni, czasem w godziny, a działające wdrożenie zajmuje od tygodni do miesięcy, zależnie od zakresu. Prototyp systemu rezerwacji boisk przygotowaliśmy w około 30 minut od nagrania rozmowy z klientem. Pierwszą wersję platformy dla siatkarzy plażowych MUST BE MVP zbudowaliśmy w Lovable w trzy dni, na React, Vite, Supabase i Stripe. Serwis działa publicznie i obsługuje konta zawodników, zapisy na turnieje oraz płatności.
Różnica między prototypem a produkcją to nie wygląd, tylko wszystko, czego w demo nie widać. Chodzi o reguły dostępu w bazie, bezpieczne logowanie, płatności odporne na błędy, stabilny hosting, kopie zapasowe i SEO, jeśli serwis ma być znajdowany w Google. Ta część zajmuje więcej czasu niż samo zbudowanie ekranów.
Podobnie jest z automatyzacjami. Nasz własny system marketingu na n8n publikuje posty i przygotowuje kampanie, ale człowiek wybiera temat i zatwierdza wynik. Taki podział warto zaplanować od początku, a nie dokładać po pierwszej wpadce.
Korzystamy z najlepszych dostępnych rozwiązań i dobieramy je do projektu, dziś m.in. Claude Code, Codex, Lovable i n8n. Jeśli macie już prototyp albo dopiero wybieracie narzędzie, opiszcie projekt w formularzu kontaktowym. Odpowiemy, którą rodzinę narzędzi wybralibyśmy i dlaczego.
Devstock · Software house
Prototyp z AI działa? Przeprowadzimy go na produkcję
Aplikację z Lovable albo innego narzędzia AI sprawdzamy przed startem: bazę danych, reguły dostępu, logowanie i płatności. Dokładamy to, czego brakuje, wdrażamy i przenosimy projekt na docelową technologię, gdy przestanie wystarczać. Jeśli prototypu jeszcze nie ma, pierwszą wersję stawiamy w kilka dni.
Pokażcie nam swój prototyp →Pytania, które warto zadać przed podpisaniem umowy
Zanim wybierzecie platformę low-code, zadajcie dostawcy albo wykonawcy pięć pytań i poproście o odpowiedzi na piśmie:
- W jakim formacie pobierzemy wszystkie dane, razem z plikami i kontami użytkowników?
- Czy logikę aplikacji da się wyeksportować jako kod, czy przy wyjściu budujemy ją od nowa?
- Ile zapłacimy przy trzy razy większej liczbie użytkowników niż dziś?
- Kto konfiguruje i sprawdza reguły dostępu do danych przed startem?
- Jak wygląda przejście na własny kod, gdy platforma przestanie wystarczać?
Jeśli na drugie i piąte pytanie odpowiedź brzmi “od nowa”, nie jest to powód do rezygnacji. To sygnał, żeby koszt i czas wyjścia policzyć z góry i wpisać do decyzji, zanim aplikacja stanie się kluczowa dla firmy. Jak podchodzimy do takich projektów, od prototypu po przejście na kod, opisujemy na stronie usługi low-code i no-code.
FAQ – najczęstsze pytania o wybór platformy low-code
Czy aplikację z Lovable można przenieść na własny serwer?
Kod aplikacji tak. Lovable pozwala synchronizować projekt z repozytorium GitHub i wdrożyć go poza swoją platformą. Z częścią serwerową jest różnie. Zewnętrzny Supabase da się uruchomić na własnej infrastrukturze, ale wbudowanej części serwerowej Lovable Cloud nie przeniesie się jednym kliknięciem, więc dane i strukturę bazy trzeba przenieść osobno. Przy okazji warto sprawdzić reguły dostępu i konfigurację logowania, bo to one najczęściej wymagają poprawek.
Która platforma low-code jest najtańsza?
Nie ma jednej odpowiedzi, bo platformy liczą koszt inaczej. Przy kilkunastu użytkownikach licencja za osobę bywa tania, a przy kilkuset staje się największą pozycją budżetu. Porównujcie więc rachunek roczny przy docelowej liczbie użytkowników, a nie cenę startową z cennika.
Czy low-code nadaje się do aplikacji dla klientów, a nie tylko dla zespołu?
Tak, ale z dwoma warunkami. Model cenowy nie może rosnąć z każdym kontem klienta szybciej niż przychód z tych kont. Druga sprawa to bezpieczeństwo, które w publicznej aplikacji trzeba sprawdzić staranniej niż w wewnętrznym panelu, bo dostęp ma do niej każdy.
Ile trwa przejście z prototypu na produkcję?
Od kilku tygodni do kilku miesięcy, zależnie od zakresu. Najwięcej czasu zajmują integracje z istniejącymi systemami, liczba ról użytkowników i wymagania dotyczące danych. Sam prototyp powstaje dziś w dni, więc to przejście na produkcję, a nie budowa ekranów, decyduje o harmonogramie.
Podsumowanie
Wybór platformy low-code w 2026 to wybór między trzema rodzinami narzędzi: klasycznymi platformami, agentami AI piszącymi kod i automatyzacjami. Zamiast porównywać listy funkcji, sprawdźcie pięć rzeczy: gdzie leżą dane, czy logika istnieje jako kod, ile zapłacicie przy docelowej liczbie użytkowników, jak wyjdziecie na własny kod i kto odpowiada za reguły dostępu. Klasyczna platforma dobrze sprawdza się tam, gdzie firma świadomie akceptuje jej model cenowy i warunki wyjścia. Kod od agenta AI daje szybki start bez zamykania drogi, ale wymaga kogoś, kto przeprowadzi go na produkcję. Automatyzacja wystarcza tam, gdzie problemem jest proces, a nie brak ekranu. Jeśli chcecie przejść przez ten wybór na własnym przypadku, zostawcie opis projektu w formularzu wyceny i wrócimy z rekomendacją.
