Jak wybrać wykonawcę aplikacji webowej dla firmy?

Dobrego wykonawcę aplikacji webowej warto oceniać nie tylko po cenie i portfolio. Powinien zrozumieć problem firmy, wyraźnie określić pierwszy etap, nazwać założenia i ryzyka oraz zapisać, po czym obie strony poznają, że praca została wykonana. Przed rozpoczęciem projektu trzeba też ustalić własność kodu i danych, dostęp do repozytorium i kont, sposób testowania, odbioru, wdrożenia, przekazania oraz dalszego utrzymania.

Oferty można uczciwie porównać dopiero wtedy, gdy dotyczą podobnego zakresu i rezultatu. Niższa cena może oznaczać mniejszy zakres, brak migracji danych, testów albo opieki po uruchomieniu. Wyższa cena również nie jest dowodem jakości, jeżeli oferta nie wyjaśnia, za co firma zapłaci.

Małe i jednoznaczne zadanie nie zawsze wymaga rozbudowanej analizy. Jeżeli jednak aplikacja ma wiele ról, integracji, wyjątków i ważnych danych, szybka wycena bez dodatkowych pytań powinna skłonić do doprecyzowania założeń.

Najpierw sprawdź, czy wykonawca rozumie problem firmy

Pierwsza rozmowa nie powinna zaczynać się wyłącznie od wyboru technologii i listy ekranów. Najpierw trzeba ustalić, kto korzysta z obecnego procesu, gdzie powstają opóźnienia, jakie dane są potrzebne i co ma działać inaczej po wdrożeniu.

Dobry wykonawca pyta między innymi:

• kto wykonuje poszczególne czynności i kto podejmuje decyzje;
• w jakich programach, arkuszach lub plikach znajdują się dane;
• gdzie praca jest powtarzana albo wykonywana ręcznie;
• jakie wyjątki pojawiają się w rzeczywistym procesie;
• co musi działać w pierwszym etapie, a co może poczekać;
• po czym użytkownicy i osoba zamawiająca ocenią rezultat.

Ważnym sygnałem jest też gotowość do wskazania prostszego rozwiązania. Czasem zamiast nowej aplikacji wystarczy konfiguracja używanego systemu, dodatkowy moduł albo integracja. Jeżeli wykonawca proponuje budowę od zera bez sprawdzenia takich możliwości, warto zapytać, dlaczego odrzucił prostsze warianty.

Do pierwszej rozmowy nie potrzebujesz dokumentacji technicznej. Przydatny jest natomiast krótki opis problemu, obecnego sposobu pracy i oczekiwanego wyniku. Pomaga go przygotować artykuł Jak opisać potrzebny system bez dokumentacji technicznej?.

Sprawdź, jak wykonawca radzi sobie z niewiadomymi

W nowym projekcie część informacji zwykle jest niepełna. Firma może znać swój problem, ale nie wiedzieć jeszcze, jak powinien wyglądać docelowy obieg danych, podział uprawnień albo integracja z używanym programem. Uczciwa oferta powinna oddzielać potwierdzone wymagania od założeń.

Zapytaj, czego wykonawca potrzebuje przed podaniem ceny i terminu. Zwróć uwagę, czy potrafi wskazać:

• decyzje, które muszą zostać podjęte przed rozpoczęciem;
• dane i dostępy wymagające sprawdzenia;
• założenia wpływające na wycenę;
• elementy wyłączone z pierwszego etapu;
• ryzyka zależne od zewnętrznych systemów lub dostawców;
• sytuacje, w których zakres trzeba ponownie uzgodnić.

Przy prostym zadaniu mogą wystarczyć materiały, krótka rozmowa i jasny warunek odbioru. Przy większej liczbie procesów, ról, danych i integracji rozsądny może być osobny etap analizy biznesowej i ustalenia MVP. Taka analiza nie powinna być obowiązkowym dodatkiem do każdego zlecenia. Ma zmniejszyć niepewność tam, gdzie bez niej obie strony wyceniałyby inny projekt.

Porównuj ten sam pierwszy etap, a nie same kwoty

Dwie oferty mogą używać podobnych nazw, a obejmować zupełnie inny zakres. Jedna może zawierać migrację danych, testy i wdrożenie, a druga wyłącznie przygotowanie aplikacji na danych przykładowych. Przed porównaniem ceny sprowadź obie propozycje do wspólnej listy.

