Przez lata widzieliśmy niejedną historię nieudanej współpracy z software housem. Klient zapłacił połowę budżetu z góry, developer znikał po dwóch tygodniach, albo — co gorsze — projekt skończył się, ale kod był tak źle napisany, że nikt inny nie chciał go przejąć. Te sytuacje nie zdarzają się przez pech. Zdarzają się dlatego, że na etapie wyboru zadaje się złe pytania — albo nie zadaje ich wcale.
Poniżej dziesięć pytań, które warto zadać przed podpisaniem umowy. Nie dlatego, żeby dostawcę złapać na kłamstwie — ale żeby zobaczyć, jak myśli i jak pracuje.
1. Czy mogę zobaczyć kod z poprzednich projektów?
Dobry software house nie ma problemu z pokazaniem kodu — nawet jeśli niektóre projekty są objęte NDA, zwykle znajdzie się coś, co można udostępnić. Czerwona flaga: wymijające odpowiedzi w stylu "wszystkie projekty są poufne". Zielona flaga: GitHub z publicznymi projektami, przykłady kodu z zanonimizowanych wdrożeń, gotowość do code review z udziałem Twojego technicznego doradcy. Kod mówi więcej niż oferta — nie rezygnuj z prawa do jego zobaczenia.
2. Kto będzie faktycznie pracował na moim projekcie?
To jedno z najważniejszych pytań. Wiele firm sprzedaje projekt przez seniora, a realizuje przez juniora — i nie ma w tym nic złego, o ile wiesz o tym z góry. Zapytaj o skład zespołu po nazwisku i doświadczeniu. Zapytaj, kto jest tech leadem i ile godzin tygodniowo będzie zaangażowany. Czerwona flaga: rozmytą odpowiedź "nasz dedykowany zespół zajmie się wszystkim". Zielona flaga: konkretne nazwiska, CV do wglądu, możliwość rozmowy technicznej z osobą, która faktycznie będzie pisała kod.
3. Jak wygląda komunikacja na co dzień?
Poczta e-mail raz w tygodniu to za mało, jeśli budujesz produkt z napiętymi terminami. Zapytaj o narzędzia, częstotliwość statusów, kanały kontaktu w pilnych sprawach i czas reakcji na zgłoszenia. Czerwona flaga: odpowiedź "jesteśmy elastyczni" bez konkretów. Zielona flaga: zdefiniowany rytm — np. tygodniowe call z demo, codzienny update na Slacku, Jira z widocznym postępem dla klienta. Komunikacja to nie formalność — to system wczesnego ostrzegania przed problemami.
4. Jakie masz doświadczenie z podobnymi systemami?
Nie chodzi o to, żeby software house miał identyczny projekt w portfolio. Chodzi o to, żeby rozumiał domenę i typowe pułapki. Firma transportowa potrzebuje kogoś, kto wie, czym jest tachograf i CMR. E-commerce potrzebuje kogoś, kto rozumie wolumeny zamówień i integracje z ERP. Zapytaj wprost: co było najtrudniejsze w ostatnim projekcie z tej branży? Dobry dostawca odpowie konkretnie. Czerwona flaga: "robimy wszystko, poradzimy sobie z każdym projektem". Zielona flaga: konkretny przykład z problemem, rozwiązaniem i wnioskiem.
5. Jak szybko możecie dostarczyć działający prototyp?
Nie chodzi o szybkość dla samej szybkości. Chodzi o to, żeby jak najwcześniej zobaczyć coś działającego — i zdecydować, czy to zmierza we właściwym kierunku. Dobry software house rozumie wartość wczesnego feedbacku i nie ukrywa się przez miesiąc za "pracujemy intensywnie". Czerwona flaga: harmonogram, w którym cokolwiek widocznego pojawi się dopiero w połowie projektu. Zielona flaga: propozycja pierwszego działającego fragmentu w ciągu 1–2 tygodni, z regularnymi demo po każdym sprincie.
6. Co dzieje się, jeśli projekt przekroczy budżet lub deadline?
To pytanie, którego wiele osób boi się zadać. A powinno być pierwszym. Zapytaj wprost: co zrobiliście w ostatnim projekcie, który się opóźnił? Jak informowaliście klienta? Jak to rozwiązaliście? Czerwona flaga: odpowiedź, że "ich projekty zawsze mieszczą się w budżecie" — to albo kłamstwo, albo nieświadomość własnej historii. Zielona flaga: uczciwa opowieść o trudnym projekcie, odpowiedzialność za eskalację i opis procesu zarządzania ryzykiem, który wyciągnęli z doświadczenia.
7. Jak obsługujecie zmiany zakresu w trakcie projektu?
Zakres projektu zmienia się zawsze. Pytanie brzmi: jak zmiany są wyceniane, kto je zatwierdza i jak szybko wchodzą do harmonogramu. Software house, który mówi "zmiany są bez dodatkowych kosztów" albo kłamie, albo przerzuci koszt w inne miejsce. Czerwona flaga: brak procesu — "dogadamy się". Zielona flaga: jasna procedura change request: opis zmiany, estymacja czasu i kosztu, zatwierdzenie klienta przed realizacją, aktualizacja harmonogramu. To chroni obie strony.
8. Czy dostanę kod na własność?
To kwestia prawna i technologiczna jednocześnie. Upewnij się, że umowa jednoznacznie przenosi prawa autorskie majątkowe do kodu na Ciebie — po zakończeniu i zapłacie. Zapytaj też, czy projekt będzie zbudowany na otwartych technologiach i bibliotekach, czy na zamkniętych, własnych rozwiązaniach dostawcy. Czerwona flaga: niejednoznaczne zapisy w umowie, licencja "na użytkowanie" zamiast własności, własny framework lub platforma, z której nie można się wynieść. Zielona flaga: standardowa umowa z cesją praw, kod w repozytorium dostępnym dla Ciebie od pierwszego dnia.
9. Jak wygląda wsparcie po wdrożeniu?
Każde oprogramowanie wymaga utrzymania — błędy produkcyjne, aktualizacje zależności, zmiany środowiskowe. Zapytaj, co dzieje się po tym, jak projekt "idzie live". Czy software house oferuje wsparcie? W jakim modelu — retainer, time & material, SLA? Kto odpowiada za błędy krytyczne w godzinach nocnych? Czerwona flaga: "po wdrożeniu to już wasza sprawa" albo brak jakiegokolwiek planu. Zielona flaga: zdefiniowany model wsparcia z SLA, jasnym zakresem i ceną — nawet jeśli nie planujesz go teraz kupić, sam fakt, że dostawca ma taki produkt, mówi o dojrzałości.
10. Jakie narzędzia i procesy używacie do zapewnienia jakości?
Testy automatyczne, code review, CI/CD, kontrola wersji — to nie są luksusy dla dużych firm. To minimum dla każdego profesjonalnego projektu. Zapytaj wprost: jaki mają coverage testami, czy używają pull requestów z review, czy mają pipeline do automatycznego deployu. Czerwona flaga: "piszemy testy jeśli klient tego wymaga" albo "review robimy nieformale". Zielona flaga: zdefiniowany proces QA jako standardowa część pracy — nie opcja do dokupienia.
Podsumowanie
Wybór software house'u to decyzja, z której skutkami będziesz żyć przez następne miesiące lub lata. Zły dostawca to nie tylko stracone pieniądze — to stracony czas, frustracja i często konieczność przebudowania projektu od zera.
Dobre pytania nie są nieuprzejme. Wiarygodny software house odpowie na nie chętnie — bo sam zadaje je sobie, zanim zaproponuje cokolwiek klientowi.
Te pytania zadajemy sobie sami, zanim zaproponujemy cokolwiek klientowi.
Potrzebujesz podobnego rozwiązania?
Porozmawiajmy o Twoim projekcie
Pierwsza rozmowa jest bezpłatna. Opisz nam swój pomysł — odpowiemy w ciągu jednego dnia roboczego.
Umów bezpłatną rozmowę