Aplikacje low-code oraz PWA zyskują coraz większą popularność. Są przedstawiane jako rozsądna i oszczędna alternatywa dla aplikacji hybrydowych. Dziś analizujemy różnice i pokazujemy dlaczego nie jest to dobry wybór.
Aplikacje Low-Code: Szybkość tworzenia kosztem elastyczności
Platformy low-code pozwalają tworzyć aplikacje za pomocą interfejsów graficznych, ograniczając konieczność ręcznego pisania kodu. To dobry wybór dla prostych projektów lub prototypów, jednak mają poważne wady, które stawiają pod znakiem zapytania wdrożenia produkcyjne:
- Nie jestem właścicielem kodu aplikacji – jest on u dostawcy narzędzia low-code
W przypadku platform low-code, kod źródłowy aplikacji pozostaje w rękach dostawcy. Oznacza to, że nie masz pełnej kontroli nad swoim produktem. Jeśli zdecydujesz się zmienić dostawcę lub przenieść aplikację na inną platformę, może to być trudne, a nawet niemożliwe bez przepisywania całego rozwiązania od zera. - Wszystkie dane użytkowników siedzą u dostawcy, a nie u mnie
Dane użytkowników są przechowywane na serwerach dostawcy low-code, co rodzi poważne problemy z bezpieczeństwem i zgodnością z przepisami (np. RODO). Nie masz pełnej kontroli nad tym, jak dane są przetwarzane, przechowywane czy zabezpieczane. W przypadku wycieku danych odpowiedzialność może spaść na Ciebie, mimo że nie masz wpływu na infrastrukturę. - Czekam, aż dostawca udostępni poprawki bugów i nowe funkcje
Rozwój aplikacji zależy od dostawcy platformy low-code. Jeśli napotkasz błąd lub będziesz potrzebować nowej funkcji, musisz czekać, aż dostawca ją zaimplementuje. To może opóźnić rozwój projektu i wpłynąć na satysfakcję użytkowników. W przypadku niszowych funkcji, możesz nigdy nie doczekać się ich wprowadzenia. - Twórca narzędzia low-code może zwiększyć mi opłaty
Platformy low-code często działają w modelu subskrypcyjnym, a ceny mogą rosnąć wraz z rozwojem aplikacji lub wzrostem liczby użytkowników. Dostawca może w dowolnym momencie podnieść opłaty, co może znacząco wpłynąć na budżet projektu. - Narzędzie może zniknąć ze względu na małą popularność / problemy finansowe twórcy i tracę wszystko
Jeśli dostawca platformy low-code upadnie lub zdecyduje się zamknąć usługę, stracisz dostęp do swojej aplikacji i danych. W takiej sytuacji odzyskanie funkcjonalności może być niemożliwe bez ponownego zbudowania aplikacji od podstaw na innej platformie.
Choć low-code przyspiesza developement, to brak swobody programistycznej sprawia, że rozwiązanie to nie nadaje się do ambitnych projektów. Twórcy aplikacji low-code uważają, że problem z eksportem kodu nie istnieje i podają liczne przykłady platform, które to umożliwiają. W każdym zbadanym przez nas przypadku twórcy platformy skutecznie powstrzymują użytkowników przed opuszczeniem ich ekosystemu. Niektórzy umożliwiają wyeksportowanie kodu aplikacji, ale musi być ona spięta z backendem dostawcy. Inni pozwalają na eksport wyłącznie pewnych fragmentów aplikacji a jeszcze inni wymuszają korzystanie z bibliotek, które łączą naszą aplikację z dostawcą no-code.
1. Bubble
🔹 Eksport kodu: ❌ Nie można pobrać kodu źródłowego
🔹 Alternatywa: Można używać API do interakcji z danymi, ale logika aplikacji jest zamknięta w ekosystemie Bubble.
2. Webflow
🔹 Eksport kodu: ✅ Tak, HTML, CSS, JS
🔹 Ograniczenia: Można eksportować kod frontendu, ale backend (np. CMS) pozostaje na serwerach Webflow.
3. Adalo
🔹 Eksport kodu: ❌ Nie można pobrać kodu źródłowego
🔹 Alternatywa: Można wygenerować aplikację mobilną (APK/IPA), ale kod nie jest dostępny.
4. Glide
🔹 Eksport kodu: ❌ Nie można pobrać kodu źródłowego
🔹 Alternatywa: Dane przechowywane w Google Sheets można eksportować.
5. OutSystems (low-code)
🔹 Eksport kodu: ✅ Tak, można wygenerować kod aplikacji (Java/.NET)
🔹 Ograniczenia: Część kodu nadal wymaga platformy OutSystems.
6. Mendix (low-code)
🔹 Eksport kodu: ✅ Tak, ale ograniczony dostęp
🔹 Ograniczenia: Można pobrać backend (np. Java) i front-end (React), ale aplikacja wciąż wymaga platformy Mendix.
7. Softr
🔹 Eksport kodu: ❌ Nie można pobrać kodu źródłowego
🔹 Alternatywa: Można eksportować dane (np. z Airtable), ale nie kod aplikacji.
8. FlutterFlow
🔹 Eksport kodu: ✅ Tak, kod Dart (Flutter)
🔹 Ograniczenia: Wymaga płatnego planu do pobrania kodu i wdrożenia poza FlutterFlow.
Tylko FlutterFlow nie robi problemów z eksportem kodu aplikacji, ale wygenerowany przez niego kod jest niskiej jakości i nawet jeśli trafi w ręce Flutter developera, to nie obędzie się bez większych modyfikacji – co oczywiście jest czasochłonne.
Nie polecamy stosowania low-code w aplikacjach, których celem jest monetaryzacja. Duże organizacje wykorzystują je wyłącznie do małych, wewnętrznych aplikacji albo do paneli administracyjnych dla ograniczonej liczby użytkowników.
Czy mimo tych wszystkich ograniczeń low-code ma sens?
Oczywiście, że w pewnych przypadkach wykorzystanie low-code daje wiele korzyści. Jeżeli nie dysponujesz żadnym budżetem, ale masz trochę wolnego czasu, to możesz samodzielnie spróbować stworzyć swoją pierwszą aplikację mobilną albo webową z wykorzystaniem tej technologii. Wystarczy jeden kurs na udemy i już masz wiedzę na poziomie “programisty” low-code. Dlatego nie warto płacić za tworzenie aplikacji tego typu freelancerom. Polecamy kursy z flutterflow. Kurs programowania no-code trwa 5 godzin. Kurs programowania aplikacji hybrydowych w React Native to 40 intensywnych godzin, po których prawdopodobnie i tak nie znajdziesz zatrudnienia, bo to zaledwie podstawy.
Czy taka aplikacja jest zbliżona do aplikacji napisanej przez programistę? Absolutnie nie. To jak stworzyć obraz w MS Paint, kiedy profesjonaliści używają Photoshopa. Możliwości customizacji są bardzo ograniczone, aplikacja jest uzależniona od zewnętrznych dostawców, a w dodatku jej kod nie należy do Ciebie. Baza danych? Firebase. Wysyłka maili? Sendgrid. Mapy? Tylko Google Maps. Płatności? Tylko Stripe. Powiadomienia? Tylko OneSignal. Spisz sobie koszty tych wszystkich usług a okaże się, że środowisko dla Twojej aplikacji kosztuje 10 razy tyle ile dla aplikacji natywnej czy hybrydowej.
Porównanie kosztów środowiska dla low-code i aplikacji hybrydowej
Low-code – 10 tyś. użytkowników
Baza danych Firebase Firestore: 900 zł miesięcznie
Wysyłka maili Sendgrid: 80 zł miesięcznie
Nawigacja Google Maps: 2000 zł miesięcznie przy 50 tyś. zapytań
Google Maps Geolokalizacja: 500 zł miesięcznie przy 50 tyś. zapytań
OneSignal do powiadomień push: 0zł miesięcznie przy 5000 aktywnych użytkowników aplikacji
Miesięczny koszt dla aplikacji, która wykorzystuje mapy i używa jej około 10000 użytkowników to około 3500 złotych miesięcznie.
Low-code – 50 tyś. użytkowników
Baza danych Firebase Firestore: 12000 zł miesięcznie
Wysyłka maili Sendgrid: 350 zł miesięcznie
Nawigacja Google Maps: 10000 zł miesięcznie przy 50 tyś. zapytań
Google Maps Geolokalizacja: 2500 zł miesięcznie przy 50 tyś. zapytań
OneSignal do powiadomień push: 400 zł miesięcznie
Miesięczny koszt dla aplikacji, która wykorzystuje mapy i używa jej około 50000 użytkowników to około 25000 złotych miesięcznie.
Aplikacja hybrydowa z własnym backendem – 10 tyś. użytkowników
Koszt serwera, który będzie w stanie obsłużyć 400 użytkowników korzystających z aplikacji w jednym czasie, to około 100 zł miesięcznie.
Baza danych: w cenie
Wysyłka maili: w cenie
Nawigacja TomTom: za darmo do 50 tyś. zapytań dziennie
Geolokalizacja TomTom: za darmo do 50 tyś zapytań dziennie
Firebase Push Notifications do powiadomień push: za darmo bez limitu
Miesięczny koszt dla aplikacji, która wykorzystuje mapy i używa jej około 10 000 użytkowników to 100 złotych miesięcznie.
Aplikacja hybrydowa z własnym backendem – 50 tyś. użytkowników
Koszt serwera, który będzie w stanie obsłużyć 5000 użytkowników korzystających z aplikacji w jednym czasie, to około 1000 zł miesięcznie.
Baza danych: w cenie
Wysyłka maili: w cenie
Nawigacja TomTom: 3000 zł miesięcznie
Geolokalizacja TomTom: 400 zł miesięcznie
Firebase Push Notifications do powiadomień push: za darmo bez limitu
Miesięczny koszt dla aplikacji, która wykorzystuje mapy i używa jej 50 000 użytkowników to około 4500 złotych miesięcznie.
Progressive Web Apps (PWA): Nowoczesność z ograniczeniami
PWA to aplikacje internetowe, które zachowują się jak natywne, oferując m.in. pracę offline czy powiadomienia push. Mimo zalet, ich wady są znaczące:
- Ograniczony dostęp do sprzętu: PWA mają utrudniony dostęp do zaawansowanych funkcji urządzeń (np. Bluetooth, skaner odcisków palców, NFC).
- Zależność od przeglądarki: Aby zainstalować na swoim telefonie aplikację PWA należy mieć zainstalowaną przeglądarkę Chrome albo Safari. Wielu użytkowników korzysta z szybszych przeglądarek innych firm a to sprawia, że nie będą mogli zainstalować Twojej aplikacji PWA.
- Problem z iOS: Apple wciąż ogranicza wsparcie dla niektórych funkcji w PWA. Z początkiem roku 2025 Apple potwierdziło, że iOS 17.4 wyłącza aplikacje PWA na ekranie głównym.
- Wydajność poniżej native: Choć PWA są szybsze niż tradycyjne strony, wciąż nie dorównują płynnością aplikacjom natywnym lub hybrydowym.
PWA sprawdzają się w projektach nastawionych na szybkość wdrożenia, ale brak pełnej integracji z systemem operacyjnym to poważny minus. Mają największy sens tam, gdzie istnieje już rozbudowana aplikacja webowa z dobrze zaprojektowanym RWD i chcemy ją bardzo szybko wprowadzić do sklepu Google Play / App Store. Jeżeli znasz HTML, CSS, JavaScript i myślisz o stworzeniu swojej pierwszej aplikacji, to jak najbardziej ma to sens.
W przypadku aplikacji PWA backend trzeba napisać samodzielnie albo korzystać z zewnętrznych usług jak w przypadku aplikacji low-code. Trzeba się liczyć z tym, że koszt utrzymania środowiska będzie zbliżony do low-code / no-code.
Aplikacje hybrydowe: Połączenie tego, co najlepsze
Aplikacje hybrydowe łączą technologie webowe (HTML, CSS, JavaScript) z natywnymi kontenerami, co pozwala im działać na dowolnej platformie. Dlaczego warto je wybrać?
- Jeden kod, wiele platform: Hybrydy eliminują konieczność pisania oddzielnego kodu dla iOS i Android, skracając czas rozwoju.
- Pełny dostęp do sprzętu: Dzięki pluginom (np. do kamery, GPS) hybrydy wykorzystują możliwości urządzeń tak samo jak aplikacje natywne.
- Natywny wygląd i wydajność: Frameworki takie jak Ionic czy React Native zapewniają płynność zbliżoną do rozwiązań natywnych, a komponenty UI dostosowują się do systemu operacyjnego.
- Obecność w sklepach: Hybrydy są publikowane jak tradycyjne aplikacje, co zwiększa ich widoczność i zaufanie użytkowników.
- Elastyczność i kontrola: W przeciwieństwie do low-code, developerzy mają pełną swobodę modyfikacji kodu, integracji z API czy optymalizacji.
O tym dlaczego nasze aplikacje mobilne piszemy w React Native przeczytasz na naszym blogu.
Podsumowanie: Hybrydy jako złoty środek
Podczas gdy aplikacje low-code więzną w szablonach, a PWA borykają się z ograniczeniami technologicznymi, hybrydowe rozwiązania oferują idealny kompromis. Łączą uniwersalność technologii webowych z dostępem do natywnych funkcji urządzeń, a przy tym pozwalają zachować kontrolę nad kodem i designem. W erze, gdzie czas wdrożenia i koszty są kluczowe, hybrydy stanowią przyszłościowy wybór zarówno dla startupów, jak i dużych przedsiębiorstw.
Low-code, no-code oraz PWA to szybka droga do MVP, ale wraz ze wzrostem użytkowników, negatywnych opinii na temat wydajności i mnóstwa błędów oraz rosnących kosztów zewnętrznych usług – będziesz musiał napisać całą aplikację od nowa w innej technologii. Jeżeli chcesz sprawdzić swój pomysł, to nie płać za stworzenie aplikacji mobilnej w tych technologiach tylko wyklikaj ją sam. Low-code nie jest alternatywą dla aplikacji natywnych i hybrydowych i nie jest warte nawet połowy kosztów stworzenia takiej aplikacji.
Chcesz przekonać się o tym, że aplikacja mobilna napisana w technologii hybrydowej może być równie tania jak no-code? Skorzystaj z naszego kalkulatora, aby przeprowadzić wstępną wycenę swojego projektu.
