Jak wybrać software house do transformacji cyfrowej - przewodnik dla właściciela firmy

Podjąłeś decyzję: stary system musi odejść. Excel, Access, aplikacja z 2008 roku w Delphi - cokolwiek to jest, wiesz, że hamuje firmę. Szukasz kogoś, kto to naprawi. Wpisujesz w Google "software house Polska", dostajesz 200 wyników. Każdy "lider rynku", każdy "doświadczony zespół", każdy "najnowsze technologie".

Jak odróżnić firmę, która zbuduje system na lata, od firmy, która weźmie pieniądze i zostawi Cię z czymś gorszym niż to, co masz teraz?

Ten artykuł jest dla właścicieli firm i managerów, którzy nie są programistami, ale muszą podjąć decyzję wartą setki tysięcy złotych. Bez żargonu, bez marketingowych bzdur. Konkretne pytania, konkretne czerwone flagi, konkretne kryteria.

Zanim zaczniesz szukać - zrób pracę domową

Zdefiniuj problem, nie rozwiązanie

Najczęstszy błąd: "Chcemy aplikację mobilną" albo "Chcemy system w React". To nie jest problem - to rozwiązanie, które ktoś Ci zasugerował. Problem brzmi:

• "Nasi handlowcy tracą 2 godziny dziennie na przepisywanie zamówień"
• "Nie wiemy ile mamy towaru w magazynie, bo dane w systemie nie zgadzają się z rzeczywistością"
• "Nie możemy sprzedawać online, bo nasz system nie ma API"
• "Generowanie raportu trwa 20 minut i blokuje system dla reszty firmy"

Dobry software house zapyta Cię o problem i sam zaproponuje rozwiązanie. Zły weźmie Twoje "chcemy aplikację mobilną" i zbuduje aplikację mobilną, nawet jeśli Twój problem rozwiązuje prosta aplikacja webowa.

Spisz swoje procesy

Zanim porozmawiasz z kimkolwiek, spisz 5-10 kluczowych procesów w firmie:

1. Jak wchodzi zamówienie od klienta? (Telefon? Email? Formularz? Allegro?)
2. Co się dzieje z zamówieniem po wejściu? (Kto sprawdza stan? Kto potwierdza cenę?)
3. Jak wygląda wydanie z magazynu?
4. Jak powstaje faktura?
5. Jak klient dostaje informację o statusie zamówienia?

Nie muszą być idealne. Ale musisz je mieć, żeby software house wiedział, co ma zbudować. Firma, która zacznie pisać kod bez zrozumienia Twoich procesów, zbuduje system dla wyimaginowanej firmy, nie dla Twojej.

Ustal budżet (choćby orientacyjny)

"Ile kosztuje system?" to jak "ile kosztuje samochód?". Zależy od rozmiaru, funkcji, jakości. Ale musisz mieć widełki, żeby nie tracić czasu na rozmowy z firmami z innej ligi cenowej.

Orientacyjne ramy dla polskiego rynku (2026):

Jeśli ktoś oferuje pełny system ERP za 50 000 PLN - albo nie rozumie zakresu, albo planuje obciąć jakość. Jeśli ktoś wycenia prosty moduł na 300 000 PLN - przepłacasz albo dostaniesz Ferrari, gdy potrzebujesz dostawczaka.

10 pytań, które MUSISZ zadać

1. "Czy robiliście coś podobnego?"

Nie "czy robiliście aplikacje webowe" - to jak pytanie mechanika "czy naprawialiście samochody". Pytaj konkretnie:

• "Czy robiliście system zamówień / ERP / CRM?"
• "Czy migrowaliście dane z legacy systemu?"
• "Czy integrowaliście się z [konkretna platforma: Allegro, InPost, Comarch]?"

Poproś o referencje - kontakt do klienta, który pozwoli porozmawiać o współpracy. Firma, która odmówi referencji, ma coś do ukrycia. Firma, która da Ci numer telefonu do trzech swoich klientów - wie, że ci klienci powiedzą dobre rzeczy.

2. "Kto będzie pracował nad moim projektem?"

