Gdzie kończy się no-code — Airtable, Glide, Softr, Bubble — limity z dokumentacji?

Co realnie powstaje bez kodu?

Cztery nazwy z tytułu to cztery różne rzeczy. Airtable jest bazą danych z widokami i automatyzacjami. Softr stawia interfejs nad cudzym źródłem danych. Glide robi aplikację z tabeli, a Bubble buduje całą aplikację razem z własną bazą i własnym API.

To rozróżnienie decyduje o tym, gdzie pojawi się granica. W Airtable pierwszy przychodzi limit rekordów, w Softr — limit użytkowników aplikacji, w Bubble — limity opisane w dokumentacji wprost jako twarde.

Airtable w planie darmowym mieści 1 000 rekordów na bazę i 1 GB załączników. Plan Team podnosi to do 50 000 rekordów i 20 GB, Business do 125 000 rekordów i 100 GB (dokumentacja producenta, odczyt 31 sierpnia 2026).

Cennik Airtable podaje 20 USD za użytkownika miesięcznie w planie Team i 45 USD w Business przy rozliczeniu rocznym. Samych limitów strona cennika nie pokazuje — liczby wyżej pochodzą z porównania planów w dokumentacji.

Glide w cenniku wymienia plan darmowy z jednym projektem, jedną aplikacją i 100 MB pamięci, plan Solo za 25 USD miesięcznie z 25 GB oraz Team za 125 USD ze 100 GB. Limitu wierszy ani liczby aktualizacji miesięcznych nie znaleźliśmy w dokumentacji na dzień 31 sierpnia 2026.

Softr rozlicza się użytkownikami i to w nim jest liczba do pilnowania. Plan darmowy daje jedną wspólną pulę 5 użytkowników (bez osobnych miejsc dla użytkowników aplikacji), Basic — 5 i 5, Pro za 119 USD miesięcznie — 10 i 50, Business za 395 USD — 30 i 100.

Każdy użytkownik ponad próg kosztuje od 1 do 2 USD, do sufitu 250 albo 500 osób.

Bubble kosztuje 29 USD miesięcznie w planie Starter, 119 USD w Growth i 349 USD w Team przy rozliczeniu rocznym dla wersji webowej. Zużycie liczy jednostkami workload units, czyli — jak pisze dokumentacja — zasobami serwera potrzebnymi do uruchomienia i skalowania aplikacji.

Ile tych jednostek mieści plan, nie znaleźliśmy w dokumentacji na dzień 31 sierpnia 2026; strony cenników Bubble i Softr pokazują tabele dopiero po uruchomieniu w przeglądarce. Dokumentacja podaje za to stawkę ponad limit: 0,30 USD za każde 1 000 jednostek.

Ceny i limity zmieniają się w trakcie roku. Data odczytu przy liczbie znaczy tu więcej niż sama liczba — każdą sprawdź w cenniku, zanim oprzesz na niej decyzję.

Gdzie dokładnie przebiega granica?

Granica nie jest jedna. Każdy obszar ma własny próg, własne źródło i własną odpowiedź na pytanie, co robić po jego przekroczeniu.

Dwie liczby z tej tabeli zaskakują częściej niż limit rekordów. Airtable przyjmuje 5 zapytań na sekundę na jedną bazę, a po przekroczeniu odpowiada kodem 429 i każe czekać 30 sekund — integracja, która co noc przelicza cennik, trafia na to szybciej niż na limit wierszy.

Druga to reguły prywatności w Bubble. Dokumentacja ostrzega, że dane, które doszły do urządzenia użytkownika, z definicji przestają być bezpieczne, a jedyną pewną metodą jest nie wysyłać ich z serwera.

Kiedy przepisać aplikację bez kodu?

Sygnałów jest pięć. Każdy znaczy to samo: od tego momentu błąd kosztuje pieniądze albo cudze dane, a nie tylko czas.

