Czego nie musisz umieć, żeby mieć aplikację dla swojej branży — i jak dzielą się role z zespołem, który buduje?

Czego naprawdę nie musisz umieć — i dlaczego to nie jest brak

Własnego specjalistę ICT zatrudniało w 2024 r. 19,4 % polskich firm o 10–49 pracujących i 88,1 % firm powyżej 250 osób. Brak informatyka w firmie Twojej wielkości jest stanem normalnym, a nie zaległością do nadrobienia przed rozmową o aplikacji.

Dane za 2024 r. z bazy Eurostatu (zbiór o firmach zatrudniających specjalistów ICT, odczyt 16 września 2026 r.). Badanie obejmuje firmy zatrudniające co najmniej 10 osób, więc dla mikrofirm takiego odsetka po prostu nie znamy — nie jest on „jeszcze niższy”, tylko niemierzony.

Zatrudnienie specjalisty nie jest zresztą drogą na skróty. W 2023 r. próbowało tego 3,3 % polskich firm o 10–49 pracujących, a 1,0 % zgłosiło wakat, którego nie umiało obsadzić. W całej Unii wśród firm rekrutujących specjalistów ICT trudności z obsadzeniem miało 57,5 %.

Kupowanie kompetencji technicznej zamiast budowania jej u siebie jest dziś normą także w warstwie sprzętu i oprogramowania: z płatnych usług chmury obliczeniowej korzystało w 2025 r. 55,3 % przedsiębiorstw w Polsce, a wśród firm małych — 50,8 % (GUS, badanie obejmuje podmioty o liczbie pracujących 10 osób i więcej).

Lista rzeczy, których nie musisz umieć, jest krótsza, niż się wydaje: pisać kodu, zaprojektować bazy i uprawnień do niej, spiąć operatora płatności, ustawić domeny, certyfikatu i poczty, pilnować kopii zapasowych z testem odtworzenia.

Z czego taka aplikacja jest złożona, opisaliśmy w tekście o warstwach aplikacji dla firmy. Nie musisz też zbudować jej sam narzędziami AI — gdzie ta droga się kończy, sprawdziliśmy w tekście o granicach budowania aplikacji z AI.

Twój wkład jest gdzie indziej i nikt go nie kupi na rynku pracy: znasz proces branży, jej wyjątki, słownik i ludzi. Tego nie da się wyczytać z dokumentacji ani ze specyfikacji dostarczonej przez firmę z zewnątrz.

Ile Twojego czasu to zabiera — i czego nie zmierzyliśmy

Ile godzin właściciel firmy spędza nad każdym etapem budowy — nie mierzyliśmy i nie będziemy tego zgadywać. Zapisane są za to okna, w których decyzja należy wyłącznie do Ciebie, bo biorą się z umów i z praktyki.

Trzy z nich warto znać przed pierwszą rozmową o budowie: 7 dni na uwagi po zgłoszeniu do odbioru, 90 dni gwarancji usuwania błędów i 1 dzień roboczy na reakcję przy zgłoszeniu krytycznym po starcie.

To są okna z umów i z praktyki, a nie pomiar Twojego czasu — mylenie jednego z drugim kończy się obietnicą „to zajmie pół dnia”, której nikt nie policzył. Kolejność samych prac opisuje dziesięć kroków budowy aplikacji, a listy materiałów tu nie powtarzamy: jest w tekście o wkładzie zamawiającego.

Jedno widać w tej tabeli od razu: prawie każde okno zamyka Twoja odpowiedź, nie cudza praca. Dlatego po Twojej stronie musi stać jedna osoba decyzyjna z nazwiskiem — także wtedy, gdy tą osobą jesteś Ty sam, a czas na decyzje masz po zamknięciu firmy.

Konkurent jako partner: kto odbiera zgłoszenie, gdy jego aplikacja stanie?

Firma z branży, która dziś jest konkurencją, przed ceną zadaje dwa pytania: kto naprawi awarię i kto odpowiada, gdy zawiedzie ktoś z łańcucha — na to drugie przepisy odpowiadają wprost (art. 28 ust. 4 RODO). Odpowiedzią jest podział ról, nie zapewnienie, że „wszystko będzie działać”.

Gdy partner wpuszcza do Twojej aplikacji dane swoich klientów, zostaje ich administratorem, Ty przetwarzasz je na jego polecenie, a zespół techniczny i dostawcy infrastruktury są dalszymi podmiotami przetwarzającymi. Z tego układu wynikają trzy rzeczy, które partner sprawdzi, zanim podpisze.

• Kogo dokładasz do łańcucha, wie partner. Podmiot przetwarzający nie korzysta z usług innego podmiotu bez uprzedniej pisemnej zgody administratora, a przy zgodzie ogólnej informuje o każdej zamierzonej zmianie i daje możliwość sprzeciwu (art. 28 ust. 2).
• Partner ma prawo sprawdzić, nie tylko uwierzyć. Umowa powierzenia zobowiązuje do udostępnienia informacji potrzebnych do wykazania zgodności oraz do umożliwienia audytów i inspekcji przeprowadzanych przez administratora albo upoważnionego przez niego audytora (art. 28 ust. 3 lit. h).
• Odpowiedzialności nie oddajesz razem z pracą. Jeżeli dalszy podmiot przetwarzający nie wywiąże się ze swoich obowiązków, pełna odpowiedzialność wobec administratora spoczywa na podmiocie pierwotnym — czyli na Tobie, nie na zespole (art. 28 ust. 4).