Nie "ilu macie programistów". Kto konkretnie. Jakie ma doświadczenie. Czy będzie przez cały projekt, czy zostanie podmieniony po dwóch miesiącach.

Czerwona flaga: "Przydzielimy zespół po podpisaniu umowy." To znaczy, że nie wiedzą kto to będzie. Albo że pokażą Ci seniorów na sprzedaży, a do pracy posadzą juniorów.

Zielona flaga: "Nad Twoim projektem będzie pracował Adam (8 lat doświadczenia, robił system X dla firmy Y) i Maja (5 lat, specjalizuje się w integrach). Możesz z nimi porozmawiać przed podpisaniem umowy."

3. "Co się stanie, jeśli chcę zmienić wymagania w trakcie?"

Wymagania zawsze się zmieniają. W trakcie budowy systemu odkryjesz, że potrzebujesz czegoś, o czym nie pomyślałeś. Albo użytkownicy powiedzą "to powinno działać inaczej". To normalne.

Czerwona flaga: "Musimy zamrozić wymagania przed rozpoczęciem. Każda zmiana to change request z osobną wyceną." To waterfall - model, który nie działa od 20 lat, ale firmy go nadal sprzedają, bo łatwo wycenić i trudno rozliczyć.

Zielona flaga: "Pracujemy w sprintach po 2 tygodnie. Po każdym sprincie pokazujemy Ci działający kawałek systemu. Jeśli coś chcesz zmienić - zmieniamy w następnym sprincie. Priorytet ustalamy razem."

4. "Kiedy zobaczę pierwszy działający kawałek?"

Jeśli odpowiedź brzmi "za 6 miesięcy" - uciekaj. Przez 6 miesięcy firma będzie pisać kod, który może nie mieć nic wspólnego z Twoimi potrzebami. A Ty zapłacisz za 6 miesięcy pracy, zanim zobaczysz cokolwiek.

Zielona flaga: "Za 2-4 tygodnie pokażemy Ci pierwszy moduł. Będziesz mógł go klikać, testować, zgłaszać uwagi. Po każdym sprincie (2 tygodnie) dostajesz następny kawałek."

To jest agile w praktyce: krótkie cykle, częsty feedback, korekta kursu. Nie "agile" jako marketingowe hasło - agile jako sposób pracy, który chroni Twoje pieniądze.

5. "Co dostanę na koniec?"

Nie tylko "system". Upewnij się, że kontrakt obejmuje:

• Kod źródłowy - Twoja własność. Nie "licencja na korzystanie". Kod jest Twój i możesz z nim robić, co chcesz - włącznie ze zmianą dostawcy.
• Dokumentacja techniczna - jak uruchomić system, jak wdrożyć zmiany, jak wygląda architektura.
• Instrukcja wdrożenia - jak postawić system na nowym serwerze od zera.
• Dane testowe - środowisko testowe, na którym można bezpiecznie próbować zmiany.
• Migracja danych - przeniesienie danych ze starego systemu do nowego.

Czerwona flaga: "System działa na naszej infrastrukturze. Nie udostępniamy kodu źródłowego." To jest vendor lock-in. Jeśli firma zniknie, Twój system zniknie razem z nią.

6. "Jakie technologie i dlaczego?"

Nie musisz rozumieć technologii. Ale musisz usłyszeć dlaczego firma wybrała konkretny stack. Dobra odpowiedź zawiera uzasadnienie biznesowe:

Zielona flaga: "Wybieramy Elixir/Phoenix, bo Twój system wymaga real-time aktualizacji dla 200 użytkowników jednocześnie. BEAM obsługuje to natywnie, bez dodatkowej infrastruktury. To zmniejsza koszty utrzymania."

Czerwona flaga: "Używamy React i Node.js, bo to najpopularniejsze technologie." Popularność to nie argument. Masło też jest popularne, ale nie nakręcisz nim śruby.

Pytaj też: "Czy będę mógł znaleźć innego programistę w tej technologii, jeśli nasza współpraca się skończy?" Technologia nie może być tak niszowa, że uzależnia Cię od jednego dostawcy. Ale nie musi być najpopularniejsza - musi mieć wystarczająco dużą społeczność.