• Drugi typ użytkownika z innymi uprawnieniami. Jeden zestaw ludzi patrzy na te same dane i wystarczy jeden widok. Dwa zestawy wymagają reguły na wiersz — a ta musi działać po stronie serwera, nie w przeglądarce.
• Pieniądze w aplikacji. Płatność zapisuje się z powiadomienia operatora, nie z ekranu podziękowania. Aplikacja, która sama zalicza wpłatę po powrocie z bramki, myli się dokładnie wtedy, gdy jest najdrożej.
• Dane osobowe osób trzecich w skali. Wchodzą obowiązki administratora: usunięcie z każdej tabeli, eksport, retencja. Narzędzie bez reguł per wiersz robi z tego pracę ręczną.
• Limit API blokuje integrację. 1 000 wywołań miesięcznie w darmowym planie Airtable wyczerpuje jedna synchronizacja z magazynem, a 5 zapytań na sekundę — jeden import.
• Rozliczenie rośnie z każdym kontem. Softr liczy użytkowników aplikacji i po przekroczeniu progu dopisuje 1–2 USD za osobę. Sam rachunek jest tematem osobnego zestawienia; tu liczy się sufit: 250 albo 500 użytkowników.

Punkt docelowy w naszej praktyce jest zawsze ten sam: jedna baza Postgres z politykami dostępu na poziomie wierszy i jednym modelem uprawnień. Nie dlatego, że jest modna — dlatego, że mieści oba typy użytkowników bez dopłaty za konto i bez sufitu z cennika.

Rozdzielanie jej na osobne usługi zaczyna mieć sens dopiero wtedy, gdy wymusza to obciążenie albo wielkość zespołu. Do tysięcy kont mniej ruchomych części znaczy jedną kopię zapasową i jeden zestaw reguł do sprawdzenia.

Trzy rzeczy sprawdzamy u siebie zawsze, bo w narzędziach bez kodu wyglądają na zrobione, a nie są. Rola zalogowanego użytkownika to nie administrator — uprawnienie administratora czytamy z osobnej tabeli ról. Identyfikator w adresie nie jest hasłem. Ograniczenie widoczności kolumn bez polityki na wiersze jest pozorne.

Reszta listy rzeczy, które trzeba sprawdzić przed wypuszczeniem aplikacji do ludzi, jest w tekście o zasadach bezpieczeństwa od pierwszego dnia. Granice generatorów AI, które budują kod zamiast klikanego interfejsu, opisuje osobny artykuł o vibe codingu.

Jak przenieść dane, gdy przychodzi czas?

Przeprowadzka z narzędzia bez kodu to sześć kroków. Żaden z nich nie wymaga pisania kodu przez zamawiającego — wymagają decyzji, które i tak trzeba podjąć.

1. Spisz tabele, pola i typy. Przy okazji wychodzi, ile kolumn powstało „na chwilę” i nikt ich nie czyta. Do nowej bazy przenosi się to, co ma właściciela i zastosowanie.
2. Spisz, kto co widzi. Dla każdej tabeli jedno zdanie: który użytkownik widzi które wiersze i który może je zmieniać. To zdanie staje się później polityką dostępu.
3. Wyciągnij dane. Bubble eksportuje bazę do CSV, JSON i NDJSON; z Airtable dane pobiera się przez API, pamiętając o 5 zapytaniach na sekundę na bazę.
4. Odtwórz relacje. W arkuszu relacja jest tekstem, w bazie — kluczem. Ten krok decyduje o tym, czy raporty po przeprowadzce dadzą te same liczby.
5. Załóż polityki dostępu, zanim wpuścisz ludzi. Pusta baza z otwartymi tabelami wygląda tak samo jak zabezpieczona, dopóki ktoś nie zajrzy.
6. Zostaw interfejs, jeśli działa. Softr potrafi stać nad SQL, Supabase, BigQuery albo Xano — bez limitu rekordów po stronie źródła. Zmiana bazy nie musi znaczyć zmiany ekranów.

Kolejność ma znaczenie, bo najdroższy błąd tej operacji to uruchomienie nowej bazy bez punktu drugiego. Reguły dostępu dopisywane po wpuszczeniu użytkowników pisze się już pod presją zgłoszeń.

Dwa pytania należą do innych serwisów i tutaj ich nie rozstrzygamy: czym w ogóle budować oraz czyj jest kod i aplikacja zbudowana bez kodu. Zakres pierwszej wersji, który przenosisz do nowej bazy, opisuje tekst o zakresie MVP.