Jak wybrać software house - i na co uważać

Przy wyborze software house’u sprawdź trzy rzeczy: odpowiedzialność za produkcję, skład zespołu realizującego projekt i warunki przekazania systemu. Portfolio i technologia są pomocne dopiero wtedy, gdy odnoszą się do podobnej skali, ryzyka oraz etapu życia produktu.

Piszemy to jako wykonawca, więc masz prawo do podejrzliwości. Dlatego pytania niżej są sformułowane tak, żeby dały się zadać także nam — i tak, żeby zła odpowiedź była widoczna.

Trzy pytania, które mówią najwięcej

1. Co utrzymujecie dziś na produkcji i jak dowiadujecie się o awarii?

„Zrobiliśmy” i „utrzymujemy” to różne kompetencje. Pytanie o działający system pozwala ocenić monitorowanie, reakcję na incydenty, kopie oraz odpowiedzialność po wdrożeniu — elementy słabo widoczne w samym portfolio.

Dobra odpowiedź jest konkretna: jaki zakres wykonawca utrzymuje, jak monitoruje usługę, kto reaguje, w jakim czasie i co pozostaje odpowiedzialnością klienta. Poufność może ograniczać nazwę projektu, ale nie powinna uniemożliwiać opisania procesu.

U nas przykładem jest platforma analityczna oparta na TimescaleDB: system wdrożony na VPS, z kolektorami pracującymi w trybie ciągłym, monitorowaniem i cyklicznym raportowaniem. Monitorowanie ma wykrywać przerwy, a nie obiecywać stuprocentową dostępność.

2. Kto konkretnie napisze mój kod?

Pytanie dotyczy przejrzystości modelu realizacji. Zespół własny, partnerzy i podwykonawcy mogą dostarczyć dobry wynik, jeśli wiadomo, kto odpowiada za architekturę, przegląd jakości, ciągłość oraz prawa do wytworzonego kodu.

Dopytaj: czy osoba prowadząca rozmowę handlową będzie w projekcie? Ile projektów prowadzi jednocześnie? Kto przejmie sprawę, gdy ta osoba pójdzie na urlop?

3. Jak wygląda rozstanie?

To pytanie łatwo pominąć, choć warunki wyjścia decydują o zależności od wykonawcy. Sprawdzaj wyjście równie uważnie jak start. Co dostajesz przy zakończeniu współpracy:

• repozytorium z historią i prawami do kodu wytworzonego dla klienta, z wykazem licencji zależności,
• dostęp do serwera, domeny i kluczowych usług na kontach klienta albo udokumentowaną procedurę ich przekazania,
• dokumentację potrzebną innemu zespołowi do uruchomienia i przejęcia uzgodnionego zakresu,
• dane w formacie do wyeksportowania.

Konta kluczowych usług powinny należeć do klienta albo mieć uzgodnioną procedurę przekazania. Jeśli z powodów operacyjnych wykonawca administruje dostępem, umowa powinna opisywać odzyskanie kontroli i eksport danych.

Dziewięć pytań uzupełniających

4. Jak wyceniacie i co się dzieje, gdy zakres się zmieni? Odpowiedź „damy znać” zwiększa ryzyko sporu. Powinien być ustalony tryb zmiany zakresu.
5. Co wchodzi w „wdrożenie”? Ustal odpowiedzialność za monitorowanie, kopie zapasowe, przetestowane odtworzenie, certyfikaty i reakcję na incydenty. Brak tych pozycji może oznaczać pilotaż albo przeniesienie obowiązków na klienta — powinno to być jawne.
6. Jak często będę widział działającą wersję? Odbiór dopiero na końcu zwiększa koszt późnego wykrycia rozbieżności. Ustal rytm demonstracji dopasowany do długości projektu i momenty, w których można jeszcze zmienić kierunek.
7. Co się stanie, gdy po dwóch tygodniach okaże się, że pomysł wymaga zmiany? Sprawdzasz, czy proces w ogóle zakłada uczenie się w trakcie.
8. Jak testujecie? Nie chodzi o listę narzędzi, a o to, czy logika, na której stoją pieniądze, ma testy automatyczne i czy ktokolwiek uruchamia je przed wdrożeniem.
9. Kto po Waszej stronie decyduje o architekturze? Chcesz wiedzieć, czy jest jedna osoba odpowiedzialna za spójność, czy każdy pisze po swojemu.
10. Jak wygląda utrzymanie i ile kosztuje? Poproś o zakres odpowiedzialności i czas reakcji zamiast ogólnego „będziemy dostępni”.
11. Gdzie będą przetwarzane nasze dane? Przy projektach z AI to szczególnie ważne pytanie — rozwijamy je w bezpieczeństwie danych przy wdrożeniu AI.
12. Możecie opisać trudny projekt i powiedzieć, czego zmieniliście w procesie? Wykonawca może nie móc ujawnić klienta, ale powinien umieć konkretnie opisać problem, decyzję i wdrożone zabezpieczenie. Referencję proś dopiero za zgodą jej autora.

