Jak wybrać wykonawcę aplikacji webowej dla firmy

Ostatnia aktualizacja: 2026-10-26

Definicja: Aplikacja webowa to oprogramowanie działające w przeglądarce, które zwykle obsługuje dane, role użytkowników, procesy lub integracje. Dlatego wybór i odbiór jej wykonawcy wymagają oceny szerszej niż sam wygląd strony.

Zacznij od zakresu, który da się porównać

Najpierw przygotuj jeden opis problemu i oczekiwanego rezultatu, a dopiero potem poproś o wyceny. Oferty można sensownie porównać, gdy dotyczą tego samego zakresu funkcji, integracji, materiałów, terminów i odpowiedzialności.^[1][4]

Zakres nie musi od razu przyjmować postaci rozbudowanej dokumentacji technicznej. Powinien jednak wyjaśniać, kto będzie korzystał z systemu, jaki proces ma obsługiwać, jakie dane będą potrzebne i z czym aplikacja ma się łączyć. Przy zamawianiu aplikacje internetowe należy traktować jako rozwiązania procesowe, a nie wyłącznie zestaw ekranów.

Co powinien zawierać krótki brief

1. Opisz problem biznesowy. Wskaż proces, który ma być obsługiwany, oraz rezultat oczekiwany po uruchomieniu aplikacji.
2. Określ użytkowników. Zapisz, jakie role wystąpią w systemie i które czynności mają wykonywać.
3. Wymień funkcje startowe. Oddziel działania niezbędne do uruchomienia procesu od wygodnych dodatków.
4. Wskaż integracje i dane. Zaznacz, z jakimi systemami aplikacja ma współpracować i jakie informacje będzie obsługiwać.
5. Dodaj ograniczenia. Uwzględnij termin, dostępne materiały oraz istotne warunki organizacyjne.
6. Wyślij ten sam dokument wszystkim kandydatom. Różnice w ofertach będą wtedy wynikały z podejścia wykonawców, a nie z odmiennych założeń.

Jak oddzielić zakres MVP od kolejnych etapów

Pierwsza wersja powinna rozdzielać funkcje potrzebne do uruchomienia procesu od tych, które można odłożyć.^[8] Tak rozumiane MVP jest minimalnym zakresem użytkowym, a nie zgodą na pominięcie ustaleń dotyczących danych, integracji czy bezpieczeństwa.

Przy każdej funkcji można zadać pytanie: czy bez niej da się przeprowadzić podstawowy proces, który aplikacja ma obsługiwać? Odpowiedź pomaga ustalić kolejność prac i ogranicza sytuację, w której kandydaci wyceniają różne wersje produktu.

Jak zweryfikować kompetencje wykonawcy

Sprawdzaj nie liczbę projektów w portfolio, lecz ich podobieństwo do własnego problemu. Użytecznym dowodem są działające wdrożenia, o ile można ustalić, za jakie elementy odpowiadał wykonawca.^[2] Same grafiki i zrzuty ekranu nie potwierdzają jakości kodu, bezpieczeństwa ani terminowości.

O co pytać przy portfolio i referencjach

• Czy można zobaczyć działającą realizację o podobnym procesie, typie integracji albo zakresie odpowiedzialności?
• Które części rozwiązania wykonała prezentowana firma, a które pochodziły od innych podmiotów?
• Kto zostanie przypisany do projektu i jakie zadania będą należały do poszczególnych osób?
• Czy wykonawca odpowiadał również za utrzymanie prezentowanego systemu?
• Czy dostępny jest kontakt referencyjny, jeśli właściciel wdrożenia może go udostępnić?

Podobieństwo branży nie musi być najważniejszym kryterium. Bardziej przydatne może być doświadczenie z analogicznym procesem, rolami użytkowników, integracjami lub późniejszym utrzymaniem.

Freelancer, agencja czy software house: jakie kryteria mają znaczenie

Rozmiar firmy wykonawczej nie stanowi samodzielnego kryterium jakości. Znaczenie mają dopasowane doświadczenie, sposób pracy, odpowiedzialność i możliwość dalszego utrzymania systemu. Nie ma jednak niezależnej podstawy do uznania jednego z tych modeli za najlepszy w każdym projekcie.

Zakres odpowiedzialności

Ustal, kto odpowiada za analizę, realizację, odbiór poprawek i obsługę po uruchomieniu.

Ciągłość prac

Zapytaj, jak zostanie zapewniona obsługa projektu, gdy osoba realizująca konkretne zadanie nie będzie dostępna.

Komunikacja

Określ osoby kontaktowe, sposób podejmowania decyzji i dokumentowania ustaleń.

Utrzymanie

Sprawdź, czy wykonawca oferuje dalszą obsługę i na jakich zasadach może zostać ona przejęta przez inny podmiot.

Porównaj oferty według zakresu, odbioru i kosztów po wdrożeniu

Nie zestawiaj wyłącznie kwot końcowych. Każdą ofertę należy ocenić według zakresu, założeń i wyłączeń, etapów, sposobu odbioru, ceny wdrożenia oraz kosztów występujących po uruchomieniu.

