Jak ocenić ofertę software house’u i nie przepłacić

Ofertę software house’u ocenisz rzetelnie, gdy sprawdzisz trzy rzeczy: czy zakres jest opisany na tyle dokładnie, że inna firma wyceniłaby to samo, czy koszt jest rozbity na moduły i role oraz czy umowa przenosi na Ciebie prawa do kodu. Najdrożej kosztuje zwykle oferta, która pomija testy, wdrożenie i utrzymanie.

Wycena aplikacji od software house’u to prognoza, a nie cennik. Różnice między ofertami na ten sam projekt bywają duże i rzadko wynikają z samych stawek. Poniżej znajdziesz listę elementów dobrej oferty, sygnały ostrzegawcze, pytania do wykonawcy i sposób porównania kilku propozycji.

Co powinna zawierać dobra oferta software house’u

Oferta, na podstawie której można podjąć decyzję, zawiera co najmniej:

• Zakres: lista funkcji z podziałem na moduły, role użytkowników, platformy (web, iOS, Android), integracje z innymi systemami, panel administracyjny.
• Założenia: co wykonawca przyjął, żeby wycenić projekt. Na przykład „płatności przez jednego operatora”, „jedna wersja językowa”, „projekt graficzny dostarcza klient”.
• Wyłączenia: czego wycena nie obejmuje. Brak tej sekcji oznacza, że spór o zakres jest kwestią czasu.
• Wycenę w podziale na moduły, najlepiej jako przedział (wariant optymistyczny i pesymistyczny) z liczbą godzin dla każdej roli.
• Skład zespołu: role, doświadczenie, wymiar zaangażowania, informacja, czy pracują pracownicy firmy, czy podwykonawcy.
• Harmonogram z kamieniami milowymi i zasadami odbioru każdego etapu.
• Jakość i infrastrukturę: testy manualne i automatyczne, środowisko testowe (staging), CI/CD, przegląd kodu, dokumentację techniczną.
• Wdrożenie: konfigurację serwerów lub chmury, publikację w sklepach z aplikacjami, migrację danych.
• Bezpieczeństwo i zgodność: podejście do ochrony danych, testy bezpieczeństwa, wymagania dostępności, jeśli dotyczą Twojej usługi.
• Utrzymanie i gwarancję: co dzieje się po uruchomieniu, w jakim czasie wykonawca reaguje na błędy i ile to kosztuje.

Przy aplikacjach dla konsumentów zwróć uwagę na dostępność. Od 28 czerwca 2025 roku obowiązuje polska ustawa wdrażająca Europejski Akt o Dostępności, która obejmuje m.in. usługi handlu elektronicznego. Nie stosuje się jej do usług świadczonych przez mikroprzedsiębiorców, ale jeśli Twoja firma nie jest mikroprzedsiębiorcą, wymagania muszą znaleźć się w zakresie.

Jeśli dopiero szacujesz budżet aplikacji mobilnej, zajrzyj do tekstu ile kosztuje aplikacja mobilna w 2026 roku, a przy wyborze technologii do porównania aplikacji natywnej i cross-platform.

Fixed price, time and materials czy model mieszany

Model rozliczenia decyduje o tym, kto ponosi ryzyko błędnej wyceny i jak obsługiwane są zmiany. Żaden nie jest z zasady tańszy.

Fixed price przy niejasnym zakresie to najgorsze połączenie. Wykonawca albo dolicza duży bufor, albo broni się interpretacją wymagań, a Ty płacisz za każdą zmianę zgłoszoną po starcie.

Czerwone flagi w wycenie aplikacji

• Zakres w jednym akapicie. „Aplikacja do rezerwacji z panelem administratora” może oznaczać bardzo różne projekty.
• Brak fazy discovery przy dużym projekcie. Wycena złożonego systemu po jednej rozmowie to zgadywanie, niezależnie od doświadczenia firmy.
• Brak osobnej pozycji na testy. Testowanie „w ramach programowania” zwykle oznacza, że testuje klient, na produkcji.
• Brak środowiska testowego. Bez stagingu każda zmiana trafia prosto do użytkowników.
• Cisza o utrzymaniu. Aktualizacje systemów mobilnych, bibliotek i zabezpieczeń są pewne, pytanie tylko, kto za nie zapłaci.
• Niejasne prawa do kodu i brak dostępu do repozytorium. Kod udostępniany dopiero „po zakończeniu i pełnej płatności” to ryzyko, że nigdy nie zobaczysz stanu prac.
• Uzależnienie od wykonawcy. Zamknięta platforma lub własny framework firmy, hosting i konta w sklepach na koncie wykonawcy, licencja ważna tylko w czasie umowy serwisowej.
• Nierealny harmonogram. Termin, w którym nie ma miejsca na analizę, testy, poprawki po odbiorach i przegląd w sklepach z aplikacjami.
• Anonimowy zespół „samych seniorów”. Bez nazwisk i zaangażowania nie wiesz, kto faktycznie będzie pracował.
• Cena wyraźnie niższa od pozostałych bez wyjaśnienia. Zwykle oznacza węższy zakres, którego nikt nie nazwał.

Pytania do software house’u przed podpisaniem umowy

