15 pytań, które naprawdę musisz zadać przed podpisaniem umowy. Plus red flags, które zignorowaliśmy u poprzednich dostawców naszych klientów.
Przez 10 lat prowadzenia software house'u rozmawiałem z setkami firm, które przyszły do nas po nieudanych współpracach z innymi wykonawcami. Historie są podobne: przekroczony budżet, opóźnienia, kod, którego nikt nie chce dotykać, i ghosting gdy zaczynają się problemy.
Zebrałem te doświadczenia w przewodnik, który pomoże Ci uniknąć naszych błędów... i ich błędów.
Zanim zaczniesz szukać: przygotowanie
Najczęstszy błąd? Wysyłanie zapytania "potrzebuję aplikacji mobilnej" do 20 firm i porównywanie cen. To jak pytanie "ile kosztuje dom?" bez określenia metrażu, lokalizacji i standardu.
Minimum, które musisz przygotować:
- Jaki problem biznesowy rozwiązujesz? (nie "chcę apkę", ale "chcę zmniejszyć liczbę telefonów do BOK o 40%")
- Kim są użytkownicy? Ilu ich będzie?
- Jakie masz deadline'y i dlaczego? (launch przed Black Friday vs. "byłoby fajnie szybko")
- Jaki masz budżet? (serio - powiedz wprost)
15 pytań, które musisz zadać
"Pokażcie mi 3 projekty podobne do mojego i pozwólcie porozmawiać z tymi klientami."
Red flag: "Mamy NDA na wszystkie projekty" - brzmi profesjonalnie, ale każdy software house ma klientów, którzy zgodzą się na referencje.
"Kto konkretnie będzie pracował nad moim projektem?"
Red flag: "Przydzielimy najlepszy zespół" - bez imion i CV. Duże firmy często sprzedają seniorami, a robią juniorami.
"Co się stanie, gdy lead developer odejdzie w trakcie projektu?"
Red flag: Brak odpowiedzi lub "to się nie zdarza". Ludzie odchodzą - musisz wiedzieć, jaki jest plan B.
"Jak wygląda Wasz proces discovery? Ile to kosztuje?"
Red flag: "Wyślij brief, dostaniesz wycenę mailem" - bez rozmowy, bez pytań o szczegóły. Solidna wycena wymaga zrozumienia kontekstu biznesowego, nie tylko listy funkcji.
"Jak często będziecie mi pokazywać postępy? Jak mogę sprawdzić, czy projekt idzie dobrze?"
Red flag: "Pokażemy Wam gotowy produkt na koniec". W 2025 roku? Serio? To przepis na katastrofę.
Analiza ofert - na co patrzeć
Słaba oferta
- Jedna kwota za całość
- "Technologia: nowoczesna"
- Brak breakdown'u godzin
- Gwarancja bez szczegółów
- Brak informacji o zespole
Dobra oferta
- Podział na fazy z osobnymi kwotami
- Konkretny stack z uzasadnieniem
- Estymacja godzin per feature
- Jasne warunki gwarancji i SLA
- CV zespołu z doświadczeniem
Najdroższy nie znaczy najlepszy
Widziałem projekty za 500k zł, które skończyły w koszu, i za 50k zł, które zarabiają miliony. Cena to jeden z czynników, nie jedyny.
Ale: jeśli jedna oferta jest 3x tańsza od pozostałych - pytaj dlaczego. Albo czegoś nie zrozumieli, albo outsource'ują do tańszych rąk bez Twojej wiedzy, albo są desperacko głodni roboty.
Umowa - must-haves
- Własność kodu - musi przejść na Ciebie po zapłacie
- Escape clause - możliwość wyjścia z umowy z określonym okresem wypowiedzenia
- Definicja "done" - jasne kryteria akceptacji dla każdego etapu
- Gwarancja na bugi - minimum 3 miesiące, standard to 6
- SLA na support - czas reakcji na krytyczne problemy
Szukasz wykonawcy na swój projekt?
Chętnie odpowiemy na te 15 pytań. I na kolejne 15, które przyjdą Ci do głowy.