Wybór wykonawcy oprogramowania to nie zakup produktu z półki. Kupujesz obietnicę pracy, która potrwa miesiącami, a jej efekt będzie działał w Twojej firmie latami. Dlatego pytanie, jak sprawdzić wykonawcę oprogramowania przed podpisaniem umowy, nie kończy się na porównaniu trzech PDF-ów z wyceną. Chodzi o coś innego: czy po drugiej stronie stoi zespół, który rozumie Twój problem biznesowy, zna ograniczenia technologii i potrafi powiedzieć, czego zrobić się nie da. W Web Systems od 2006 roku zajmujemy się tworzeniem oprogramowania na zamówienie: aplikacjami webowymi i mobilnymi, systemami B2B, integracjami API oraz rozwiązaniami AI. Widzieliśmy więc i projekty prowadzone wzorowo, i takie przejmowane po kimś w połowie drogi. Poniżej to, co realnie odsiewa dobrych wykonawców od sprawnych sprzedawców.
Spis treści
Czego naprawdę szukasz, zanim zaczniesz sprawdzać oferty
Weryfikacja zaczyna się od Ciebie, nie od wykonawcy. Zanim ocenisz czyjekolwiek kompetencje, musisz nazwać, co zamawiasz. MVP do walidacji pomysłu rynkowego, wewnętrzny system B2B, który ma pracować przez najbliższą dekadę, modernizacja aplikacji działającej od ośmiu lat – trzy zupełnie różne przedsięwzięcia. Inne podejście, inne tempo, inni ludzie.
Prototyp premiuje szybkość i gotowość do wyrzucenia połowy kodu po pierwszych testach z użytkownikami. System integrujący się z ERP premiuje ostrożność, znajomość struktur danych i cierpliwość w rozmowach z dostawcą tamtego systemu. Zespół świetny w pierwszym scenariuszu bywa przeciętny w drugim. I odwrotnie. Jeżeli tego rozróżnienia nie zrobisz, poprosisz wszystkich o „aplikację” i dostaniesz oferty, których po prostu nie da się porównać merytorycznie.
No i wtedy pojawia się typowa pułapka. Skoro dokumenty wyglądają podobnie, decyzja zapada po kwocie. Tyle że różnica w cenie zwykle nie bierze się z chciwości drugiej strony, tylko z odmiennego rozumienia zakresu. Jeden wykonawca policzył formularz. Drugi ten sam formularz plus walidację danych z zewnętrznego rejestru, obsługę błędów i panel administracyjny do poprawiania pomyłek.
Sygnał ostrzegawczy: wykonawca podaje konkretną liczbę, zanim zapyta o wolumen danych, liczbę użytkowników, wymagane integracje i to, co dzieje się z aplikacją w szczycie sezonu. Wycena bez pytań to wycena czegoś innego niż Twój projekt.
Tip: spisz na jednej stronie trzy rzeczy – problem biznesowy do rozwiązania, procesy, które aplikacja ma obsłużyć, oraz systemy, z którymi musi rozmawiać. Ta kartka zrobi więcej dla jakości ofert niż dwudziestostronicowa specyfikacja pisana bez znajomości technologii. Wyślij ją wszystkim zapytanym firmom i patrz, kto dopyta, a kto od razu wyśle cennik.
Doświadczenie, którego nie widać w portfolio
Portfolio pokazuje efekt wizualny, nie trudność techniczną. Estetyczny sklep bywa standardowym wdrożeniem gotowego silnika, a nieciekawy graficznie panel logistyczny – najtrudniejszym projektem w historii firmy, bo synchronizuje stany magazynowe między czterema systemami w czasie rzeczywistym. Zrzuty ekranu tego nie oddają.
Zamiast galerii poproś o opis wyzwań. Pytanie brzmi: co było najtrudniejsze w tym projekcie i jak zostało rozwiązane. Odpowiedź „wszystko poszło gładko” jest podejrzana. Projekty informatyczne nie idą gładko, idą co najwyżej sprawnie zarządzone. Wykonawca, który potrafi opowiedzieć o błędnym założeniu architektonicznym z początku prac i o tym, jak je skorygował, mówi Ci więcej niż dwadzieścia logotypów na stronie.
Osobno pytaj o projekty utrzymywane latami. Oddanie systemu i zniknięcie to nie to samo co siedem lat opieki nad rozwijającą się aplikacją, w trakcie których zmieniły się wersje frameworka, wymagania prawne i API partnerów. Długie relacje z klientami trudniej podrobić niż jednorazowe realizacje.
- Ciągłość zespołu – czy ludzie, którzy budowali projekt sprzed trzech lat, nadal pracują w firmie, czy została po nich tylko nazwa w portfolio.
- Staż firmy – podmiot działający kilkanaście lat przeszedł już kilka zmian technologicznych i przynajmniej jedno spowolnienie gospodarcze.
- Sposób opowiadania o porażkach – konkretna historia naprawionego błędu waży więcej niż deklaracja bezawaryjności.
Referencje weryfikuj rozsądnie. Rozmowa z klientem tydzień po odbiorze przynosi entuzjazm. Rozmowa rok później – prawdę o kosztach utrzymania, czasie reakcji na zgłoszenia i tym, czy ktokolwiek odbiera telefon, gdy projekt przestał być nowy. Pytaj o ten drugi moment.
Pytania techniczne, które odsiewają wykonawców
Nie musisz być programistą, żeby zadać pytania odsiewające. Wystarczy, że posłuchasz, czy w odpowiedzi jest uzasadnienie, czy same nazwy technologii. Poproś o opis proponowanej architektury i o wyjaśnienie, dlaczego akurat taka. Monolit bywa właściwym wyborem dla systemu obsługiwanego przez trzydziestu użytkowników, a rozdrobnienie go na mikrousługi potrafi wygenerować koszty operacyjne bez żadnej korzyści biznesowej.
Drugi obszar to bezpieczeństwo i dane osobowe. Zapytaj, jak działa uwierzytelnianie, gdzie przechowywane są hasła i tokeny, kto ma dostęp do bazy produkcyjnej oraz jak wygląda podział uprawnień w aplikacji. Jeśli system dotyka danych osobowych, powinny paść słowa o szyfrowaniu, retencji, logach dostępu i minimalizacji zbieranych informacji.
Trzeci obszar to integracje. Czyli miejsce, w którym ginie najwięcej budżetów. Samo wywołanie API jest proste. Schody zaczynają się przy limitach zapytań, chwilowej niedostępności partnera, powtórzonych zdarzeniach i danych, które przyszły niekompletne.
- Co się dzieje, gdy zewnętrzne API odpowie błędem albo nie odpowie wcale – czy jest kolejka, ponowienie, limit prób.
- Jak rozpoznajecie duplikaty zdarzeń, żeby jedna transakcja nie zaksięgowała się dwa razy.
- Gdzie trafiają rekordy odrzucone przez walidację i kto je ogląda.
- Jak zachowa się system, gdy wolumen danych wzrośnie kilkukrotnie – co wtedy stanie się wąskim gardłem.
Zapytaj też o higienę pracy: testy automatyczne, CI/CD, oddzielne środowisko testowe, logowanie zdarzeń i monitoring. Wykonawca wdrażający zmiany prosto na produkcję oszczędza teraz i wystawia Ci rachunek później. Sprawdzone wielokrotnie. Przy wdrożeniach opartych na sztucznej inteligencji dopytaj o koszt tokenów przy realnym ruchu, jakość i przygotowanie danych wejściowych oraz sposób kontroli wyników – model generujący nieprzewidywalne odpowiedzi w procesie obsługi klienta potrzebuje ram, nie samego promptu.
Wycena, harmonogram i model rozliczenia
Fixed price kusi przewidywalnością, ale działa tylko przy zakresie opisanym na tyle dokładnie, że obie strony rozumieją go tak samo. Im dokładniejszy opis, tym więcej pracy analitycznej przed startem. A ta praca też kosztuje. Wykonawca, który zgadza się na sztywną cenę przy mglistych wymaganiach, albo zabezpieczył się grubym buforem, albo planuje aneksy przy każdej zmianie.
Time and material daje elastyczność i uczciwie odzwierciedla nakład. Wymaga jednak zaufania oraz raportowania, które da się zweryfikować. Sensownym kompromisem bywa rozdzielenie projektu: płatna analiza i projekt techniczny w pierwszym etapie, a dopiero na ich podstawie wiążąca wycena realizacji. Wydajesz wtedy niewielką część budżetu, żeby dowiedzieć się, ile naprawdę kosztuje reszta, i możesz odejść z dokumentacją do innego zespołu.
Bardzo niska oferta rzadko oznacza wyjątkową efektywność. Częściej oznacza wąsko zrozumiany zakres, pominięte testy, brak migracji danych albo założenie, że treści, grafiki i konfigurację infrastruktury zapewnisz sam. Zsumuj to później i porównaj z ofertą, która wydawała się droga.
Estymacja bez podziału na etapy jest niesprawdzalna. Jedna kwota za całość nie pozwala ocenić, czy ktoś w ogóle pomyślał o panelu administracyjnym albo o imporcie starych danych. Proś o rozbicie na moduły i funkcje, z osobno wskazanym czasem analizy, testów, wdrożenia i przekazania projektu.
Ustal też, co dzieje się przy zmianie zakresu w trakcie prac. Bo zmiana nastąpi. Potrzebna jest prosta ścieżka: zgłoszenie, wycena zmiany, akceptacja, realizacja. Bez niej każda modyfikacja staje się negocjacją od zera.
Tip: porównuj oferty po założeniach, nie po kwocie końcowej. Wypisz w tabeli, co każdy wykonawca uznał za wliczone, a co pominął milczeniem. Różnice w tej tabeli wyjaśnią różnice w cenie lepiej niż jakakolwiek rozmowa handlowa.
Kod, dane i licencje – kto jest właścicielem po zakończeniu projektu
To najczęściej lekceważona część umowy. I jednocześnie ta, która potrafi zablokować firmę na lata. Zapłata za wykonanie oprogramowania nie oznacza automatycznie nabycia praw do niego. Przeniesienie autorskich praw majątkowych musi być zapisane wprost, z wymienionymi polami eksploatacji, i obejmować także prawo do modyfikacji oraz zlecania zmian innym podmiotom. Bez tego ostatniego punktu formalnie posiadasz kod, którego nie możesz swobodnie rozwijać.
Równie ważny jest dostęp do repozytorium od pierwszego dnia pracy, nie po odbiorze końcowym. Bieżący wgląd w kod to nie brak zaufania, tylko elementarne zabezpieczenie ciągłości. Jeśli współpraca skończy się w połowie projektu, masz wszystko, co powstało do tej pory, wraz z historią zmian.
Infrastruktura powinna należeć do Ciebie. Domena zarejestrowana na Twoją firmę, konta chmurowe założone na Twój adres, klucze API do usług zewnętrznych wystawione na Twoje konta, a wykonawca dopisany jako użytkownik z odpowiednimi uprawnieniami. Odwrotna konfiguracja, gdzie wszystko wisi na koncie agencji, zamienia zwykłą zmianę dostawcy w negocjacje.
- Licencje komponentów – poproś o listę bibliotek zewnętrznych i ich licencji, zwłaszcza przy oprogramowaniu, które zamierzasz sprzedawać lub udostępniać klientom.
- Eksport danych – musi istnieć sposób na wyjęcie kompletu danych w czytelnym formacie, bez pisania dodatkowego narzędzia.
- Dokumentacja przekazania – opis architektury, instrukcja uruchomienia środowiska i lista zależności, żeby inny zespół mógł przejąć projekt bez archeologii w kodzie.
Sprawdź też, czy w projekcie nie ma zamkniętych komponentów autorskich wykonawcy, licencjonowanych tylko na czas współpracy. To dopuszczalne, ale musisz o tym wiedzieć przed podpisaniem, a nie przy próbie migracji.
Zapisy w umowie, które ratują projekt
Umowa nie jest dokumentem na wypadek konfliktu. To zapis tego, jak obie strony rozumieją współpracę, i dlatego warto poświęcić jej czas przed startem, gdy relacja jest jeszcze dobra. Na pierwszym miejscu: definicja odbioru. „Gotowe” musi mieć konkretne znaczenie – zestaw scenariuszy testowych, które przechodzą, uruchomienie na wskazanym środowisku, przekazana dokumentacja, wskazana osoba potwierdzająca odbiór i termin na zgłoszenie uwag.
Gwarancja opisana hasłowo nie działa. Potrzebujesz podziału błędów na kategorie i przypisanych do nich czasów reakcji. Awaria blokująca sprzedaż to inna sprawa niż przesunięty przycisk, a umowa powinna to rozróżniać. Ustal również, w jakich godzinach obowiązują te czasy i co dzieje się poza nimi.
Opisz zasady komunikacji. Kto po stronie wykonawcy odpowiada za projekt, kto zastępuje tę osobę podczas urlopu, jak często dostajesz raport postępu i w jakim kanale zgłaszasz uwagi. Projekty rozsypują się częściej od chaosu informacyjnego niż od trudności technicznych. Jedna osoba decyzyjna po każdej stronie oszczędza tygodnie.
Jeśli aplikacja przetwarza dane osobowe, potrzebna jest umowa powierzenia przetwarzania z określeniem zakresu danych, celu, podwykonawców, lokalizacji serwerów i zasad usunięcia danych po zakończeniu współpracy. Bywa traktowana jako formalność do podpisania w biegu. A to realne zabezpieczenie w razie incydentu.
Na koniec warunki wyjścia. Zapisz, co dzieje się przy rozwiązaniu umowy: przekazanie kodu, danych, dostępów, dokumentacji i konfiguracji w określonym terminie, rozliczenie prac wykonanych. Dobrze opisane rozstanie zwykle nigdy nie jest potrzebne, ale jego brak zamienia zwykłą zmianę dostawcy w spór ciągnący się miesiącami.
Utrzymanie po wdrożeniu – najczęściej pomijany element wyboru
Aplikacja zaczyna kosztować naprawdę dopiero po starcie. Wtedy pojawiają się aktualizacje bibliotek, łatki bezpieczeństwa, zmiany w API partnerów wymuszające przeróbki integracji, rosnące rachunki za infrastrukturę przy większym ruchu i drobne poprawki zgłaszane przez użytkowników, którzy wreszcie zaczęli z systemu korzystać. Wykonawca, który w rozmowie handlowej milczy o tym etapie, albo nigdy nie utrzymywał niczego przez dłuższy czas, albo świadomie omija niewygodny temat.
Monitoring, kopie zapasowe i procedura przywracania powinny być ustalone przed uruchomieniem, nie po pierwszej awarii. Sama kopia zapasowa nic nie znaczy, jeśli nikt nigdy nie sprawdził odtworzenia z niej działającego systemu. Zapytaj wprost, jak wygląda test odtworzenia i ile trwa powrót do pracy po poważnym incydencie.
Ustal, kto reaguje na awarię w piątek wieczorem i na jakich warunkach. Odpowiedź „jakoś się dogadamy” oznacza brak procedury. Musisz wiedzieć, czy istnieje dyżur, jak się go uruchamia, ile kosztuje i czego dotyczy.
Sprawdź też zdolność do powrotu. Za pół roku będziesz chciał dołożyć moduł raportowania albo podpiąć nowy system płatności. Firma zajęta wyłącznie nowymi wdrożeniami, bez procesu obsługi dawnych klientów, może nie mieć wtedy wolnych ludzi.
Typowy błąd: wybór najtańszego wykonawcy do budowy z założeniem, że utrzymanie przejmie ktoś inny. Przejęcie cudzego kodu bez dokumentacji, testów i opisu decyzji projektowych kosztuje więcej niż początkowa oszczędność, a nowy zespół najpierw musi zrozumieć, czego dotknąć nie wolno. Traktuj budowę i utrzymanie jako jedną decyzję.
Podsumowanie
Sprawdzenie wykonawcy oprogramowania przed podpisaniem umowy polega na ocenie sposobu myślenia o problemie, nie na porównaniu cenników i galerii realizacji. Ładne portfolio i atrakcyjna kwota nie powiedzą Ci, jak zachowa się zespół, gdy integracja zacznie zwracać błędy, wolumen danych urośnie ponad założenia albo zmienią się wymagania w połowie prac. Powiedzą to natomiast odpowiedzi na pytania o architekturę, bezpieczeństwo, obsługę wyjątków i utrzymanie.
Największe ryzyko nie siedzi w warstwie graficznej. Siedzi w integracjach, jakości danych, prawach do kodu i tym, co dzieje się po uruchomieniu. Zabezpiecz te cztery obszary w rozmowie i w umowie, a resztę da się poprawić w trakcie. Dobry partner sam z siebie mówi o ograniczeniach, kompromisach i kosztach utrzymania jeszcze na etapie ofertowania, bo woli trudną rozmowę teraz niż konflikt za rok.
Planujesz MVP, aplikację webową lub mobilną, integrację API, automatyzację procesów, rozwiązanie oparte na AI albo modernizację systemu, który już nie nadąża za firmą? Napisz do nas. Chętnie przejrzymy oferty, które masz na biurku, i podpowiemy, o co dopytać, zanim cokolwiek podpiszesz.