7. "Jak wygląda wsparcie po wdrożeniu?"

System wdrożony to nie system skończony. Będą błędy do naprawienia, zmiany do wdrożenia, aktualizacje bezpieczeństwa.

Pytaj konkretnie:

• Jaki jest czas reakcji na zgłoszenie krytyczne? (System nie działa)
• Jaki jest czas reakcji na zgłoszenie zwykłe? (Coś nie działa jak powinno)
• Ile kosztuje godzina wsparcia po wdrożeniu?
• Czy jest umowa SLA (Service Level Agreement)?
• Kto robi aktualizacje bezpieczeństwa i jak często?

Czerwona flaga: "Wsparcie wliczone w cenę przez 3 miesiące, potem zobaczymy." Co znaczy "zobaczymy"? Że za 4 miesiące będziesz płacić 500 PLN/h za naprawienie buga, który powinien być naprawiony w ramach gwarancji?

8. "Co jeśli Wasza firma przestanie istnieć?"

Pytanie niewygodne, ale konieczne. Małe software house'y zamykają się, łączą, zmieniają profil. Co się stanie z Twoim systemem?

Zielona flaga: "Kod jest Twój od dnia zero. Dokumentacja techniczna jest na bieżąco. System stoi na Twoim serwerze (lub Twoim koncie w chmurze). Każdy programista w tej technologii może przejąć projekt."

Czerwona flaga: "System jest na naszych serwerach, kod jest naszą własnością intelektualną, licencjujemy Ci prawo do korzystania." Jeśli ta firma zniknie, Twój system zniknie z nią.

9. "Jak będziemy się komunikować?"

To pytanie o codzienny komfort współpracy:

• Jak często będziemy mieć spotkania?
• Kto jest moją osobą kontaktową?
• Jak zgłaszam błędy i zmiany?
• Czy widzę postęp prac na bieżąco?

Zielona flaga: "Spotkanie co tydzień/dwa tygodnie. Masz dostęp do tablicy zadań (Jira/Linear/Trello). Widzisz co robimy, co planujemy, co jest zablokowane. Osoba kontaktowa to [imię], odpowiada w ciągu dnia roboczego."

Czerwona flaga: "Wyślemy Ci raport na koniec miesiąca." Miesiąc bez kontaktu to miesiąc, w którym firma może iść w złym kierunku bez Twojej wiedzy.

10. "Czy możemy zacząć od czegoś małego?"

To jest test na uczciwość. Dobra firma powie: "Tak, zróbmy najpierw jeden moduł. Zobaczysz jak pracujemy, ocenisz jakość, zdecydujesz czy chcesz kontynuować."

Czerwona flaga: "Musimy podpisać kontrakt na cały system. Minimum 6 miesięcy." Dlaczego? Bo wiedzą, że po 2 miesiącach możesz ocenić ich pracę i nie być zadowolonym.

Zielona flaga: "Zróbmy 4-tygodniowy pilotaż. Jeden moduł, ustalony budżet. Jeśli Ci się spodoba - kontynuujemy. Jeśli nie - masz działający moduł i doświadczenie, które pomoże Ci wybrać innego dostawcę."

Czerwone flagi - uciekaj, gdy je zobaczysz

"Zrobimy wszystko, co chcesz"

Firma, która na wszystko mówi "tak", albo nie rozumie Twoich wymagań, albo planuje powiedzieć "nie" po podpisaniu umowy (w formie change requestów). Dobra firma mówi: "To nie jest dobry pomysł, bo... Zamiast tego proponujemy..."

Brak pytań o Twój biznes

Jeśli na pierwszym spotkaniu firma mówi głównie o sobie (technologie, certyfikaty, nagrody) i nie pyta o Twoje procesy, problemy, cele - nie zbuduje systemu dla Twojej firmy. Zbuduje system, który pasuje do ich portfolio.

Wycena bez analizy

