Strona główna/Przewodniki/Jak wybrać software house

Jak wybrać software house

Na co zwrócić uwagę wybierając partnera technologicznego. Kryteria, red flags i najlepsze praktyki.

Zaktualizowano:

O czym jest ten przewodnik

Wybór software house'u to decyzja, która na długo określa tempo rozwoju produktu, jakość kodu i to, ile zapłacisz za każdą kolejną zmianę. Źle dobrany partner kosztuje nie tylko budżet projektu, ale też miesiące, których nie da się odzyskać, oraz kod, który często trzeba przepisać.

Rynek jest szeroki: od freelancerów, przez małe zespoły specjalizujące się w jednej technologii, po duże firmy konsultingowe. Każdy model ma sens w innym kontekście. Kluczem jest dopasowanie partnera do skali projektu, budżetu, poziomu niepewności wymagań i sposobu, w jaki Twoja firma podejmuje decyzje.

W tym przewodniku pokazujemy, jak przejść przez wybór krok po kroku: od przygotowania briefu, przez ocenę ofert i weryfikację referencji, po model rozliczeń i zapisy w umowie. Każda sekcja zaczyna się od krótkiej odpowiedzi, a potem rozwija temat o konkrety, które pomogą porównać oferty na chłodno.

Kluczowe zagadnienia

01

Od czego zacząć wybór software house'u?

Zacznij od siebie, nie od listy firm. Spisz problem biznesowy, który ma rozwiązać oprogramowanie, najważniejsze funkcje, ograniczenia budżetowe i oczekiwany termin. Nawet krótki, jednostronicowy brief pozwala porównywać oferty według tych samych kryteriów i szybko odsiać wykonawców, którzy nie rozumieją Twojego celu albo nie mają doświadczenia w podobnej skali.

Dobry brief nie musi być specyfikacją na pięćdziesiąt stron. Wystarczy opis użytkowników, kluczowych procesów, systemów, z którymi trzeba się zintegrować, oraz lista funkcji podzielona na niezbędne i opcjonalne. Dodaj informację, kto po Twojej stronie będzie podejmował decyzje i ile czasu może poświęcić projektowi.

Zastanów się też, czy w ogóle potrzebujesz zewnętrznego zespołu. Jeśli planujesz wieloletni rozwój produktu jako główną działalność firmy, warto rozważyć budowę własnego działu. Porównanie kosztów i ryzyk obu podejść znajdziesz w zestawieniu outsourcing IT vs zespół wewnętrzny.

Na koniec przygotuj krótką listę kandydatów, zwykle trzy do pięciu firm. Więcej ofert rzadko daje lepszą decyzję, za to wydłuża proces i utrudnia rzetelne porównanie.

02

Jakie kryteria brać pod uwagę przy ocenie software house'u?

Najważniejsze kryteria to doświadczenie w podobnych projektach, kompetencje w wymaganym stosie technologicznym, jakość komunikacji, dojrzałość procesu (discovery, testy, wdrożenia), stabilność zespołu i przejrzystość wyceny. Cena ma znaczenie, ale powinna być oceniana dopiero na tle tych czynników, bo najtańsza oferta często okazuje się najdroższa w utrzymaniu.

Zbuduj prostą macierz ocen z wagami. Przykładowo: doświadczenie domenowe i technologiczne 30%, proces i jakość 25%, komunikacja 20%, cena 15%, warunki umowy 10%. Wagi dostosuj do projektu, ale ustal je przed otrzymaniem ofert, żeby nie dopasowywać kryteriów do firmy, która po prostu zrobiła dobre wrażenie.

Zwróć uwagę, czy firma pyta o cele biznesowe, a nie tylko o listę ekranów. Partner, który dopytuje o model przychodów, użytkowników i ryzyka, zwykle proponuje rozsądniejszy zakres. Jeśli Twoje procesy są nietypowe i gotowe narzędzia ich nie obsłużą, sprawdź, czy wykonawca ma doświadczenie w tworzeniu oprogramowania na zamówienie, a nie tylko we wdrażaniu szablonów.

