Każdy obszar biznesowy zmienia się wraz z narzędziami
Z czasem każda branża się standaryzuje, a sposoby realizacji usług stają się szybsze i tańsze. Kiedyś meble wykonywano ręcznie na zamówienie, dziś linie produkcyjne i systemy modułowe pozwalają tworzyć je szybko, a jednocześnie dopasowywać do indywidualnych potrzeb.
Najczęściej takie zmiany zachodzą ewolucyjnie, ale wyjątkowe wydarzenia mogą gwałtownie je przyspieszyć. Tak było podczas pandemii COVID-19, kiedy sprzedaż w dużej mierze przeniosła się do Internetu. Pandemia minęła, ale zakupy online pozostały i stały się nowym standardem dla niemal każdego rodzaju sklepu.
Mechanizm takich zmian jest zwykle podobny:
- popularność produktu lub usługi zwiększa popyt,
- rosnący popyt prowadzi do wzrostu cen, konkurencji i problemów z dostępnością specjalistów,
- firmy zaczynają więc szukać nowych narzędzi i sposobów pracy,
- nowe rozwiązania początkowo budzą nieufność i opór, ale z czasem stają się koniecznością,
- branża adaptuje nowe narzędzia, które ostatecznie stają się standardem.
A potem cykl zaczyna się od nowa.
Historia cykli tradycyjnego programowania
Branża IT od początku rozwijała się według podobnego schematu: rosnące zapotrzebowanie na aplikacje prowadziło do powstawania nowych narzędzi, które upraszczały pracę programistów i przyspieszały rozwój kolejnych rozwiązań. Tak wyglądały najważniejsze etapy tej ewolucji:
- Karty perforowane i kod maszynowy (lata 40.–50.) – pierwsze programy tworzono za pomocą kodu maszynowego i kart perforowanych. Proces był powolny, skomplikowany i podatny na błędy. Odpowiedzią stały się asemblery, które pozwoliły zastąpić ciągi zer i jedynek bardziej czytelnymi instrukcjami.
- Języki wysokiego poziomu (lata 50.–70.) – wraz z rosnącym wykorzystaniem komputerów programowanie w asemblerze przestało być wystarczająco efektywne. Powstały języki takie jak Fortran, COBOL czy C, które pozwalały skupić się na logice programu zamiast na szczegółach działania sprzętu.
- Programowanie strukturalne i obiektowe (lata 70.–90.) – coraz większe systemy stawały się trudne w utrzymaniu i rozwijaniu oraz wymagały specjalistycznej wiedzy programistycznej. Nowe podejścia do organizacji kodu, wykorzystywane m.in. w Pascalu, C++ czy Javie, poprawiły jego czytelność, modularność i możliwość ponownego wykorzystania.
- Frameworki, RAD i gotowe komponenty (lata 90.–2010) – rozwój internetu, aplikacji desktopowych i mobilnych zwiększył presję na szybsze wdrażanie oprogramowania. Frameworki, biblioteki i narzędzia RAD pozwoliły korzystać z predefiniowanych komponentów zamiast tworzyć wszystko od podstaw. Znacznie przyspieszyło to pracę, ale nadal wymagało znajomości programowania.
Każdy z tych etapów obniżał próg wejścia i pozwalał zespołom IT przyspieszać proces tworzenia aplikacji. Kolejnym krokiem tej ewolucji stały się platformy no-code i low-code, które przenoszą ten proces jeszcze dalej, ograniczając ilość kodu potrzebnego do budowania aplikacji. O tym, czym jest low-code i no-code opowiemy w następnych akapitach.
Low-code i no-code development – kolejny cykl projektowania aplikacji
Wraz z postępującą cyfryzacją biznesu rosło zapotrzebowanie na nowe aplikacje, automatyzacje i narzędzia wspierające codzienną pracę firm. Trend ten dodatkowo przyspieszyła pandemia COVID-19, która zwiększyła znaczenie kanałów cyfrowych, e-commerce i pracy zdalnej.
Tradycyjne metody tworzenia oprogramowania, nawet przy wykorzystaniu frameworków i gotowych bibliotek, nie zawsze pozwalały realizować nowe projekty wystarczająco szybko. Firmy zaczęły więc szukać kolejnych sposobów na skrócenie procesu developmentu i zmniejszenie zależności od ograniczonych zasobów programistycznych. Odpowiedzią na te potrzeby stały się platformy low-code i no-code.
Czym jest low-code i no-code w tworzeniu oprogramowania?
Low-code i no-code to podejścia do tworzenia aplikacji, w których dużą część tradycyjnego programowania zastępują wizualne interfejsy, gotowe komponenty i wcześniej przygotowane mechanizmy. Zamiast pisać całą aplikację od podstaw, użytkownik może budować jej interfejs, logikę, bazę danych i automatyzacje za pomocą dostępnych elementów oraz integracji.
No-code jest skierowane przede wszystkim do osób bez doświadczenia programistycznego i pozwala tworzyć aplikacje bez konieczności pisania kodu lub przy jego minimalnym wykorzystaniu. Low-code działa na podobnej zasadzie, ale daje programistom większą możliwość rozszerzania gotowych funkcji za pomocą własnego kodu. Dzięki temu może być wykorzystywane do budowania bardziej złożonych i niestandardowych systemów.
Platformy takie jak Bubble, Webflow czy Zapier obniżają próg wejścia w tworzenie cyfrowych produktów i automatyzację procesów. Pozwalają firmom szybciej wdrażać nowe rozwiązania, a zespołom IT ograniczać liczbę prostych i powtarzalnych zadań. W tym sensie no-code i low-code są więc kolejnym etapem tego samego procesu, który wcześniej doprowadził do powstania języków wysokiego poziomu, frameworków i gotowych bibliotek.
Automatyzacja i sztuczna inteligencja (AI)
Co więcej, dzięki użyciu narzędzi low-code i no-code można w łatwy sposób integrować się z modelami LLM (z ang. Large Language Model) takimi jak Claude czy ChatGPT, tym samym uzbrajając nasze aplikacje w potężne narzędzie analizowania danych i podejmowania decyzji. Coś co kiedyś wymagało tysięcy linii kodu tradycyjnego oprogramowania, zostaje obecnie zastąpione prostą integracją dwóch uzupełniających się rozwiązań. Jednakże z tak dużymi możliwościami wiąże się również ogromna odpowiedzialność. Więcej o automatyzacji procesów biznesowych przeczytasz w naszym artykule: "Automatyzacja procesów biznesowych – usprawnij działanie swojej firmy!"
Low-code vs no-code – poznaj różnice
Najważniejsza różnica między no-code a low-code dotyczy zakresu ingerencji w kod. No-code pozwala budować aplikacje i automatyzacje głównie za pomocą wizualnych edytorów, konfiguracji oraz mechanizmów typu przeciągnij i upuść. Low-code działa podobnie, ale umożliwia dodatkowo rozszerzanie projektu własnym kodem tam, gdzie możliwości platformy okazują się niewystarczające.
No-code najlepiej sprawdza się przy prostszych, powtarzalnych procesach, takich jak formularze, wewnętrzne narzędzia, obiegi informacji czy podstawowe automatyzacje. Low-code daje z kolei większą elastyczność i kontrolę, dlatego lepiej radzi sobie z nietypową logiką, bardziej wymagającymi integracjami i rozbudowanymi procesami.
Granica między tymi podejściami nie zawsze jest jednak jednoznaczna. Wiele platform określanych jako no-code pozwala w razie potrzeby kodować wybrane fragmenty rozwiązania. Dobrym przykładem jest n8n, gdzie większość automatyzacji można zbudować wizualnie, a bardziej niestandardowe operacje uzupełnić własnym kodem.
No-code pozwala szybciej wystartować, natomiast low-code daje większą swobodę wtedy, gdy projekt zaczyna wykraczać poza standardowe możliwości wybranego narzędzia.
Czy Twoja firma potrzebuje programisty, czy tylko citizen developera?
Nie każdy projekt wymaga zaangażowania programisty od pierwszego dnia. Jeśli firma chce szybko zautomatyzować prosty proces, zbudować wewnętrzne narzędzie lub sprawdzić pomysł w formie MVP, często wystarczy no-code i osoba dobrze znająca proces biznesowy, czyli tzw. citizen developer.
Low-code staje się lepszym wyborem wtedy, gdy rozwiązanie wymaga większej liczby integracji, niestandardowej logiki, obsługi dużej ilości danych albo dodatkowych mechanizmów bezpieczeństwa i testowania. W takich przypadkach wiedza programistyczna pozwala wyjść poza ograniczenia platformy bez konieczności budowania całości od zera.
W praktyce wybór nie powinien więc sprowadzać się do pytania: „no-code czy programista?”. Najlepsze efekty często daje połączenie obu kompetencji. Citizen developer może szybko odwzorować proces i zbudować pierwszą wersję rozwiązania, a bardziej wymagające elementy przekazać osobom z doświadczeniem w integracjach, bezpieczeństwie czy architekturze.
Jakie są wady platform no-code i low-code?
Platformy no code/low code (NCLC) rewolucjonizują wdrażanie aplikacji i automatyzację procesów biznesowych jednak, jak w każdym cyklu z technologią, pojawiają się nowe wyzwania i obawy. Poniżej znajdziesz 4. główne wady technologii low-code i no-code, na które trzeba po prostu uważać.
1. Cyberbezpieczeństwo a narzędzia no-code
Aplikacje no-code są często tworzone przez osoby, które nie posiadają doświadczenia w programowaniu, dlatego mogą być bardziej narażone na błędy związane z bezpieczeństwem, np. niewłaściwym zarządzaniem danymi, brakiem szyfrowania czy błędną konfiguracją dostępu. Szybkość pracy metodą „przeciągnij i upuść”, na której opiera się no-code development, może dodatkowo sprzyjać pomijaniu dobrych praktyk, szczególnie gdy projekt powstaje bez nadzoru specjalistów IT.
W jednym z naszych projektów dla firmy produkcyjnej wykorzystaliśmy platformę low-code n8n do zautomatyzowania procesu ofertowania. System analizował dane klientów przy użyciu modelu AI, jednak klient nie chciał przekazywać zewnętrznemu dostawcy modelu sztucznej inteligencji danych osobowych ani informacji o cenach usług. Jednocześnie utrzymywanie prywatnego modelu AI na własnej infrastrukturze byłoby zbyt kosztowne.
Dlatego wdrożyliśmy kilka dodatkowych zabezpieczeń:
- anonimizację danych – przed wysłaniem informacji do modelu AI usuwane są wszystkie dane pozwalające zidentyfikować klienta,
- obliczanie wycen poza modelem AI – sztuczna inteligencja analizuje dane wejściowe, ale nie zna rzeczywistych cen usług; finalne obliczenia odbywają się poza modelem,
- testy penetracyjne – przed wdrożeniem rozwiązania przeprowadziliśmy testy bezpieczeństwa zgodne z OWASP Top 10.
Sam wybór platformy no code lub low code nie zwalnia więc z odpowiedzialności za bezpieczeństwo. W projektach przetwarzających wrażliwe dane kluczowe pozostają odpowiednia architektura, kontrola dostępu i niezależna weryfikacja zastosowanych zabezpieczeń.
2. Testowanie i zarządzanie QA w aplikacjach stworzonych narzędziami no-code i low-code
Wiele platform no-code do szybkiego tworzenia aplikacji, wykorzystuje wizualne edytory WYSIWYG, dzięki którym użytkownik może budować aplikację bez potrzeby kodowania jej od podstaw. Upraszcza to proces tworzenia, ale jednocześnie ukrywa część technicznej złożoności systemu. W rezultacie logika i konfiguracja bywają zapisane „na sztywno”, co utrudnia automatyczne testowanie i kontrolę jakości.
W jednym z naszych projektów, workflow automatyzacji przenosiło wiadomości e-mail od potencjalnych klientów do centralnej bazy. Problem pojawiał się podczas przerw technicznych serwera pocztowego. Po zerwaniu połączenia automatyzacja nie zawsze uruchamiała się ponownie, przez co klient mógł tracić potencjalnych klientów bez żadnego powiadomienia.
Rozwiązaliśmy ten problem na dwa sposoby:
- zmieniliśmy sposób komunikacji z serwerem pocztowym – zamiast utrzymywać stałe połączenie, serwer sam informował system o pojawieniu się nowej wiadomości,
- wdrożyliśmy testy automatyczne – aplikacja regularnie wysyła wiadomość testową i sprawdza, czy została poprawnie przetworzona; w przypadku błędu wysyłane jest powiadomienie.
W tym przypadku możliwości samego no-code okazały się niewystarczające, dlatego brakującą logikę uzupełniliśmy własnym kodem. To dobry przykład tego, że podejście typu low code development z użyciem nawet małej ilości kodu, pozwala zachować szybkość gotowych narzędzi, a jednocześnie daje większą elastyczność i kontrolę tam, gdzie jest ona rzeczywiście potrzebna.
3. Skalowalność technologii no-code w firmach
Nawet dobrze zaprojektowana aplikacja no-code lub low-code może mieć problemy z wydajnością. Wizualne narzędzia często ukrywają sposób wykonywania operacji w tle, dlatego osoba tworząca automatyzację może nie zauważyć, że zastosowane rozwiązanie działa dobrze dla kilkuset rekordów, ale przestaje być efektywne przy setkach tysięcy.
Z takim problemem spotkaliśmy się podczas migracji danych dla klienta z branży e-commerce. Początkowo proces został przygotowany przez osobę z działu Digital Sales, która miała doświadczenie w prostych automatyzacjach. Migracja trwała jednak godzinami, a każdy błąd wymagał ponownego uruchomienia całego procesu.
Analiza pokazała, że każdy rekord był przesyłany w osobnej transakcji bazodanowej. Platforma wykonywała więc setki tysięcy operacji, choć z poziomu wizualnego edytora problem był praktycznie niewidoczny. Po zmianie mechanizmu i przetwarzaniu danych zbiorczo czas migracji został skrócony o ponad 90%.
No-code pozwala szybko budować rozwiązania, ale nie eliminuje znaczenia wiedzy technicznej. Wraz ze wzrostem skali coraz ważniejsze stają się architektura, sposób przetwarzania danych i znajomość mechanizmów działających pod warstwą wizualnego interfejsu.
4. Modele licencyjne narzędzi low-code i no-code
Platformy NCLC różnią się nie tylko funkcjonalnością, ale również modelami rozliczeń. Jedne naliczają opłaty w zależności od użycia, inne od liczby użytkowników, dostępnych funkcji lub rodzaju infrastruktury. Dlatego wybór narzędzia wyłącznie na podstawie jego możliwości technicznych może prowadzić do niepotrzebnie wysokich kosztów.
Przy wyborze platformy warto analizować całkowity koszt posiadania, czyli TCO (Total Cost of Ownership), uwzględniający:
- koszty rozwojowe – związane z budową i dalszym rozwojem rozwiązania,
- koszty utrzymania – obejmujące m.in. infrastrukturę, administrację i wsparcie,
- koszty licencyjne – wynikające z modelu cenowego wybranej platformy.
Dobrym przykładem był projekt systemu obsługi kursów dla prywatnej uczelni. Airtable dobrze odpowiadał wymaganiom projektu, jednak przy dużej liczbie wykładowców i studentów standardowy model licencyjny generowałby zbyt wysokie koszty. Zaprojektowaliśmy więc system tak, aby płatnego dostępu z możliwością edycji potrzebowało jedynie kilka osób, natomiast pozostali użytkownicy korzystali z formularzy i dedykowanych interfejsów.
Dzięki temu zachowaliśmy możliwości platformy, a jednocześnie znacząco ograniczyliśmy koszty licencji. Pokazuje to, że przy świadomym projektowaniu rozwiązania platformy no-code i low-code mogą oferować zarówno szybkość wdrożenia, jak i odpowiednią elastyczność i kontrolę nad całkowitym kosztem systemu.
Podsumowując – kiedy wybrać no code, a kiedy low code?
No-code i low-code development pozwalają dziś budować aplikacje oraz automatyzować procesy znacznie szybciej niż przy wykorzystaniu tradycyjnych metod programowania. Przy prostych automatyzacjach, MVP czy wewnętrznych narzędziach często wystarczające będzie no-code obsługiwane przez mniej techniczne osoby dobrze znające proces biznesowy. Gdy jednak projekt obejmuje duże zbiory danych, niestandardową logikę, wymagania dotyczące bezpieczeństwa lub ma być rozwijany jako komercyjny produkt, lepiej zaangażować doświadczonych specjalistów i wykorzystać low-code lub klasyczne programowanie tam, gdzie jest to potrzebne. Najlepszy wybór zależy więc nie od samej popularności narzędzia, ale od skali, ryzyka i przyszłych planów związanych z projektem.