Low-code czy custom development: jak wybrać bez przepłacania i długu technicznego

Firma potrzebuje uruchomić panel dla partnerów, zautomatyzować akceptację wniosków albo szybko sprawdzić nową usługę. Są dwie drogi. Pierwsza to złożyć rozwiązanie na platformie low-code w kilka tygodni z gotowych bloków. Druga to zaprojektować własny system i mieć pełną kontrolę nad logiką, danymi i interfejsem.

Pytanie low-code czy custom development często stawia się jako starcie „tanio kontra jakościowo”, ale to błędna rama. Low-code nie jest tanim zamiennikiem programistów, a custom nie musi oznaczać wieloletniego projektu za miliony. To różne narzędzia, a wybór zależy od tego, jak krytyczny jest proces, jakich integracji potrzebuje i jak zmieni się za rok czy dwa. Przeanalizujmy wybór na trzech typowych zadaniach.

Krótko o kategoriach

Platforma low-code pozwala budować interfejsy i procesy z gotowych komponentów, schematów wizualnych i konektorów. Kod pisze się tylko tam, gdzie standardowe możliwości nie wystarczają: Microsoft Power Apps, Retool, OutSystems, Mendix, a do automatyzacji procesów n8n, Make czy Zapier.

Platformy no-code takie jak Bubble, Glide czy Airtable są skierowane do osób bez umiejętności programowania. Granica między kategoriami jest płynna: każde poważne rozwiązanie, nawet złożone myszką, i tak wymaga specjalisty od architektury, bezpieczeństwa i integracji.

Zadanie 1. Panel partnerski dla 300 dealerów

Partnerzy mają widzieć swoje ceny, stany, historię zamówień i dokumenty. Dane leżą w ERP, dostęp potrzebny jest z zewnątrz, a każdy widzi tylko siebie.

Low-code zamyka tu interfejs i autoryzację w kilka tygodni, ale szybko napotyka dwie bariery: licencjonowanie za każdego użytkownika zewnętrznego oraz limity zapytań do ERP. Przy 300 partnerach koszt platformy może przewyższyć koszt wytworzenia już w drugim roku.

Praktyczny wniosek: jeśli z panelu korzystają dziesiątki osób wewnętrznych — wybierz low-code. Jeśli setki zewnętrznych — policz całkowity koszt posiadania na trzy lata; często wygrywa custom lub wariant hybrydowy, w którym backend jest własny, a panel administracyjny na platformie.

Zadanie 2. Akceptacja wniosków wewnątrz firmy

Wniosek zakupowy przechodzi przez trzech akceptujących, ma SLA i historię decyzji. Tutaj low-code jest niemal zawsze właściwą odpowiedzią: proces jest typowy, użytkownicy wewnętrzni, a integracje ograniczają się do poczty i katalogu pracowników.

Ryzyko jest inne — niekontrolowany rozrost. Po roku w firmie okazuje się, że działa czterdzieści automatyzacji bez dokumentacji, a osoba, która je budowała, odeszła. Dlatego nawet prosty proces potrzebuje właściciela aplikacji, rejestru integracji i przeglądu uprawnień raz na kwartał.

Zadanie 3. Konfigurator produktu z własną logiką cen

Klient wybiera parametry, system liczy cenę według złożonych reguł, sprawdza kompatybilność i rezerwuje materiały. To już przewaga konkurencyjna firmy.

Tutaj custom development jest uzasadniony: logikę trudno wyrazić blokami wizualnymi, obciążenie bywa nierówne, a trzymanie rdzenia biznesu na cudzej platformie jest ryzykowne. To samo dotyczy sytuacji, gdy danych osobowych klientów nie można przechowywać u zewnętrznego dostawcy albo interfejs musi być unikalny.

Porównanie podejść

Jak uczciwie policzyć koszt

Pierwszy prototyp na low-code faktycznie jest tani, ale rachunek rośnie niepostrzeżenie. W kalkulacji na trzy lata uwzględnij licencjonowanie wraz ze wzrostem liczby użytkowników, płatne konektory, limity operacji i rekordów, osobne plany dla środowisk testowych, pracę specjalisty wsparcia oraz koszt ewentualnej migracji.