Siedem sygnałów ostrzegawczych

• Wycena bez jawnych założeń. Wstępny przedział po jednym mailu może służyć kwalifikacji, ale oferta wiążąca powinna opisywać zakres, wyłączenia i tryb zmiany.
• Brak pytań o rezultat i ryzyka. Sprawdź, czy wykonawca rozumie problem, dane, integracje i koszt błędu, a nie tylko listę funkcji.
• Brak technicznej weryfikacji przed zobowiązaniem. Handlowiec może prowadzić rozmowę, lecz wykonalność i istotne założenia powinny przejść ocenę osoby odpowiedzialnej technicznie.
• Kod i kluczowe dostępy wyłącznie u wykonawcy bez procedury przekazania. Patrz punkt trzeci.
• Sam stack jako argument. „Robimy w najnowszej technologii” nie jest odpowiedzią na pytanie o Twój problem.
• Termin bez marginesu. Obietnica „na pewno w cztery tygodnie” bez zastrzeżeń wskazuje, że nikt nie liczył ryzyk.
• Brak sposobu ustalenia zakresu. Nie każdy mały projekt potrzebuje pełnego discovery, ale przed kodowaniem muszą powstać przynajmniej kryteria odbioru, założenia i właściciel decyzji. Przy większej niepewności proponujemy discovery.

Duży czy mały wykonawca?

Nie ma jednej odpowiedzi. Poniższe różnice są częstymi modelami organizacyjnymi, nie gwarancją wynikającą z rozmiaru firmy:

	Mniejsze studio	Duży software house
Kontakt z osobą techniczną	często bezpośredni	zależy od składu projektu
Zmiana zakresu	może być szybka, ale mniej sformalizowana	częściej ma formalny proces
Ciągłość zespołu	sprawdź plan zastępstw i dokumentację	sprawdź rotację oraz gwarancję składu
Procedury i SLA	mogą być dopasowane indywidualnie	częściej są standaryzowane
Dopasowanie do projektu	zależy od kompetencji i dostępności	zależy od kompetencji i minimalnej skali kontraktu

W mniejszym studiu jednym z ryzyk może być zależność od pojedynczej osoby — warto więc zapytać o zastępstwo, dokumentację i sposób przekazania. W naszym modelu repozytorium trafia do klienta w zakresie określonym umową; własność kont i procedurę przekazania kluczowych dostępów również ustalamy dla konkretnego projektu. Każde przejęcie nadal wymaga czasu na poznanie systemu.

Czego nie sprawdzać

Trzy rzeczy, które zajmują dużo miejsca w rozmowach i mało mówią:

• Sama liczba realizacji. Sto stron wizytówkowych jest słabym dowodem umiejętności zbudowania systemu o innym ryzyku i skali; sprawdź podobieństwo zakresu oraz odpowiedzialność za produkcję.
• Lista technologii na stronie. Wpisanie nazwy do stopki jest darmowe.
• Sama wielkość zespołu. Zapytaj o osoby przypisane do Twojego projektu, ich dostępność, odpowiedzialność i plan zastępstw. Łączna liczba pracowników nie odpowiada na te pytania.

Najczęstsze pytania

Czy warto płacić za wycenę?

Wstępna rozmowa i przedział cenowy mogą być bezpłatne. Osobnym produktem jest analiza, która tworzy zakres, architekturę lub plan możliwy do wykorzystania niezależnie od wykonawcy. U nas rozmowa i wycena są bezpłatne, płatne jest discovery.

Jak porównywać oferty, które różnią się kilkukrotnie?

Najpierw po zakresie, założeniach i odpowiedzialności, dopiero potem po cenie. Rozstrzał często wynika z innego rozumienia tych samych słów oraz z tego, czy oferta obejmuje doprowadzenie na produkcję. Rozbieramy to w ile kosztuje aplikacja webowa.

Co, jeśli mam już wykonawcę i coś nie działa?

Zacznij od trzech rzeczy: gdzie jest repozytorium, na czyich kontach są dostępy i co konkretnie jest wdrożone na produkcji. Odpowiedzi na te pytania określają, jakie masz realne opcje.

---

Przed startem projektu poproś o jawny skład, odpowiedzialność za przegląd kodu i warunki przekazania. Zobacz nasz proces, stack i aplikacje budowane od zera, albo zadaj nam te dwanaście pytań.