Jak wybrać software house? Dziesięć pytań, które warto zadać przed podpisaniem umowy

Wybór software house'u zwykle zaczyna się od portfolio, ceny i wrażenia z pierwszej rozmowy. To ważne, ale większość problemów we współpracy wychodzi dopiero po kilku miesiącach: kod, którego nikt poza jednym programistą nie rozumie, serwer zarejestrowany na wykonawcę, brak testów, wdrożenia „ręcznie w piątek wieczorem”. Poniżej dziesięć pytań, które pozwalają to sprawdzić przed podpisaniem umowy — razem z odpowiedziami, których warto oczekiwać.

1. Do kogo należy kod, repozytorium i infrastruktura?

Właściwa odpowiedź: do Ciebie, od pierwszego dnia. Repozytorium na Twoim koncie (albo z pełnym dostępem administracyjnym), serwery i domeny na Twoją firmę, dokumentacja w Twoich rękach. Jeśli wykonawca przekazuje kod „po zakończeniu projektu” albo trzyma infrastrukturę u siebie, zmiana dostawcy w przyszłości będzie trudna i kosztowna. O tym, jak wygląda sytuacja, gdy tego zabrakło, piszemy przy przejmowaniu projektów po innych wykonawcach.

2. Czy mogę zobaczyć przykładowy kod?

Referencje mówią o relacji z klientem, kod — o jakości pracy. Poważny wykonawca pokaże zanonimizowane fragmenty kodu, standardy pracy i sposób dokumentowania. Poproś o to i pokaż komuś technicznemu, nawet z zewnątrz.

3. Jak wygląda code review i testy?

Szukasz odpowiedzi w rodzaju: „każda zmiana przechodzi przegląd drugiego programisty, zanim trafi do głównej gałęzi, a testy uruchamiają się automatycznie przy każdym pull requeście”. Brak code review oznacza, że jakość zależy od jednej osoby. Brak testów oznacza, że każda zmiana może zepsuć coś, co działało.

4. Kto będzie pracował nad projektem?

Zapytaj, kto konkretnie: ile osób, jakie role, czy będzie stały zespół, czy osoby zmieniające się między projektami. Zapytaj też, co się stanie, gdy kluczowa osoba odejdzie — odpowiedź powinna odwoływać się do dokumentacji i code review, dzięki którym wiedza nie siedzi w jednej głowie.

5. Jak będę wiedzieć, co się dzieje w projekcie?

Konkretna odpowiedź to na przykład: tygodniowy status na piśmie, demo działającej części po każdym sprincie, dostęp do narzędzia do zarządzania zadaniami (Jira, Linear) i dedykowany kanał komunikacji. „Będziemy w kontakcie” to nie jest odpowiedź.

6. Jak rozliczamy zmiany zakresu?

Zmiany będą — to pewne. Ważne, żeby przed startem było jasne, jak się je zgłasza, kto je wycenia i jak wpływają na termin. Z tym wiąże się wybór modelu rozliczenia; porównanie opisujemy w tekście o Fixed Price i Time & Material.

7. Kto zajmuje się serwerami i wdrożeniami?

Aplikacja musi gdzieś działać. Zapytaj, czy wykonawca konfiguruje infrastrukturę, jak wygląda wdrożenie nowej wersji (dobra odpowiedź: automatycznie, jednym poleceniem), jak robione są kopie zapasowe i kto monitoruje aplikację po starcie. Jeśli „to już po stronie klienta”, zaplanuj, kto się tym zajmie. Zobacz, co obejmują usługi DevOps.

8. Co dzieje się po wdrożeniu?

Zapytaj o utrzymanie, zanim podpiszesz umowę na budowę: czy jest umowa SLA z czasem reakcji, monitoring, aktualizacje bezpieczeństwa, jak rozliczane są poprawki. Wykonawca, który znika po wdrożeniu, zostawia Cię z aplikacją bez opieki. Opisujemy to szerzej na stronie utrzymania i rozwoju aplikacji.

9. W jakich technologiach pracujecie i dlaczego?

Dobra odpowiedź jest konkretna i pokazuje, że wykonawca ma swój sprawdzony stack, ale potrafi uzasadnić wybór. Uważaj na dwie skrajności: firmę, która obiecuje wszystko w każdej technologii, i firmę, która wybiera modne narzędzie bez względu na problem. My piszemy głównie w Laravelu i React, aplikacje mobilne w React Native, a po Rusta sięgamy tam, gdzie liczy się wydajność — i mówimy wprost, gdy projekt lepiej zrobić inaczej.

10. Co, jeśli zechcę zmienić wykonawcę?

To pytanie mówi najwięcej. Dobra odpowiedź: „masz kod, dokumentację i dostępy, a my przekażemy wiedzę nowemu zespołowi”. Wykonawca, który nie boi się tego pytania, zwykle nie musi trzymać klientów zależnością.

Na co jeszcze zwrócić uwagę

• Realizacje podobne do Twojej. Nie muszą być z tej samej branży, ale powinny mieć podobną skalę i złożoność. Poproś o opis problemu i rozwiązania, a nie tylko zrzut ekranu.
• Pytania, które zadaje wykonawca. Dobry software house na pierwszej rozmowie pyta więcej o Twój biznes niż o technologię.
• Szczerość co do zakresu. Jeśli wykonawca od razu zgadza się na wszystko bez pytań o cel, prawdopodobnie nie przemyślał ryzyka.
• Gotowość, by powiedzieć „nie”. Czasem gotowe narzędzie wystarczy i warto to usłyszeć, zanim wydasz budżet na dedykowane rozwiązanie.

Podsumowanie

• Sprawdź własność kodu i infrastruktury — to fundament bezpiecznej współpracy.
• Zapytaj o code review, testy i przykładowy kod — to mówi o jakości więcej niż portfolio.
• Ustal z góry komunikację, zmiany zakresu i utrzymanie.
• Zadaj pytanie o zmianę wykonawcy — odpowiedź dużo powie o intencjach.

Chcesz zadać nam te pytania? Umów bezpłatną konsultację — odpowiemy na każde z nich, a przykładowy kod pokażemy przed podpisaniem umowy. Nasze projekty opisujemy w zakładce Realizacje.