--- title: "Jak wybrać firmę programistyczną: pytania przed umową" description: "Pytania do firmy programistycznej przed podpisaniem umowy: kto wykona pracę, dorobek, zakres, prawa do kodu, bezpieczeństwo, przekazanie i sygnały alarmowe." canonical: https://sdk.enterprises/pl/insights/choosing-a-software-partner language: pl --- # Jak wybrać firmę programistyczną: pytania przed umową Zaktualizowano: 2026-09-25 > Przed zatrudnieniem firmy programistycznej trzeba dokładnie ustalić, kto będzie pisał kod, jakie podobne systemy już dostarczyła, jak zdefiniowano zakres i odbiór oraz do kogo należy kod od pierwszego dnia. Wymijające odpowiedzi na którekolwiek z tych pytań są poważniejszym sygnałem ostrzegawczym niż wysoka cena. ## Kto naprawdę będzie pisał kod Osoby obecne na spotkaniu handlowym często nie są tymi, które zbudują system. Warto poprosić o nazwiska, role i doświadczenie inżynierów, którzy będą pracować nad projektem, oraz o rozmowę z liderem technicznym przed podpisaniem umowy. Trzeba też zapytać, czy część prac jest zlecana podwykonawcom lub freelancerom. Oba rozwiązania mogą dobrze działać, ale należy o tym wiedzieć, a partner powinien ręczyć za każdą osobę, którą wprowadza do projektu. Warto również zapytać, co się stanie, jeśli kluczowy inżynier odejdzie w trakcie projektu, i kto zapłaci za czas potrzebny zastępcy na wdrożenie się. - Kto jest liderem technicznym i jaką część swojego czasu poświęca temu projektowi? - Którzy inżynierowie są pracownikami, a którzy podwykonawcami lub freelancerami? - Jak firma wybiera i sprawdza specjalistów, których angażuje? - Jak wygląda proces, gdy ktoś odchodzi albo nie pasuje do zespołu? ## Doświadczenie, które odpowiada Państwa problemowi Długa lista klientów niewiele dowodzi, jeśli żaden projekt nie przypomina Państwa projektu. Warto poprosić o przykłady z podobnymi ograniczeniami: ten sam rodzaj systemu, porównywalny ruch lub wrażliwość danych, podobny kontekst regulacyjny. Następnie zapytać, co w każdym przypadku zrobił ten konkretny zespół, a nie co osiągnął cały program klienta. Trzeba jasno ustalić, czyje doświadczenie się kupuje. Niektóre firmy przedstawiają indywidualny dorobek swoich inżynierów, co jest w porządku, jeśli mówią o tym uczciwie. Warto zapytać, kiedy firma została założona, które prace wykonała w ramach własnych umów i czy można porozmawiać z jej byłym klientem. ## Zakres, kamienie milowe i odbiór na piśmie Wiele sporów bierze się z zakresu, którego nigdy nie spisano precyzyjnie. Dobra oferta wymienia rezultaty, dzieli prace na kamienie milowe i określa, jak odbywa się odbiór każdego z nich, na przykład przez testy, które przechodzą, demo w środowisku testowym (staging) lub przekazaną dokumentację. Warto zapytać, jak obsługiwane i wyceniane są zmiany zakresu oraz jaki jest model rozliczeń. Stała cena pasuje do dobrze zdefiniowanych prac, a rozliczenie czasu i materiałów do fazy rozpoznania i zmieniających się wymagań. W obu przypadkach należy zobaczyć założenia, na których opiera się wycena. ## Prawa do kodu i przekazanie projektu ustalone przed startem Umowa powinna stwierdzać, że kod i związana z nim własność intelektualna należą do Państwa, oraz określać, kiedy następuje przeniesienie praw. Repozytoria, konta chmurowe i domeny najlepiej zakładać w Państwa organizacji od pierwszego dnia, a partnera zapraszać jako współpracownika, aby nigdy nie zależeć od niego w kwestii dostępu. Przekazanie projektu planuje się na początku, a nie na końcu. Warto zapytać, co zostanie przekazane: dokumentacja, zapisy decyzji architektonicznych, instrukcje operacyjne (runbooki) i sesje robocze z Państwa zespołem. Trzeba też sprawdzić, jakich licencji zewnętrznych i open source projekt będzie używał, bo wiążą się z nimi obowiązki. ## Uzgodniony sposób śledzenia postępów Nigdy nie powinno być potrzeby dopytywania, czy projekt idzie zgodnie z planem. Warto uzgodnić stały rytm, na przykład cotygodniowe demo działającego oprogramowania i krótki pisemny raport o postępach, ryzykach i decyzjach, których potrzeba z Państwa strony. Należy poprosić o bezpośredni dostęp do systemu zgłoszeń i repozytorium oraz o jedną wskazaną osobę kontaktową, która odpowiada za realizację. Trzeba też ustalić, jak eskalowane są problemy i jak szybko można spodziewać się odpowiedzi. ## Praktyki bezpieczeństwa zamiast odznak Warto zapytać, jak inżynierowie uzyskują dostęp do Państwa systemów i danych, jak przechowywane są sekrety, jak kod jest przeglądany przed wdrożeniem i jak zależności są sprawdzane pod kątem znanych podatności. Konkretne odpowiedzi znaczą więcej niż slajd z logotypami. Jeśli partner będzie przetwarzał dane osobowe w Państwa imieniu, potrzebna jest umowa powierzenia przetwarzania danych spełniająca wymogi RODO. Jeśli dostawca powołuje się na certyfikat, warto poprosić o jego kopię wraz z zakresem i upewnić się, że obejmuje zespół i usługi, które Państwo kupują. ## Sygnały ostrzegawcze, przy których warto przerwać rozmowę Pojedynczy sygnał ostrzegawczy może mieć wyjaśnienie. Kilka naraz zwykle oznacza, że projekt będzie trudniejszy, niż musiałby być. - Firma nie potrafi wskazać inżynierów, którzy wykonają pracę. - Studia przypadków pokazują wyniki, ale nie to, co faktycznie zrobił ten zespół. - Wycena przychodzi, zanim ktokolwiek zadał szczegółowe pytania o Państwa system. - Repozytoria i konta chmurowe pozostają pod kontrolą partnera. - Kamienie milowe nie mają spisanych kryteriów odbioru. - Na pytania o bezpieczeństwo pada ogólne zapewnienie zamiast konkretnych praktyk. ## Najważniejsze wnioski - Przed podpisaniem umowy warto poznać lidera technicznego i dowiedzieć się, kto będzie pisał kod. - Doświadczenie ocenia się po tym, jak bardzo odpowiada Państwa ograniczeniom, i po tym, co zrobił sam zespół. - Spisane kamienie milowe z jasnymi kryteriami odbioru zapobiegają wielu sporom o zakres. - Repozytoria i konta chmurowe powinny od pierwszego dnia należeć do Państwa organizacji. - Warto pytać o konkretne praktyki bezpieczeństwa i o dowód każdego certyfikatu, na który powołuje się dostawca. ## FAQ ### Z iloma firmami porozmawiać przed wyborem? Z tyloma, by móc porównać realne różnice w podejściu, co w przypadku większości projektów oznacza kilka. Każda powinna dostać ten sam opis projektu i te same pytania, aby odpowiedzi dało się porównać. ### Stała cena czy rozliczenie czasu i materiałów? Stała cena pasuje do prac, które można szczegółowo opisać przed ich rozpoczęciem. Rozliczenie czasu i materiałów (time and materials) pasuje do fazy rozpoznania, zmieniających się wymagań i ciągłego rozwoju, pod warunkiem przejrzystego raportowania i regularnych demo. ### Co powinna obejmować pierwsza rozmowa z potencjalnym partnerem? Państwa cel, ograniczenia, harmonogram i istniejące systemy, a także pytania partnera do Państwa. Partner, który już podczas pierwszej rozmowy zadaje szczegółowe pytania o system, zwykle wyceni go uczciwie. W SDK Enterprises taka pierwsza rozmowa trwa 30 minut i odbywa się po francusku lub po angielsku. ## Zacznijmy od Państwa potrzeby - [Tworzenie stron internetowych](https://sdk.enterprises/pl/website-development) - [CTO na część etatu](https://sdk.enterprises/pl/fractional-cto) ## Powiązane usługi - [Audyt techniczny i doradztwo](https://sdk.enterprises/pl/services/consulting) - [Oprogramowanie na zamówienie](https://sdk.enterprises/pl/services/product-engineering)