Koszt wykonania nie jest pełnym kosztem posiadania aplikacji. Osobno mogą wystąpić koszty hostingu, usług zewnętrznych, kopii zapasowych, wsparcia, poprawek i dalszego rozwoju.^[7] Ich zakres zależy od architektury, skali użycia i modelu wsparcia, dlatego bez założeń projektowych nie należy przyjmować uniwersalnej kwoty.

Kryteria odbioru powinny opisywać sprawdzalny rezultat. Zamiast ogólnego warunku „aplikacja działa” lepiej przypisać akceptację do uzgodnionych funkcji, ról, integracji, dokumentacji i przekazania. Ułatwia to również odróżnienie usuwania wad od zamówienia nowych funkcji.

Co ustalić w umowie przed rozpoczęciem prac

Umowa powinna przełożyć ofertę na mierzalny zakres, sposób odbioru, odpowiedzialność za poprawki, warunki utrzymania, dostęp do kodu oraz zasady zakończenia współpracy.^[4] Konkretne postanowienia trzeba dopasować do rodzaju umowy, a przy istotnym projekcie poddać ocenie prawnej.

Prawa do kodu, licencje i pola eksploatacji

Jeżeli umowa ma przenosić autorskie prawa majątkowe, na gruncie polskiego prawa wymaga to formy pisemnej pod rygorem nieważności, a pola eksploatacji powinny zostać wyraźnie określone.^[5] Nie oznacza to, że identyczne zasady obejmą każdy składnik systemu. Licencje i elementy osób trzecich mogą podlegać odmiennym warunkom.

W praktyce trzeba więc rozdzielić elementy wykonane na zamówienie od komponentów używanych na podstawie licencji. Samo sformułowanie o „własności kodu” może nie wyjaśniać, w jakim zakresie firma będzie mogła korzystać z aplikacji, rozwijać ją i przekazać jej obsługę.

Dane osobowe i dostęp wykonawcy

Jeżeli wykonawca przetwarza dane osobowe w imieniu administratora, współpraca powinna uwzględniać wymagania art. 28 RODO, w tym odpowiednią umowę lub inny instrument prawny.^[6] Obowiązek zależy od rzeczywistego modelu dostępu i przetwarzania danych; nie każda współpraca technologiczna oznacza automatycznie powierzenie przetwarzania.

Przed zawarciem umowy należy zatem ustalić, do jakich danych wykonawca uzyska dostęp, jakie operacje będzie wykonywał i które osoby będą potrzebowały uprawnień. Pozwala to dopasować zasady współpracy do faktycznej roli wykonawcy.

Utrzymanie, poprawki i zakończenie współpracy

Umowa powinna rozróżniać obsługę błędów, bieżące utrzymanie i rozwój nowych funkcji. Każdy z tych obszarów może mieć inny sposób zgłaszania, odbioru i rozliczenia.

Trzeba też ustalić, co wydarzy się po zakończeniu współpracy: które dostępy i materiały zostaną przekazane, w jakiej postaci będzie można wyeksportować dane oraz kto odpowiada za zamknięcie lub przeniesienie używanych usług.

Zadbaj o dostęp do kodu, infrastruktury i dokumentacji

Przed rozpoczęciem prac ustal, gdzie będą znajdować się repozytorium, konta infrastruktury, dokumentacja, kopie zapasowe i dane. Określ również, kto będzie właścicielem kont oraz jak nastąpi przekazanie systemu.

Dostęp do samego kodu może nie wystarczyć do przejęcia utrzymania bez konfiguracji, dokumentacji i kontroli nad usługami zewnętrznymi. Zakres uprawnień powinien jednocześnie odpowiadać rolom i zasadom ochrony danych.

• Repozytorium: ustal miejsce przechowywania kodu i zasady dostępu do niego.
• Konta administracyjne: określ właścicieli hostingu i pozostałych usług używanych przez aplikację.
• Dokumentacja: wskaż materiały potrzebne do utrzymania, konfiguracji i przekazania rozwiązania.
• Kopie zapasowe: zapisz, kto odpowiada za ich wykonywanie oraz za procedurę odtworzenia.
• Eksport danych: ustal sposób otrzymania danych po zakończeniu współpracy.
• Przekazanie: opisz listę dostępów, materiałów i czynności kończących obsługę przez dotychczasowego wykonawcę.

Takie ustalenia ograniczają zależność od jednego dostawcy i pozwalają przygotować przejęcie obsługi bez utożsamiania samego pliku z kodem z pełnym, gotowym do utrzymania środowiskiem.

Odbierz aplikację na podstawie kryteriów, nie deklaracji

Przed końcowym rozliczeniem zweryfikuj uzgodnione funkcje, role użytkowników, integracje, dokumentację i przekazanie. Odbiór powinien wynikać z kryteriów ustalonych przed realizacją, a nie wyłącznie z ogólnego wrażenia po prezentacji produktu.

Lista kontroli przed końcowym rozliczeniem

Portfolio, cena i wielkość firmy nie są samodzielnym dowodem jakości kodu, bezpieczeństwa, terminowości ani kosztów utrzymania. Również model współpracy nie przesądza o wyniku projektu. Decyzję należy oprzeć na dopasowanym doświadczeniu, jednoznacznym zakresie, odpowiedzialności oraz możliwości dalszego działania i utrzymania systemu.

+Artykuł Sponsorowany+