Jeżeli chcesz dokładniej zrozumieć, skąd biorą się różnice między ofertami, przeczytaj artykuł Ile kosztuje aplikacja webowa dla firmy?. Sama stawka godzinowa nie odpowiada na pytanie, ile pracy potrzeba, co zostanie sprawdzone i co klient otrzyma na końcu.

Ustal własność kodu, danych i kont przed podpisaniem umowy

Własność i dostęp często są omawiane dopiero przy zakończeniu współpracy. Wtedy ich uporządkowanie jest najtrudniejsze. Przed startem ustal na piśmie:

• kto i na jakich warunkach otrzymuje prawa do kodu przygotowanego w projekcie;
• gdzie znajduje się repozytorium i kto ma do niego dostęp;
• kto jest właścicielem domeny, hostingu i kont chmurowych;
• na czyim koncie są rozliczane zewnętrzne API, poczta, SMS-y i inne usługi;
• jak klient otrzyma eksport danych oraz materiały potrzebne do dalszej pracy;
• które biblioteki, szablony lub usługi mają osobne licencje;
• co dzieje się z dostępami wykonawcy po zakończeniu współpracy.

Nie należy zakładać, że przeniesienie praw, kodu, licencji i wszystkich kont nastąpi automatycznie po opłaceniu faktury. Zakres trzeba zapisać w konkretnej umowie.

W Domin Software przyjmujemy model, w którym klient pozostaje właścicielem domeny, hostingu i rozliczanych kont, a my otrzymujemy uzgodniony dostęp potrzebny do pracy. Szczegóły odpowiedzialności, kodu i materiałów zawsze wymagają jednak zapisania dla danego projektu.

Zapytaj, jak będą sprawdzane najważniejsze funkcje

Zdanie „aplikacja będzie przetestowana” jest zbyt ogólne. Innego sprawdzenia wymaga formularz kontaktowy, innego import faktur, a jeszcze innego system z rolami, płatnościami i dostępem do danych klientów.

Poproś wykonawcę o prostą odpowiedź na kilka pytań:

1. Które procesy są najważniejsze i jak zostaną sprawdzone?
2. Czy odbiór odbędzie się na środowisku testowym lub w inny bezpieczny sposób?
3. Jak zostaną sprawdzone role, uprawnienia i ważne operacje?
4. Kto wykona kopię przed zmianą i czy sposób odtworzenia jest znany?
5. Jak wygląda wdrożenie oraz kontrola bezpośrednio po uruchomieniu?
6. Co stanie się, jeżeli wdrożenie nie spełni kryteriów odbioru?
7. Jak zgłasza się błędy i kto ocenia ich pilność?

Bezpieczeństwo również powinno być opisane przez konkretne wymagania i sposób ich sprawdzenia, a nie przez ogólną deklarację. OWASP ASVS przedstawia wymagania, które mogą służyć do projektowania i weryfikowania zabezpieczeń aplikacji webowych. NIST SSDF opisuje praktyki bezpiecznego wytwarzania, które można włączyć do używanego sposobu pracy. Nie oznacza to, że każdy mały projekt musi wdrażać cały standard. Zakres kontroli powinien odpowiadać ryzyku, rodzajowi danych i skutkom błędu.

Oceń komunikację na realnym przykładzie

Szybka odpowiedź na zapytanie sprzedażowe nie wystarcza do oceny późniejszej współpracy. Poproś wykonawcę, aby wyjaśnił jeden ważny fragment oferty prostym językiem. Może to być sposób odbioru, ryzyko integracji albo różnica między pierwszym etapem a dalszym rozwojem.

Zwróć uwagę, czy wykonawca:

• podsumowuje ustalenia i wskazuje brakujące decyzje;
• wyjaśnia konsekwencje wyboru zamiast wymieniać technologie;
• potrafi powiedzieć, czego jeszcze nie wie;
• odróżnia błąd od zmiany zakresu;
• ustala osoby decyzyjne i sposób zatwierdzania zmian;
• określa, jak często będzie informował o postępie.

Dobra komunikacja nie polega na unikaniu trudnych informacji. Wartościowa odpowiedź może brzmieć: „Tego nie da się jeszcze wiarygodnie wycenić, dopóki nie sprawdzimy formatu danych i dokumentacji API”. Taka informacja jest bardziej użyteczna niż precyzyjna liczba oparta na domysłach.

Portfolio ma pokazywać sposób pracy, a nie tylko wygląd

