Jak wybrać partnera technologicznego? 10 pytań przed podpisaniem umowy

Raporty Standish Group (CHAOS Report 2025) pokazują, że 66% projektów IT przekracza budżet lub termin, a 19% kończy się całkowitą porażką. W zdecydowanej większości przypadków przyczyną nie jest technologia, lecz komunikacja, zarządzanie projektem i niedopasowanie oczekiwań między klientem a wykonawcą. W Polsce rynek software house'ów liczy ponad 5 000 firm — od jednoosobowych freelancerów po korporacje z setkami programistów. Wśród nich są świetne zespoły, ale też firmy, które obiecują więcej niż mogą dostarczyć. Jak odróżnić jednych od drugich? Nie po portfolio — bo każdy pokaże najlepsze projekty. Nie po cenie — bo najtańsza oferta rzadko oznacza najlepszą wartość. Kluczem jest zadawanie właściwych pytań jeszcze przed podpisaniem umowy. W ciągu 8 lat pracy z firmami B2B zebraliśmy 10 pytań, które konsekwentnie pomagają naszym klientom ocenić potencjalnych partnerów. Pogrupowaliśmy je w pięć obszarów tematycznych: proces i metodologia, zespół i komunikacja, własność kodu i IP, wsparcie i utrzymanie oraz budżet i harmonogram.

Pytanie 1: Jak wygląda Wasz proces wytwarzania oprogramowania od briefu do wdrożenia? Słuchaj, czy partner opisuje konkretne etapy (discovery, design, development, QA, deployment), czy mówi ogólnikami. Dobry partner powinien umieć narysować swój proces na kartce w 5 minut — z nazwami etapów, artefaktami na wyjściu każdego etapu i punktami decyzyjnymi, w których klient akceptuje lub odrzuca rozwiązanie. Pytanie 2: Jaka jest Wasza metodologia zarządzania projektem i jak często będę otrzymywać aktualizacje? Scrum, Kanban, własna hybryda — nazwa jest mniej ważna niż rytm komunikacji. Szukaj: regularnych sprintów (1–2 tygodnie), demo po każdym sprincie, backlogu dostępnego online (Jira, Linear, Notion), cotygodniowego raportu statusu. Jeśli partner proponuje miesięczne aktualizacje — uciekaj. Miesiąc bez informacji zwrotnej to miesiąc, w którym projekt może pójść w złym kierunku. Projekty z tygodniowym cyklem feedbacku mają 3,5 razy większe szanse na sukces według badań PMI z 2024 roku.

Pytanie 3: Kto konkretnie będzie pracował nad moim projektem i czy mogę poznać te osoby przed podpisaniem umowy? To jedno z najważniejszych pytań, a zarazem jedno z najczęściej pomijanych. Wiele software house'ów sprzedaje projekt seniorom, a realizuje juniorami. Poproś o LinkedIn profile osób, które będą przypisane do projektu, oraz o informację, jaki procent ich czasu będzie dedykowany Twojemu projektowi. Jeśli kluczowy developer pracuje na Twoim projekcie na 30% etatu, a resztę czasu spędza na innych projektach — jakość i tempo ucierpią. Pytanie 4: Kto jest moim głównym punktem kontaktu i jaki jest czas odpowiedzi na pilne kwestie? Szukaj jednej osoby odpowiedzialnej — project managera lub tech leada — z którą możesz rozmawiać bezpośrednio, nie przez warstwy handlowe. Dopytaj o SLA komunikacyjne: czy na wiadomość na Slacku dostajesz odpowiedź w 2 godziny, czy w 2 dni? Dobry standard to: Slack/email — odpowiedź w ciągu 4 godzin roboczych, spotkanie wideo — możliwość umówienia w ciągu 24 godzin.

Pytanie 5: Kto jest właścicielem kodu źródłowego i czy mam pełne prawa do repozytorium od dnia pierwszego? To pytanie, które powinno być deal-breakerem. Jedyną akceptowalną odpowiedzią jest: Ty jesteś właścicielem kodu od momentu opłacenia faktury za dany sprint. Kod powinien być przechowywany w repozytorium, do którego masz pełen dostęp (np. GitHub organizacja klienta). Jeśli partner przechowuje kod na swoim koncie i 'udostępni go po zakończeniu projektu' — to ryzyko, które może kosztować Cię cały projekt w razie konfliktu. Pytanie 6: Czy używacie bibliotek open-source i jaki jest ich wpływ na licencjonowanie mojego produktu? Każdy nowoczesny projekt korzysta z dziesiątek zależności open-source. Dobry partner powinien umieć wyjaśnić, jakich licencji używa (MIT, Apache 2.0, GPL) i czy którekolwiek z nich nakładają ograniczenia na komercyjne wykorzystanie Twojego produktu. W szczególności licencje copyleft (GPL, AGPL) mogą wymusić udostępnienie kodu źródłowego — jeśli Twój produkt jest SaaS-em, AGPL może mieć poważne konsekwencje. Partner powinien prowadzić rejestr zależności i ich licencji.