Zapytaj też, kto konkretnie będzie pracował nad projektem i czy możesz porozmawiać z tymi osobami przed podpisaniem umowy. Zespół na prezentacji sprzedażowej nie zawsze jest tym, który potem pisze kod.

03

Jak zweryfikować portfolio i referencje software house'u?

Poproś o dwa lub trzy projekty najbliższe Twojemu pod względem skali, branży lub technologii i dopytaj o rolę firmy w każdym z nich. Porozmawiaj bezpośrednio z byłymi klientami, sprawdź działające produkty, a jeśli to możliwe, zleć krótki płatny etap discovery, który pokaże sposób pracy w praktyce.

Samo portfolio z ładnymi zrzutami ekranu niewiele mówi. Pytaj, co dokładnie zespół zrobił: czy budował produkt od zera, czy tylko frontend, jak długo trwała współpraca, jakie problemy pojawiły się po drodze i jak zostały rozwiązane. Dobra firma bez oporu opowie także o projektach, które nie poszły zgodnie z planem.

W rozmowie z referencyjnym klientem zapytaj o terminowość, reakcję na zmiany zakresu, jakość dokumentacji i to, czy wybrałby tę firmę ponownie. Opinie na platformach branżowych i LinkedIn są pomocne, ale rozmowa telefoniczna daje więcej niuansów. Przykładowe opisy projektów z kontekstem biznesowym znajdziesz w naszych realizacjach.

Najlepszym testem jest płatny warsztat lub discovery trwające od kilku dni do dwóch tygodni. Dostajesz konkretny rezultat, na przykład mapę funkcji i wstępną architekturę, a jednocześnie widzisz, jak zespół komunikuje się, zadaje pytania i dotrzymuje ustaleń.

04

Jakie sygnały ostrzegawcze powinny zapalić czerwoną lampkę?

Uważaj na firmy, które wyceniają projekt bez zadawania pytań, obiecują sztywny termin przy niejasnym zakresie, oferują cenę wyraźnie niższą od rynku, nie mają procesu testowania ani zarządzania zmianą, unikają rozmowy o własności kodu albo nie potrafią wskazać osób, które faktycznie będą realizować projekt.

Wycena przygotowana w jeden dzień na podstawie krótkiego maila zwykle oznacza, że ryzyko zostało ukryte, a nie oszacowane. Brakujące elementy wrócą później jako aneksy, dodatkowe płatności albo obniżona jakość. Rzetelna oferta zawiera założenia, wykluczenia i listę rzeczy, które wymagają doprecyzowania.

Kolejny sygnał to brak dostępu do repozytorium i środowiska testowego w trakcie prac. Powinieneś widzieć postęp regularnie, najlepiej co tydzień lub co dwa tygodnie, a nie dopiero na koniec etapu. Niepokojąca jest też duża rotacja ludzi albo sytuacja, w której jedna osoba odpowiada jednocześnie za analizę, kod, testy i kontakt z klientem.

Jeśli masz za sobą nieudany projekt, przeanalizuj, które z tych sygnałów były widoczne wcześniej, zanim podpisałeś umowę. To najlepsza lista kontrolna przy kolejnym wyborze i dobry punkt wyjścia do rozmowy z nowym wykonawcą.

05

Fixed price czy time & materials – który model współpracy wybrać?

Fixed price sprawdza się, gdy zakres jest dobrze opisany i mało prawdopodobne są zmiany, np. przy małym, zamkniętym module. Time & materials lepiej pasuje do produktów rozwijanych iteracyjnie, gdzie wymagania doprecyzowują się w trakcie. Często najrozsądniejsze jest połączenie: stała cena za discovery, a rozwój rozliczany godzinowo z limitem budżetu.