Partner nie przestaje przy tym odpowiadać za swoje dane: jako administrator ma wdrożyć odpowiednie środki techniczne i organizacyjne oraz umieć to wykazać (art. 24 ust. 1). Dlatego pyta o dowody, zamiast poprzestać na zapewnieniu — i dlatego warto mu je pokazać wcześniej, niż zapyta.

Podstawa: rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO), art. 24 i art. 28 (odczyt 16 września 2026 r.).

Konkurenta przekonuje nazwany tor zgłoszenia z czasem reakcji zamiast obietnicy, jawna lista firm stojących za aplikacją i to, że pierwszą osobą, z którą rozmawia, jest ktoś z branży, a nie konsultant czytający skrypt.

Boi się czegoś innego: że jego awaria trafi do jednej skrzynki, w której siedzi człowiek zajęty własnymi zleceniami. Odpowiedź musi być podziałem pracy — zgłoszenie przyjmujesz Ty i tłumaczysz je na język procesu, usuwa je zespół, który utrzymuje aplikację na co dzień.

Zapisać trzeba cztery rzeczy: kto przyjmuje zgłoszenie i w jakim czasie reaguje, kto może dołożyć albo zmienić dostawcę, co partner zabiera przy wyjściu i kto odpowiada, gdy zawiedzie ktoś z łańcucha. Zasady, które to umożliwiają po stronie technicznej, zebraliśmy w zasadach bezpieczeństwa od pierwszego dnia.

Co zostaje po Twojej stronie, a co robi zespół, który buduje

Dziesięć obszarów rozstrzyga o tym, kto za co odpowiada — i w każdym z nich zamiana ról kosztuje konkretne pieniądze albo tygodnie. Zasada jest jedna: Twoje jest wszystko, co wymaga wiedzy o branży i podpisu; zespołu — wszystko, co wymaga wiedzy o tym, jak działa oprogramowanie.

Tabela nie zabrania pytać o technikę — przeciwnie, pytania są Twoim narzędziem kontroli. Zabrania czegoś innego: podejmowania cudzych decyzji. Wybór bazy nie jest Twoją decyzją, ale zdanie „ceny konkurenta nie mogą być widoczne dla innych firm” już tak, i to zdanie zmienia model uprawnień.

Działa to też w drugą stronę. Gdy zespół zaczyna rozstrzygać, jak wygląda proces w Twojej branży, powstaje oprogramowanie poprawne technicznie i bezużyteczne w pracy — a to najdroższy rodzaj sprawnie zbudowanej aplikacji.

Dowody, po których poznasz, że praca jest sprawdzona

Zdanie „testujemy” nic nie znaczy, dopóki nie wiadomo, co blokuje wdrożenie i co wymaga Twojego podpisu. Pięć rzeczy da się pokazać i sprawdzić bez wiedzy technicznej.

• Polityki dostępu na poziomie wierszy są włączone od pierwszej migracji, a automat kontroli kodu odrzuca politykę „wpuść wszystkich”. Rola operatora jest przypięta do identyfikatora użytkownika, nie do adresu e-mail — inaczej ktoś zrobiłby się operatorem, rejestrując się na ten sam adres.
• Pętla poprawek ma budżet z góry: trzy rundy krytyki na krok. Czwarta nie startuje — zamiast niej zapada decyzja: wzmocnić krytykę i zamknąć albo wypuścić i resztę odłożyć. Wyjątek jest jeden: audyt bezpieczeństwa powtarza się do czystej rundy.
• Zadania cykliczne sprawdzamy w bazie, nie w plikach. Plik z migracją nie jest dowodem, że automat naprawdę działa; przed startem produkcyjnym liczy się to, co faktycznie istnieje w bazie.
• Kolejność uruchamiania jest stała: domena, hosting, baza, sekrety, funkcje, zadania cykliczne. Odwrotna kolejność wysyła prawdziwym użytkownikom link do nieistniejącej domeny, na przykład w mailu resetującym hasło.
• Testy od końca do końca idą najpierw na atrapach danych. Konta testowe żyją wyłącznie w domenie testowej aplikacji, więc próbna wiadomość nie ma jak trafić do prawdziwego klienta partnera.

Jest jeszcze jeden podział, który zaskakuje właścicieli firm przy uruchomieniu. Część rzeczy zrobi automat, część wykonawca, a konto operatora płatności zakładasz Ty osobiście — bo to Ty przechodzisz weryfikację tożsamości i to Ty jesteś sprzedawcą wobec swoich partnerów.

Jak wygląda praca zespołu od środka, gdy część kodu piszą agenci AI, opisaliśmy w tekście o rolach, bramkach i tym, co zostaje przy człowieku. Odpowiedzialność za decyzje w każdym z tych wariantów zostaje po stronie ludzi — Twojej i zespołu.

Czego ten podział nie rozstrzyga

Podział ról nie mówi, ile budowa kosztuje ani ile kosztuje utrzymanie aplikacji, z której korzysta kilkadziesiąt firm. Rachunki prowadzimy osobno: ile kosztuje aplikacja przez 3 lata oraz ile kosztuje miesięcznie utrzymanie przy 50 płacących firmach.

Nie odpowiada też na trzy pytania obok: dlaczego wiedza o branży jest składnikiem aplikacji, jak spisać własny proces i kiedy branża zaczyna płacić. Każde z nich ma własny tekst: znasz branżę od środka, jak spisać swój proces, kiedy branża zaczyna płacić.