Zrzut ekranu potwierdza, że istniał jakiś interfejs. Nie mówi jeszcze, jaki problem rozwiązał wykonawca, za które elementy odpowiadał ani czy system nadal jest używany. W case study szukaj osobno opisanego problemu, zakresu pracy, ograniczeń oraz rezultatu, który można potwierdzić.

Podobny proces bywa ważniejszy niż identyczna branża. Firma tworząca system rezerwacji może mieć doświadczenie przydatne w projekcie z wieloma rolami, kalendarzem i rozliczeniami, nawet jeżeli nowy klient działa w innym sektorze.

W naszych realizacjach można zobaczyć różne rodzaje złożoności:

• 44Islands pokazuje system rozwijany etapami dla różnych ról i procesu rezerwacji;
• HUB.ITM.PL pokazuje historyczny projekt mapowania danych z różnych programów księgowych do formatu EDI++;
• HUB-2-API pokazuje historyczny przepływ produktów, ofert eBay.de, zamówień oraz API dla trzech klientów z Francji.

HUB.ITM.PL i HUB-2-API nie działają już produkcyjnie. Są przykładami wcześniejszej pracy z danymi, integracjami i procesami, a nie demonstracją aktualnie dostępnych usług zewnętrznych. Przy ocenie dowolnego portfolio warto zwracać uwagę na takie ograniczenia.

Ustal przekazanie i utrzymanie, zanim projekt się rozpocznie

Odbiór działającej aplikacji nie kończy wszystkich obowiązków. Trzeba ustalić, co klient otrzyma po zakończeniu etapu i kto będzie odpowiadał za rozwiązanie później.

Zakres przekazania może obejmować:

• dostęp do repozytorium i odpowiedniej wersji kodu;
• instrukcję uruchomienia oraz opis ważnych zależności;
• dane dostępowe przekazane bezpiecznym kanałem;
• listę usług zewnętrznych i terminów ich rozliczeń;
• kopię lub eksport danych w uzgodnionym zakresie;
• wyniki odbioru i listę znanych ograniczeń;
• informację o kopiach, monitoringu, aktualizacjach i sposobie zgłaszania błędów.

Opieka może być częścią projektu, osobną umową albo pracą zlecaną w razie potrzeby. Nie ma jednego modelu dobrego dla wszystkich firm. Ważne, aby pojęcia takie jak czas reakcji, godziny obsługi i zakres aktualizacji miały konkretne znaczenie. Jeżeli chcesz rozdzielić rozwój od późniejszej opieki, sprawdź ofertę utrzymania aplikacji i sklepów.

Czerwone flagi, które wymagają dodatkowych pytań

Pojedynczy sygnał nie musi od razu przekreślać wykonawcy. Powinien jednak prowadzić do konkretnego pytania. Zachowaj ostrożność, gdy:

• pełna cena i termin pojawiają się przed rozpoznaniem ról, danych, integracji i wyjątków;
• wybrana technologia jest przedstawiana jako gwarancja bezpieczeństwa lub skalowalności;
• oferta nie określa własności repozytorium, danych i kont;
• zakres nie ma kryteriów odbioru ani jawnych wyłączeń;
• nie wiadomo, jak rozwiązanie będzie testowane i wdrożone;
• portfolio nie wyjaśnia, co rzeczywiście wykonała dana firma;
• zasady zmian, poprawek, utrzymania i zakończenia współpracy są niejasne;
• wykonawca naciska na szybką umowę przed wyjaśnieniem podstawowych założeń.

Problemem nie jest sama różnica zdań ani potrzeba dodatkowej analizy. Większym ryzykiem jest sytuacja, w której ważne pytania pozostają bez odpowiedzi, a obie strony zakładają, że rozumieją zakres tak samo.

Co przygotować do pierwszej rozmowy z wykonawcą?

Nie musisz zaczynać od obszernej specyfikacji. Przygotuj materiały, które pokażą rzeczywisty problem:

1. jednozdaniowy opis sytuacji i oczekiwanego rezultatu;
2. obecny sposób pracy oraz osoby biorące udział w procesie;
3. najważniejsze dane, systemy i potrzebne integracje;
4. trzy priorytety pierwszego etapu;
5. ograniczenia terminu, budżetu lub istniejącej infrastruktury;
6. przykłady nietypowych przypadków i wyjątków;
7. osobę, która może podejmować decyzje;
8. materiały przykładowe bez haseł, kluczy i prawdziwych danych klientów.