"Ile kosztuje system ERP? 200 000 PLN." - taka odpowiedź po 30-minutowej rozmowie jest nonsensem. To jak lekarz, który przepisuje leki bez badania. Rzetelna wycena wymaga minimum kilku dni analizy.

Uczciwa odpowiedź: "Na podstawie tego, co opisujesz, widełki to 150-300k PLN. Ale żeby podać konkretną kwotę, potrzebujemy 2-3 dni na analizę Twoich procesów. Koszt analizy: X PLN, który odliczamy od projektu, jeśli zdecydujesz się na współpracę."

Brak referencji

"Nie możemy podać kontaktu do klienta z powodu NDA." Możliwe, ale mało prawdopodobne, że każdy klient ma NDA zabraniające referencji. Jeśli firma nie może pokazać ani jednego zadowolonego klienta, to nie ma zadowolonych klientów.

Zespół z CV, nie z doświadczenia

Profil na stronie: "Jan Kowalski, 10 lat doświadczenia, certyfikat AWS, certyfikat Scrum Master, certyfikat...". Certyfikaty nie budują systemów. Doświadczenie buduje systemy. Pytaj o projekty, nie o certyfikaty.

"Nasz system na pewno będzie lepszy"

Firma, która krytykuje Twój obecny system, nie widząc go, nie wie o czym mówi. Stary system, mimo wad, działa - obsługuje Twoją firmę od lat. Szacunek do istniejącego rozwiązania i zrozumienie, dlaczego jest jakie jest, to znak dojrzałości.

Zielone flagi - znaki, że trafiłeś dobrze

Pytają więcej niż mówią

Pierwsze spotkanie to 80% ich pytań, 20% ich odpowiedzi. Chcą zrozumieć Twój biznes, Twoje problemy, Twoich ludzi. Dopiero potem proponują rozwiązanie.

Mówią "nie" i wyjaśniają dlaczego

"Aplikacja mobilna natywna to przesada w Twoim przypadku - 95% Twoich użytkowników pracuje na desktopie. Responsywna aplikacja webowa da ten sam efekt za połowę budżetu." Firma, która odradza droższe rozwiązanie, ma Twój interes na uwadze.

Pokazują działający kod szybko

Demo po 2 tygodniach. Prototyp po 4 tygodniach. Nie slajdy, nie mockupy w Figmie - działający system, który możesz klikać.

Mają opinię techniczną

"Proponujemy PostgreSQL, bo..." - firma ma swój stack, zna go dobrze, potrafi uzasadnić wybór. To lepsze niż "użyjemy cokolwiek chcesz" - bo to oznacza, że nie są ekspertami w niczym.

Myślą o utrzymaniu

"System musi być łatwy do utrzymania za 5 lat, gdy my możemy nie być Twoim dostawcą." Firma, która myśli o Twojej niezależności, jest partnerem. Firma, która buduje zależność, jest dostawcą.

Transparent pricing

Wiesz ile płacisz za co. Stawka godzinowa albo fixed price za moduł. Faktury z opisem co zostało zrobione. Żadnych "opłat administracyjnych" ani "kosztów zarządzania projektem" ukrytych w fakturze.

Model współpracy: fixed price vs time & materials

Fixed price (stała cena)

"Moduł zamówień za 80 000 PLN, gotowy za 6 tygodni."

Zalety: Wiesz ile zapłacisz. Ryzyko przekroczenia budżetu po stronie wykonawcy.

Wady: Firma wkalkuluje bufor (20-40%) na niespodzianki. Zmiany wymagań = change request = dodatkowa wycena = opóźnienie. Firma ma motywację, żeby dostarczyć minimum wymagań jak najszybciej.

Kiedy wybrać: Gdy zakres jest jasno zdefiniowany i raczej się nie zmieni. Mniejsze projekty, dobrze opisane moduły.

Time & materials (czas i materiały)

"Stawka 250 PLN/h, pracujemy w sprintach po 2 tygodnie, po każdym sprincie oceniasz postęp."

Zalety: Elastyczność. Możesz zmieniać wymagania bez formalnych change requestów. Płacisz za realną pracę, nie za bufor. Firma ma motywację do jakości (bo chce długoterminowej relacji).