1. Kto konkretnie będzie pracował w projekcie, w jakim wymiarze i czy są to pracownicy, czy podwykonawcy?
2. Jakie założenia przyjęliście przy wycenie i czego wycena nie obejmuje?
3. Jak wygląda testowanie: kto testuje, czy piszecie testy automatyczne, jaka część budżetu przypada na QA?
4. Kiedy dostanę dostęp do repozytorium i wersji testowej aplikacji?
5. Jak zgłaszam i wyceniacie zmiany zakresu?
6. Jak często i w jakiej formie raportujecie postęp i zużycie budżetu?
7. Jakich bibliotek open source i własnych komponentów użyjecie i na jakich licencjach?
8. Jak wygląda gwarancja, utrzymanie i czas reakcji na awarię po wdrożeniu?
9. Co przekażecie, jeśli współpraca się zakończy, i ile potrwa przekazanie projektu innej firmie?
10. Czy mogę porozmawiać z klientem, dla którego realizowaliście podobny projekt?

Zwróć uwagę nie tylko na treść odpowiedzi, ale też na to, czy padają konkretnie i na piśmie. Wymijające odpowiedzi na pytania o repozytorium i przekazanie projektu to sygnał, że model biznesowy wykonawcy opiera się na uzależnieniu klienta.

Umowa: prawa autorskie do kodu, SLA i gwarancja

Przeniesienie autorskich praw majątkowych

Program komputerowy jest w polskim prawie chroniony jak utwór. Kilka zasad z ustawy o prawie autorskim i prawach pokrewnych ma bezpośrednie znaczenie dla zamawiającego:

• Umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności (art. 53). Formę pisemną zastępuje podpis kwalifikowany, ale akceptacja mailowa już nie.
• Umowa obejmuje tylko pola eksploatacji wyraźnie w niej wymienione (art. 41 ust. 2). Dla programów komputerowych chodzi m.in. o zwielokrotnianie, modyfikowanie i rozpowszechnianie (art. 74 ust. 4). Ogólnik „wszystkie prawa do aplikacji” to za mało.
• Prawa do programu napisanego przez pracownika w ramach obowiązków przysługują pracodawcy (art. 74 ust. 3). Programiści na umowach B2B to inna sytuacja: software house musi najpierw skutecznie nabyć od nich prawa, żeby móc je przenieść na Ciebie. Poproś o potwierdzenie tego w umowie.

Sprawdź też, kiedy prawa przechodzą. Zapis „z chwilą zapłaty całości wynagrodzenia” oznacza, że przy sporze o ostatnią fakturę nie masz praw do niczego. Bezpieczniej, gdy prawa do każdego etapu przechodzą po jego odbiorze i zapłacie. Upewnij się, że umowa pozwala Tobie i innym wykonawcom modyfikować kod, a gotowe komponenty wykonawcy są objęte licencją bezterminową i nieodwołalną.

SLA, gwarancja i dane osobowe

• SLA powinno rozróżniać czas reakcji i czas naprawy oraz kategorie błędów (krytyczny, poważny, drobny). Określ godziny, w których obowiązuje, i konsekwencje przekroczenia.
• Gwarancja ma wskazywać okres i zakres. Ustal, co jest błędem, który wykonawca poprawia bezpłatnie, a co nowym wymaganiem.
• Umowa powierzenia przetwarzania danych osobowych zgodna z art. 28 RODO jest potrzebna, jeśli wykonawca będzie miał dostęp do danych Twoich klientów, np. przy utrzymaniu.
• Kryteria odbioru spisz przed startem etapu. Odbiór „na podstawie wrażenia” kończy się sporem.

Umowę na projekt o istotnym budżecie daj do przejrzenia prawnikowi, który zna umowy IT. Ten tekst nie jest poradą prawną.

Jak porównać trzy oferty software house’u

Zanim porównasz ceny, ujednolić założenia. Wyślij wszystkim firmom ten sam opis zakresu i poproś o listę założeń i wyłączeń w tym samym układzie. Jeśli oferty nadal różnią się wyraźnie, zapytaj o konkretne moduły, w których rozjazd jest największy.

Porównuj całkowity koszt posiadania, a nie tylko cenę budowy: wytworzenie, utrzymanie przez pierwszy rok, hosting, licencje i koszt ewentualnej zmiany wykonawcy. Poniższa tabela pomaga ocenić oferty punktowo, np. w skali od 0 do 2 dla każdego kryterium:

Nadaj kryteriom wagi odpowiednie dla projektu. Przy aplikacji przetwarzającej dane wrażliwe bezpieczeństwo i jakość ważą więcej niż termin, a przy prototypie do testu rynku odwrotnie. W systemach przetwarzających dane klientów zaplanuj też test penetracyjny przed uruchomieniem i sprawdź, czy któraś oferta go uwzględnia.

Kiedy niezależna ocena techniczna oferty się opłaca

Druga opinia osoby technicznej, która nie jest stroną transakcji, ma największy sens, gdy:

• w firmie nie ma nikogo, kto oceni architekturę, technologię i realność wyceny,
• budżet projektu jest istotny w skali firmy albo system będzie krytyczny dla sprzedaży lub obsługi klientów,
• oferty różnią się wyraźnie i nie potrafisz wskazać przyczyny,
• wykonawca proponuje fixed price przy zakresie, który sam uważasz za niejasny,
• przejmujesz projekt od poprzedniego wykonawcy albo oceniasz firmę lub produkt przed inwestycją.

Niezależny ekspert przegląda zakres i wyceny, zadaje wykonawcom pytania techniczne, wskazuje brakujące pozycje, pomaga przygotować załącznik techniczny do umowy i kryteria odbioru. Ważne, żeby nie pobierał prowizji od żadnego z oferentów. Kiedy taka rola ma sens na dłużej, opisujemy w artykule zewnętrzny CTO: kiedy się opłaca. Przeglądy ofert i drugą opinię techniczną przygotowujemy też w ramach naszych usług.