Możesz skorzystać z bezpłatnego narzędzia Opis projektu. Prowadzi przez najważniejsze pytania i tworzy uporządkowane podsumowanie do dalszej rozmowy. Narzędzie nie wysyła projektu automatycznie i nie zastępuje analizy większego zakresu.

Najczęstsze pytania

Czy przed wyborem wykonawcy trzeba mieć gotową specyfikację techniczną?

Nie. Na początku wystarczy opis problemu, obecnego procesu, użytkowników, danych i oczekiwanego wyniku. Specyfikacja techniczna może powstać później, gdy rozwiązanie i zakres zostaną lepiej rozpoznane.

Czy lepiej wybrać freelancera, małą firmę czy software house?

Nie ma jednej odpowiedzi. Wybór zależy od rozmiaru projektu, ryzyka, potrzebnej dostępności, specjalizacji i sposobu komunikacji. Ważniejsze od samej nazwy modelu jest to, kto faktycznie wykona pracę, kto zastąpi tę osobę w razie niedostępności i jak zostanie przekazany kod oraz wiedza o systemie.

Jak porównać dwie wyceny aplikacji, jeśli mają różne zakresy?

Najpierw porównaj rezultat pierwszego etapu, funkcje, role, dane, integracje, testy, wdrożenie i elementy wyłączone. Dopiero potem oceniaj kwotę. Jeżeli zakresów nie da się sprowadzić do wspólnej listy, poproś wykonawców o doprecyzowanie ofert.

Kto powinien być właścicielem kodu, repozytorium i danych?

Warunki powinny być jawne i zapisane w umowie. Firma zamawiająca powinna co najmniej wiedzieć, gdzie znajduje się kod i dane, kto ma do nich dostęp, jakie licencje obowiązują oraz jak otrzyma potrzebne materiały po zakończeniu współpracy. Samo opłacenie etapu nie zastępuje tych ustaleń.

Czy płatna analiza przed wyceną jest zawsze potrzebna?

Nie. Proste zadanie z jasnym wynikiem można często wycenić na podstawie krótkiego opisu i materiałów. Osobna analiza ma sens, gdy trzeba rozpoznać wiele procesów, danych, ról, integracji i niewiadomych, które istotnie wpływają na zakres.

O co zapytać w sprawie testów i bezpieczeństwa?

Zapytaj, które procesy zostaną sprawdzone, w jakim środowisku odbędzie się odbiór, jak będą kontrolowane role i ważne operacje, kto wykona kopię oraz jak będzie wyglądało bezpieczne wdrożenie. Zakres testów powinien odpowiadać ryzyku projektu.

Co powinno zostać przekazane po zakończeniu projektu?

Zależy to od umowy, ale zwykle warto ustalić dostęp do kodu i repozytorium, instrukcję uruchomienia, informacje o zależnościach i usługach zewnętrznych, eksport danych, wyniki odbioru oraz listę znanych ograniczeń. Ważny jest też sposób przekazania dostępów i ich późniejszego odebrania wykonawcy.

Czy utrzymanie aplikacji musi być częścią tej samej umowy?

Nie. Utrzymanie może należeć do projektu, być osobną usługą albo zostać przekazane innemu wykonawcy. Trzeba jednak wcześniej ustalić, kto odpowiada za monitoring, kopie, aktualizacje, awarie i kontakt z dostawcami infrastruktury.

Przygotuj porównywalny punkt wyjścia

Najpierw opisz problem, pierwszy potrzebny rezultat i najważniejsze ograniczenia. Skorzystaj z narzędzia Opis projektu, aby przygotować jedno podsumowanie dla wszystkich porównywanych wykonawców. Dzięki temu każda rozmowa zacznie się od tych samych informacji.

Jeżeli szukasz wykonawcy dedykowanej aplikacji, zobacz usługi programistyczne Domin Software. Po zapoznaniu się z opisem możemy wskazać, czy wystarczy rozmowa i mały etap, czy najpierw potrzebna jest osobna analiza. Nie podajemy pełnej ceny i terminu bez poznania zakresu, danych, integracji oraz sposobu odbioru.

Źródła

• OWASP Application Security Verification Standard, OWASP, stabilna wersja 5.0.0 opublikowana 30.05.2025, dostęp sprawdzony 30.10.2026.
• NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1, National Institute of Standards and Technology, publikacja z lutego 2022, dostęp sprawdzony 30.10.2026.