Pytanie 7: Co się dzieje po wdrożeniu — jaki jest model wsparcia i ile kosztuje? Wdrożenie to nie koniec — to początek. Systemy wymagają aktualizacji bezpieczeństwa, poprawek, drobnych zmian i monitoringu. Poproś o konkretny cennik wsparcia: ile kosztuje godzina pracy po wdrożeniu, czy jest pakiet godzin miesięcznych (retainer), jaki jest SLA na naprawę krytycznych błędów (powinno być poniżej 4 godzin), jaki jest SLA na błędy niekrytyczne (24–48 godzin). Typowy koszt retainera dla systemu B2B to 3 000–8 000 zł miesięcznie za 10–20 godzin wsparcia. Pytanie 8: Czy dokumentujecie kod i procesy w sposób umożliwiający przejęcie projektu przez inny zespół? To pytanie na wypadek, gdyby współpraca się nie udała. Dobry partner dostarczy: dokumentację techniczną (architektura, schemat bazy danych, API), dokumentację wdrożeniową (jak postawić środowisko), README w repozytorium pozwalające nowemu deweloperowi uruchomić projekt w mniej niż godzinę. Jeśli partner nie dokumentuje — tworzysz uzależnienie, które może być bardzo kosztowne.

Pytanie 9: Jak wyceniacie projekt — fixed price, time & material czy hybryda — i jakie są ryzyka każdego modelu? Fixed price daje przewidywalność budżetową, ale wymaga bardzo precyzyjnego zakresu (a ten rzadko jest precyzyjny na starcie). Time & material daje elastyczność, ale wymaga zaufania i kontroli — bez nich budżet może wymknąć się spod kontroli. Najlepszym modelem dla większości projektów B2B jest hybryda: discovery i design w modelu fixed price (10–15% budżetu), a development w T&M z cap'em (budżetem maksymalnym) na każdy sprint. Pytanie 10: Jaki jest Wasz track record z terminowością i co robicie, gdy projekt się opóźnia? Każdy powie, że jest terminowy. Poproś o konkrety: jaki procent projektów w ostatnim roku został dostarczony w terminie? Jaki był średni procent przekroczenia budżetu? Co robicie, gdy sprint się opóźnia — dodajecie ludzi, przenosicie zadania, czy informujecie klienta i renegocjujecie zakres? Transparentny partner poda realne liczby — np. '85% projektów dostarczamy w budżecie, średnie przekroczenie to 12%' — zamiast obiecywać 100% terminowość.

Na podstawie dziesiątek rozmów z klientami, którzy przychodzili do nas po nieudanych projektach, zidentyfikowaliśmy siedem czerwonych flag. Po pierwsze: brak pytań o Twój biznes — jeśli partner od razu mówi o technologii, nie pytając o cele biznesowe, procesy i użytkowników, buduje system w próżni. Po drugie: brak dostępu do repozytorium przed końcem projektu. Po trzecie: brak dedykowanego project managera — 'u nas każdy developer zarządza swoją częścią' to przepis na chaos. Po czwarte: niechęć do podpisania NDA lub brak jasnych klauzul dotyczących IP w umowie. Po piąte: wycena bez discovery — jeśli ktoś wycenia projekt na podstawie godzinnej rozmowy, albo nie rozumie zakresu, albo liczy na scope creep. Po szóste: brak referencji z projektów o podobnej skali — poproś o kontakt do 2–3 klientów i zadzwoń do nich. Po siódme: komunikacja tylko mailowa, bez narzędzi do zarządzania projektem — brak Jiry, Lineara czy choćby Trello oznacza brak struktury.

W Stackpilot odpowiadamy na wszystkie 10 pytań jeszcze na etapie pierwszej rozmowy — bez ukrywania czegokolwiek. Nasz proces jest opisany w dokumentacji, którą udostępniamy przed podpisaniem umowy. Kod od pierwszego dnia żyje w repozytorium klienta na GitHubie. Pracujemy w sprintach tygodniowych z demo w każdy piątek. Każdy projekt zaczyna się od płatnego discovery (zwykle 5 000–12 000 zł), które kończy się dokumentem wymagań, architekturą systemu, estymacją kosztów i harmonogramem. Klient może z tym dokumentem pójść do dowolnego innego wykonawcy — nie uzależniamy nikogo od siebie. Wsparcie po wdrożeniu oferujemy w modelu retainerowym z jasnym SLA: błąd krytyczny — reakcja w 2 godziny, naprawa w 8 godzin; błąd standardowy — reakcja w 8 godzin, naprawa w 48 godzin. Dokumentujemy każdy projekt: architektura, API, baza danych, procesy wdrożeniowe, instrukcje dla nowych developerów. Nasz track record: 91% projektów w budżecie, średnie przekroczenie harmonogramu — 8%. Nie jesteśmy idealni, ale jesteśmy transparentni.