Wady: Nie wiesz dokładnie, ile zapłacisz na końcu. Musisz kontrolować postęp, żeby nie "przepalać" godzin.

Kiedy wybrać: Gdy zakres jest niepewny, wymagania mogą się zmieniać, projekt jest duży i złożony. Większość transformacji cyfrowych.

Hybrid (rekomendowany)

"Analiza za fixed price 15 000 PLN. Na podstawie analizy wyceniamy moduły fixed price. Zmiany i dodatkowe prace time & materials."

To daje Ci kontrolę nad budżetem (wiesz ile kosztuje każdy moduł) z elastycznością na zmiany (time & materials na modyfikacje). I weryfikujesz firmę na małej stawce (analiza), zanim zaangażujesz duży budżet.

Kontrakt - na co zwrócić uwagę

Nie musisz być prawnikiem. Ale te punkty sprawdź:

1. Własność kodu - "Wszelkie prawa majątkowe do kodu źródłowego przechodzą na Zamawiającego." Bez tego jesteś zakładnikiem.

2. Dostęp do kodu na bieżąco - nie po projekcie, nie po zapłacie. Na bieżąco, od dnia zero. Repozytorium git, do którego masz dostęp.

3. Prawo do zmiany dostawcy - "Zamawiający ma prawo zlecić dalszy rozwój systemu dowolnemu podmiotowi." Ochrona przed vendor lock-in.

4. Gwarancja - minimum 6 miesięcy na błędy w kodzie. Gwarancja oznacza: jeśli coś, co firma zbudowała, nie działa jak powinno - naprawia za darmo.

5. Kary za opóźnienia - jeśli fixed price. Motywacja do dotrzymywania terminów.

6. Klauzula wyjścia - "Każda ze stron może rozwiązać umowę z 30-dniowym wypowiedzeniem." Nie podpisuj umowy, z której nie możesz wyjść.

7. Poufność - firma nie ujawni Twoich danych biznesowych, procesów, tajemnic handlowych.

Po podpisaniu - jak kontrolować projekt

Sprint review co 2 tygodnie

Siadasz z zespołem, widzisz co zrobili, testujesz, dajesz feedback. Jeśli coś idzie w złym kierunku - wiesz po 2 tygodniach, nie po 6 miesiącach.

Dostęp do tablicy zadań

Widzisz co jest zaplanowane, co jest w toku, co jest zablokowane. Nie musisz pytać "nad czym pracujecie" - widzisz sam.

Środowisko testowe

Działająca wersja systemu, na której testujesz nowe funkcje. Nie na produkcji, nie na screenach - na żywym systemie z Twoimi danymi testowymi.

Regularne demo dla zespołu

Co miesiąc pokazuj postęp swoim ludziom - tym, którzy będą używać systemu. Ich feedback jest bezcenny i łapie problemy, których nie złapiecie Ty ani firma.

Podsumowanie: checklista wyboru

Przed podpisaniem umowy sprawdź:

• Firma pyta o Twój biznes, nie tylko o technologię
• Ma referencje od klientów, z którymi możesz porozmawiać
• Wiesz, kto konkretnie będzie pracował nad projektem
• Pierwszy działający prototyp w 2-4 tygodnie
• Kod źródłowy jest Twoją własnością od dnia zero
• Masz dostęp do repozytorium kodu na bieżąco
• Model współpracy pozwala na zmiany wymagań
• Jest plan wsparcia po wdrożeniu (SLA, stawki, czas reakcji)
• Możesz zacząć od małego pilotażu
• Firma potrafi powiedzieć "nie" i uzasadnić dlaczego
• Kontrakt zawiera klauzulę wyjścia
• Wycena jest oparta na analizie, nie na zgadywaniu

Szukasz firmy, która przeprowadzi Twoją transformację cyfrową? Porozmawiajmy - zaczynamy od bezpłatnej 30-minutowej konsultacji, w której ocenimy Twój przypadek i powiemy szczerze, czy jesteśmy właściwym partnerem. Czasem odpowiedź brzmi "nie" - i to też jest wartościowa informacja.