W modelu fixed price wykonawca bierze na siebie ryzyko wyceny, więc dolicza do niej bufor. Każda zmiana zakresu wymaga renegocjacji, co spowalnia projekt i rodzi spory o to, co było w umowie. Dla klienta zaletą jest przewidywalny koszt, pod warunkiem że wymagania naprawdę są stabilne.

Time & materials daje elastyczność: możesz zmieniać priorytety po każdym sprincie i płacisz za faktycznie wykonaną pracę. Wymaga za to większego zaangażowania po Twojej stronie, regularnych przeglądów i przejrzystego raportowania godzin. Przy dłuższej współpracy warto rozważyć także model dedykowanego zespołu, który działa jak przedłużenie Twojego działu IT.

Niezależnie od modelu ustal limit budżetu na etap, częstotliwość demo oraz sposób akceptacji prac. To chroni obie strony przed niespodziankami.

06

Ile kosztuje współpraca z software house'em w Polsce?

Koszt zależy od zakresu, technologii i modelu rozliczeń. Stawki polskich software house'ów są zwykle niższe niż w Europie Zachodniej przy porównywalnej jakości. W Midapt stawka godzinowa to 140 PLN, a system średniej wielkości mieści się zazwyczaj w przedziale 60 000 - 200 000 PLN. Ostateczną kwotę określa dopiero analiza wymagań.

Porównując oferty, sprawdzaj, co obejmuje cena. Czy wycena zawiera projekt UX/UI, testy, konfigurację infrastruktury, wdrożenie produkcyjne i okres gwarancyjny? Różnica między ofertami często wynika nie z wyższej stawki, lecz z tego, że jedna firma uwzględniła elementy, które druga pominęła. Testy to zwykle 15-20% budżetu i nie warto na nich oszczędzać.

Uważaj na porównywanie samych stawek godzinowych. Zespół z wyższą stawką, ale doświadczony w podobnych projektach, często dowiezie ten sam zakres w krótszym czasie i z mniejszą liczbą poprawek. Poproś każdą firmę o rozbicie wyceny na etapy i role, a także o informację, jak wycena zmieni się, jeśli zakres wzrośnie o kilka funkcji. To szybko pokaże, która oferta jest realistyczna.

Pamiętaj też o kosztach po starcie. Utrzymanie, aktualizacje bibliotek, monitoring i drobne poprawki to zazwyczaj 15-25% kosztu budowy rocznie. Pełniejszy obraz stawek, struktury zespołu i realiów rynku znajdziesz na stronie software house Polska, a orientacyjne widełki dla różnych typów projektów w cenniku.

07

Co musi znaleźć się w umowie z software house'em?

Umowa powinna jasno regulować przeniesienie autorskich praw majątkowych do kodu z określeniem pól eksploatacji, dostęp do repozytorium, zasady akceptacji prac, procedurę zmiany zakresu, gwarancję i czas reakcji na błędy, poufność, ochronę danych osobowych oraz warunki zakończenia lub wypowiedzenia współpracy wraz z przekazaniem dokumentacji i dostępów.

W polskim prawie przeniesienie praw autorskich wymaga formy pisemnej i wskazania pól eksploatacji, dlatego ogólny zapis, że kod należy do klienta, może okazać się niewystarczający. Warto, aby umowę przejrzał prawnik znający branżę IT. Zwróć uwagę także na biblioteki open source i komponenty, których wykonawca używa w wielu projektach.

Jeśli system przetwarza dane osobowe, potrzebna będzie umowa powierzenia przetwarzania zgodna z RODO. Ustal też, co dzieje się po zakończeniu współpracy: kto przejmuje dostęp do serwerów, kont w chmurze i domen oraz w jakim terminie wykonawca przekaże pełną dokumentację.

Dobrze napisana umowa nie zakłada złej woli. Po prostu porządkuje sytuacje, które w każdym projekcie prędzej czy później się pojawią.

Rozpocznij projekt

Masz pomysł na projekt?

Porozmawiajmy o Twoich potrzebach. Umów bezpłatną konsultację i dowiedz się, jak możemy pomóc w realizacji Twojej wizji.

Contact