Dla custom w tej samej tabeli znajdą się wytworzenie, hosting, testy, monitoring i rozwój. Często okazuje się, że w horyzoncie roku tańszy jest low-code, a w horyzoncie trzech lat już custom. Właśnie dlatego decyzję podejmuje się na podstawie TCO, a nie ceny startu.

Sprawdzenie platformy przed startem

Przed wyborem platformy warto ustalić kilka rzeczy: jak działa licencjonowanie przy wzroście liczby użytkowników, jakie limity mają API i magazyn danych, czy da się wyeksportować wszystkie dane w standardowym formacie, czy są osobne środowiska dla rozwoju i testów, kopie zapasowe oraz dziennik działań. I najważniejsze — jaki masz plan wyjścia z platformy, jeśli podrożeje albo przestanie odpowiadać.

Microsoft w zaleceniach dla Power Platform osobno podkreśla role administratorów, rozdzielenie środowisk, bezpieczeństwo i monitoring. Te zasady nie spowalniają pracy, ale chronią przed chaosem po roku.

Hybryda to najczęściej właściwa odpowiedź

Low-code i custom nie muszą stać w opozycji. Popularny model: krytyczna logika biznesowa i dane żyją we własnym backendzie, a wewnętrzny panel administracyjny czy raportowanie powstają na low-code ponad nim, przez API. Inny scenariusz: MVP na platformie weryfikuje hipotezę, po czym najcenniejsza część trafia do produktu custom.

Najważniejsze to z góry wyznaczyć granice. Platforma nie może stać się przypadkowym magazynem krytycznej logiki, której nie da się przenieść. O tym, jak rozpoznać moment, w którym gotowe rozwiązanie przestaje wystarczać, pisaliśmy w artykule „Kiedy sklep internetowy przerósł CMS” — większość sygnałów dotyczy też systemów wewnętrznych. A jeśli mowa o e-commerce z wieloma kanałami, do porównania warto dodać architekturę headless.

Pięć pytań przed decyzją

Na ile ten proces jest unikalny dla Twojej firmy? Co się stanie, jeśli platforma będzie niedostępna przez dzień lub tydzień? Jakie dane są przetwarzane i czy można je trzymać u zewnętrznego dostawcy? Ilu użytkowników i operacji spodziewasz się za rok? Jakich integracji potrzebujesz i czy platforma obsługuje je od razu?

Jeśli na większość pytań odpowiadasz „typowo, niewiele, obsługuje” — wybierz low-code. Jeśli co najmniej dwie odpowiedzi dotyczą unikalności, krytyczności lub skali, planuj custom albo hybrydę.

Często zadawane pytania

Czy system z low-code można później przenieść do custom?

Można, ale niemal zawsze oznacza to budowę od nowa. Dlatego od pierwszego dnia trzymaj dane w formacie, który da się wyeksportować, i dokumentuj logikę procesów.

Czy low-code jest bezpieczny?

Duże platformy dobrze chronią infrastrukturę. Ryzyka wynikają nie z platformy, lecz z niekontrolowanych uprawnień, publicznych linków i braku dziennika działań.

Co jest tańsze w perspektywie trzech lat?

Dla narzędzia wewnętrznego dla kilkudziesięciu użytkowników zwykle low-code. Dla systemu z setkami użytkowników zewnętrznych, złożonymi integracjami lub dużym obciążeniem częściej opłaca się custom.

Ile trwa MVP na low-code?

Typowe narzędzie wewnętrzne powstaje w dwa do sześciu tygodni wraz z integracjami. Najważniejsze to wcześniej ustalić, po czym uznacie hipotezę za potwierdzoną.

Jeśli proces jest typowy i trzeba szybko sprawdzić jego wartość, low-code bywa najlepszym startem. Jeśli system definiuje produkt, ma złożone integracje lub wysokie ryzyka, własna architektura daje więcej kontroli. GL.ua może przeprowadzić discovery, zbudować prototyp i pomóc wybrać podejście bez przywiązania do jednego narzędzia — więcej o naszych usługach tworzenia stron i systemów.