# Software house nie dowozi projektu – co zrobić krok po kroku?

Autor: Michał Molenda  
Data: 2026-08-27 10:34:10

[Oryginalny artykuł](https://michalmolenda.pl/blog/software-house-nie-dowozi-projektu)

Czy masz problem z realizacją projektu przez software house? Sprawdź praktyczne porady, które pomogą Ci rozwiązać te trudności. Przeczytaj artykuł!

Zleciłeś budowę aplikacji, zapłaciłeś za kilka sprintów, a zamiast działającego produktu masz serię wymówek i przesuwany harmonogram? Opóźnienia w IT to częsty problem – statystyki są bezlitosne: 80% projektów IT nie przetrwa dłużej niż kilka miesięcy. Ale to nie znaczy, że Twój projekt musi skończyć tak samo. Poniżej znajdziesz konkretną ścieżkę działania - od pierwszych kroków ratunkowych po wybór nowego partnera technologicznego.

## Na skróty: co zrobić, gdy software house nie dowozi – 5 pierwszych ruchów

Wyobraź sobie sytuację z 2024 roku: startup B2B zamówił marketplace z integracją płatności. Software house obiecał MVP w cztery miesiące. Minęło osiem, a klient ma niedziałający frontend, brak środowiska testowego i zerową dokumentację. Budżet przepalony w 70%, a produkt nie nadaje się do pokazania pierwszym użytkownikom. Stres i frustracja rosną z każdym tygodniem.

W przypadku opóźnienia kluczowe jest zachowanie spokoju i podjęcie ustrukturyzowanych działań. Oto pięć ruchów, od których warto zacząć:

- **Zbierz fakty i dowody** - maile, wiadomości na Slacku, historię zadań w Jira, umowę, ofertę, roadmapę. Wszystko, co dokumentuje obietnice i faktyczny stan realizacji projektu.
- **Wyślij oficjalny, eskalujący e-mail** - opisz konkretne opóźnienia, brakujące funkcjonalności i oczekiwania. Formalne wezwanie do wykonania umowy powinno być pisemne.
- **Zażądaj planu naprawczego** - z datami, zakresem i osobami odpowiedzialnymi za poszczególne zadania.
- **Skonsultuj się z prawnikiem lub niezależnym CTO** - konsultacja z prawnikiem jest zalecana przed odstąpieniem od umowy, a fractional CTO pomoże ocenić stan techniczny.
- **Przygotuj plan B** - niezależny audyt kodu i wstępna rozmowa z potencjalnym nowym wykonawcą.

Poniżej rozwijam każdy z tych kroków szczegółowo.

## Diagnoza: czy software house faktycznie „nie dowozi", czy to tylko przesunięcia?

Zanim podejmiesz radykalne decyzje, musisz odpowiedzieć na kluczowe pytanie: czy masz do czynienia z realnym niedowożeniem, czy raczej z opóźnieniami wynikającymi z naturalnego scope creep i zmieniających się wymagań? Ciągła komunikacja jest kluczowa przez cały proces współpracy - jej brak często powoduje, że drobne przesunięcia eskalują w poważne problemy.

Pamiętaj: dwa na sto projektów IT przetrwają dłużej niż kilka miesięcy. To znaczy, że nawet „normalne" opóźnienia mogą być symptomem głębszych problemów.

Kryteria twardych problemów:

- Brak działających funkcjonalności mimo rozliczonych sprintów
- Niewywiązanie się z kamieni milowych zapisanych w umowie
- Brak demo, środowiska testowego lub wersji do akceptacji
- Brak regularnych raportów statusu i monitorowanie postępów jest niemożliwe

Kryteria miękkie, ale równie niepokojące:

- Wysoka rotacja programistów w zespole (szczególnie seniorów)
- Brak odpowiedzi na maile przez wiele dni
- Ciągłe wymówki bez konkretnego planu naprawczego
- Brak osoby decyzyjnej po stronie software house

Dobrą praktyką jest porównanie pierwotnej roadmapy (np. harmonogram z marca 2024) z faktycznymi funkcjami dostępnymi w sierpniu 2024. Sporządź krótki „raport sytuacyjny" po stronie klienta - 1–2 strony opisujące, co obiecano, co dostarczono, ile było sprintów, bugów i opóźnień. Dokumentacja opóźnienia jest kluczowa w przypadku sporów dotyczących dostarczenia projektu.

## Sprawdź umowę: jakie masz prawa, terminy i zabezpieczenia?

Zanim podejmiesz emocjonalną decyzję, wróć do [umowy z software house'em](https://michalmolenda.pl/blog/umowa-z-software-house) - to ona określa Twoje pole manewru. Ważne jest dokładne przeanalizowanie umowy i ustaleń projektowych. Oto co konkretnie sprawdzić:

- **Definicja zakresu prac i rezultatów** - czy jest opisane minimum viable product? Czy załączono specyfikację funkcjonalną, makiety, dokument analityczny? Brak specyfikacji utrudnia wycenę projektu IT i późniejsze dochodzenie roszczeń.
- **Harmonogram** - terminy etapów, release'ów, sprintów. Umowa powinna zawierać terminy, kamienie milowe oraz zasady odbioru prac.
- **Model rozliczeń** - Time & Material vs fixed price. Przy fixed price sprawdź, czy płatności zależą od postępu prac i akceptacji przez klienta.
- **Postanowienia o opóźnieniach** - w umowach mogą być przewidziane [kary umowne](https://kordeckipartners.com/en/insights/saas-contracts-key-clauses-for-polish-market-4/) za każdy dzień opóźnienia. Sprawdź, jakie warunki muszą być spełnione, by je naliczyć.
- **Prawa autorskie i własność kodu** - kto jest właścicielem oprogramowania? Kiedy następuje przeniesienie praw majątkowych? Czy masz dostęp do repozytorium?
- **Procedury odstąpienia lub wypowiedzenia** - możliwość [odstąpienia od umowy](https://creativa.legal/wp-content/uploads/2023/02/EBOOK-CREATIVA-SAAS-2023-1.pdf) może być przewidziana w umowie lub na mocy prawa cywilnego.

Zwróć uwagę na to, czy mowa jest o umowie o dzieło (obowiązek rezultatu) czy o świadczenie usług (obowiązek starannego działania) - ma to kluczowe znaczenie dla zakresu odpowiedzialności wykonawcy. Brak specyfikacji utrudnia wycenę projektów IT, dlatego sprawdź, czy zakres w umowie jest wystarczająco precyzyjny.

Przygotuj listę pytań do prawnika na podstawie zapisów umowy, zamiast wysyłać cały dokument bez kontekstu. Dokumentacja wszystkich ustaleń pomiędzy stronami powinna być przechowywana na piśmie.

## Uporządkowana eskalacja: jak rozmawiać z software house'em, zanim „pójdziesz na wojnę"

Pierwszym krokiem po diagnozie powinien być uporządkowany proces współpracy i eskalacji - nie od razu wypowiedzenie umowy. Sprawne zarządzanie projektem wymaga indywidualnego podejścia, ale schemat eskalacji jest uniwersalny:

- Przygotuj „status memo" z twojej strony - konkretne daty, ustalenia, log rozmów, lista niewywiązanych zobowiązań.
- Zwołaj regularne spotkania statusowe z udziałem PM, tech leada i osoby decyzyjnej po stronie software house'u.
- Przedstaw różnicę między planem realizacji projektu IT a aktualnym stanem - konkretne funkcje, daty, bugi, brakujące elementy.
- Zażądaj pisemnego planu naprawczego na najbliższe 4–6 tygodni z datami, zakresem i odpowiedzialnymi osobami.
- Ustal nowe, mierzalne KPI - liczba zakończonych zadań w sprintach, czas reakcji na zgłoszenia krytyczne, termin wydania MVP.

Po każdym spotkaniu wyślij podsumowanie ustaleń e-mailem z datą, zakresem i terminem odpowiedzi. To później przydaje się jako dowód w ewentualnym sporze.

W przypadku braku poprawy, możliwe jest rozwiązanie współpracy z wykonawcą. Brak reakcji lub nieprzestrzeganie planu naprawczego to wyraźny sygnał, by przygotować transfer projektu do innego partnera technologicznego.

## Bezpieczeństwo projektu: dostęp do kodu, środowisk i wiedzy (zanim będzie za późno)

W 2023 roku klient firmy technologicznej nie miał dostępu administracyjnego do repozytorium. Po rozstaniu z software house'em został dosłownie bez kodu, dokumentacji i możliwości dalszego rozwoju aplikacji. Zabezpieczenie dostępu do kodu źródłowego i dokumentacji jest niezwykle ważne przed zakończeniem współpracy.

Elementy, które trzeba jak najszybciej zabezpieczyć:

- **Własność intelektualna** - upewnij się, że masz przeniesienie praw majątkowych do kodu tworzonych w ramach twojego projektu.
- **Dostęp administracyjny** - repozytorium (GitHub / GitLab / Azure DevOps), system zadań (Jira, Asana), środowiska: produkcja, staging, test.
- **Infrastruktura** - kopie konfiguracji (Terraform, Ansible), dostępy do chmury (AWS, GCP, Azure), klucze API, ustawienia CI/CD.
- **Dokumentacja** - architektura systemu, diagramy, integracje, kluczowe procesy biznesowe zaimplementowane w aplikacji, instrukcje wdrożenia.

Koszty wdrożenia mogą wzrosnąć przez brak dokumentacji - czasem nawet dwu- lub trzykrotnie. W razie napiętej relacji formalnie poproś software house o przekazanie pełnych dostępów i dokumentacji w określonym terminie (np. 7 dni), powołując się na zapisy umowy.

Brak kontroli nad tymi elementami znacznie utrudnia zmianę dostawcy i może realnie zablokować dalszy rozwój twojego projektu IT.

## Audyt techniczno-biznesowy: sprawdź stan projektu przed podjęciem radykalnych decyzji

Audyt twojego projektu IT to obiektywna ocena kodu, architektury, jakości realizacji projektu oraz zgodności z celami biznesowymi ustalonymi na starcie. Niezależny audyt techniczny może pomóc ocenić stan projektu i jakość kodu - zanim podejmiesz decyzję o dalszych krokach.

Co powinien obejmować audyt:

- **Przegląd repozytorium** - struktura kodu, standardy, dług techniczny. Testowanie oprogramowania obejmuje różne metody, w tym testy jednostkowe - sprawdź, czy w ogóle istnieją.
- **Ocena architektury** - skalowalność, bezpieczeństwo, koszty utrzymania w chmurze. TCO, czyli całkowity koszt posiadania projektu IT, potrafi zaskoczyć.
- **Porównanie zakresu** - realny stan funkcjonalności vs pierwotna roadmapa i zakres [MVP](https://michalmolenda.pl/blog/mvp-czyli-jak-zweryfikowac-swoje-zalozenia).
- **Analiza ryzyk** - zależności od konkretnych osób, użyte niszowe technologie, brak testów, brak monitoringu.
- **Ocena sensowności kontynuacji** - czy obecny software house ma potencjał, czy lepiej myśleć o przejęciu projektu przez inny zespół.

Przejęcie projektu wymaga 20–25 godzin analizy kodu, a koszty przejęcia projektu zależą od stanu technicznego systemu. Audyt może przeprowadzić niezależny ekspert (np. fractional CTO) lub potencjalny nowy partner technologiczny - jak Michał Molenda / Code Apps - w ramach tzw. audytu zerowego.

Efektem audytu powinien być raport z rekomendacją: „kontynuować z poprawkami", „zmienić model współpracy" lub „zaplanować uporządkowane przejęcie projektu".

## Plan naprawczy: jak uratować współpracę i dowieźć MVP zamiast zaczynać od zera

Nie zawsze trzeba zrywać współpracę. Dobry software house dostarcza spersonalizowane rozwiązania dostosowane do potrzeb klienta - czasem wystarczy reset oczekiwań i sprawne zarządzanie. Na sto projektów dwa mają szansę na dłuższe funkcjonowanie, więc warto walczyć o swój.

Elementy dobrego planu naprawczego:

- **Redefinicja zakresu** na najbliższe 6–8 tygodni: skupienie na wydaniu minimum viable product zamiast pełnej wizji z prezentacji sprzedażowej. Proces współpracy zaczyna się od analizy potrzeb klienta - nawet na tym etapie.
- **Jasne priorytety funkcji** - must-have vs nice-to-have, powiązane z konkretnymi celami biznesowymi (np. możliwość przyjmowania pierwszych płatności do 30.11.2024). W fazie projektowania powstaje makieta aplikacji - jeśli jej nie było, pora ją nadrobić.
- **Doprecyzowany proces** - częstotliwość statusów, cotygodniowe demo, forma raportów (np. tygodniowy raport w poniedziałek do 10:00), monitorowanie postępów w czasie rzeczywistym.
- **Mierniki jakości** - liczba krytycznych błędów, pokrycie testów, czas reakcji na zgłoszenia.
- **Zmiana składu zespołu** - dołożenie seniora, zmiana PM, wzmocnienie kompetencji po stronie pracowników software house'u.

Plan warto spisać jako aneks do umowy lub oficjalny „Project Recovery Plan" zaakceptowany przez obie strony. Jeśli w ciągu 2–3 sprintów nie widać poprawy, wracasz do scenariusza zmiany wykonawcy.

## Gdy trzeba się rozstać: zakończenie umowy i przygotowanie transferu projektu

Decyzja o rozstaniu z software house'em to decyzja biznesowa, nie osobista porażka. Praca nad starymi systemami często wiąże się z dużymi kosztami, ale kontrolowany transfer jest zawsze tańszy niż chaotyczny.

Aspekty formalne:

- Wybór trybu zakończenia - wypowiedzenie vs odstąpienie, zależnie od typu umowy i konsultacji z prawnikiem.
- Dotrzymanie okresów wypowiedzenia zapisanych w umowie.
- Rozliczenie etapów prac na podstawie rzeczywiście dostarczonych rezultatów - demo, wdrożone funkcje, dokumentacja. Wdrożenie oprogramowania zapewnia integrację z istniejącymi systemami klienta - rozlicz tylko to, co faktycznie działa.

Aspekty praktyczne „exit planu":

- Stworzenie listy zasobów do przejęcia: kody źródłowe, dokumentacja, dostępy, klucze API, konta w usługach zewnętrznych.
- Ustalenie, kto i w jakich datach (np. w ciągu 14 dni) ma przekazać wiedzę techniczną nowemu zespołowi.
- Zaplanowanie krótkiego okresu „nakładania się" starego i nowego dostawcy - np. 2 tygodnie wspólnych calli technicznych.
- Spisanie protokołu zdawczo-odbiorczego projektu IT na zakończenie współpracy.

Unikaj palenia mostów - kulturalny, ale stanowczy ton komunikacji. Rozlicz zobowiązania, jasno określ oczekiwania co do wsparcia w transferze.

## Wybór nowego partnera: jak uniknąć powtórki i dobrze zaplanować realizację projektu IT

Po złym doświadczeniu łatwo popaść w skrajność - wybrać tylko po cenie albo „z polecenia bez weryfikacji". Wybór software house może zająć kilka tygodni, ale tym razem warto podejść metodycznie. Klienci często obawiają się ujawnienia swoich pomysłów - dobry software house rozumie to i oferuje kompleksową obsługę z zachowaniem poufności.

Kryteria wyboru:

- **Doświadczenie w podobnych projektach** - portfolio software house powinno zawierać zróżnicowane projekty z branży IT (SaaS, marketplace, aplikację mobilną, system wewnętrzny).
- **Umiejętność przejmowania istniejących systemów** - audyt zerowy, plan przejęcia, radzenie sobie z długiem technicznym.
- **Transparentny proces współpracy** - discovery, warsztaty, regularne demo, raportowanie, praca na wspólnych narzędziach. Dobry software house jest w stanie dostosować się do indywidualnych potrzeb.
- **Nacisk na potrzeby biznesowe** - software house powinien umieć przełożyć wymagania biznesowe na roadmapę produktu i pomóc w osiągnięciu product-market fit.
- **Elastyczność** - gotowość do startu od MVP i stopniowego skalowania zamiast od razu wersji enterprise.

Software house oferuje tworzenie aplikacji mobilnych i webowych, a usługi obejmują również automatyzację procesów biznesowych. Zwróć uwagę na to, czy technologie używane przez software house wpływają korzystnie na koszty i rozwój systemu w dłuższej perspektywie. Software house powinien dostarczyć pełną [wycenę po analizie projektu](https://michalmolenda.pl/blog/wycena-prac-programistycznych).

Przed podpisaniem umowy poproś o przykładowy plan realizacji projektu na 3 miesiące, propozycję zakresu MVP i wstępne ryzyka z rekomendacjami technologicznymi.

## Jak ułożyć nową współpracę, żeby projekt nie utknął ponownie?

Zmiana dostawcy to tylko połowa sukcesu. Współpraca z software house zwiększa efektywność biznesową, ale wymaga zdrowego procesu i klarownych zasad. Software house zapewnia wsparcie techniczne na każdym etapie projektu - pod warunkiem, że obie strony grają fair.

Kluczowe elementy dobrze ustawionego procesu:

- **Warsztaty startowe (Discovery)** - jasne zdefiniowanie celów biznesowych klienta, grup użytkowników i KPI przed wyborem stacku technologicznego. Aktywny udział po twojej stronie jest niezwykle ważne.
- **Realistyczna roadmapa** - najpierw MVP, potem kolejne releasy zgodne z priorytetami biznesowymi i założenia dopasowane do rynku.
- **Zaangażowanie klienta** - kto decyduje o priorytetach, jak często bierzesz udział w przeglądach sprintów, jak szybko odpowiadasz na pytania w backlogu.
- **Przejrzystość budżetu** - regularne raporty kosztowe, porównanie wyceny projektu do rzeczywistych wydatków, świadome decyzje o rozszerzeniu zakresu w każdym czasie.
- **Dokumentacja i IP od pierwszego dnia** - repozytoria, dostęp, opisy architektury aktualizowane na bieżąco. Stworzenie tej bazy na wczesnym etapie oszczędza koszty w przyszłości.

Jako [zewnętrzny dział IT](https://michalmolenda.pl/blog/zewnetrzny-dzial-it) lub fractional CTO, Code Apps może pilnować jakości zarządzania projektem z Twojej strony - nawet jeśli stworzenie kodu realizuje inny software house. To zwrócenie uwagi na proces, nie tylko na technologie, robi różnicę między projektem, który dowiezie produkt, a kolejnym, który utknie.

## Podsumowanie: jak zamienić kryzys projektu IT w impuls do zbudowania lepszego produktu

Od diagnozy, przez zabezpieczenie zasobów, audyt, plan naprawczy, po ewentualną zmianę wykonawcy i lepsze ułożenie procesu - każdy krok ma znaczenie. Nawet jeśli pierwszy software house nie dowiózł projektu, nie oznacza to, że Twój pomysł lub cele biznesowe są złe. Często problem leży w procesie, komunikacji lub niedoszacowanym MVP. Jak [uczy doświadczenie](https://michalmolenda.pl/blog/czego-nauczylem-sie-tworzac-wlasne-startupy) - porażka projektu to nie koniec drogi, lecz szansa na lepsze założenia.

Potraktuj sytuację jako okazję do uporządkowania strategii rozwoju produktu, budżetu i sposobu pracy nad kolejnymi wersjami systemu. Pozyskiwanie nowych klientów dla Twojego biznesu zależy od tego, czy dostarczysz im działający produkt - a nie od tego, ile sprintów rozliczył poprzedni wykonawca.

Jeśli potrzebujesz audytu istniejącego projektu, chcesz zaplanować minimum viable product albo szukasz wsparcia fractional CTO przy dalszej realizacji projektu IT - **napisz do mnie**. Jako Michał Molenda / Code Apps pomagam firmom wyjść z impasu technologicznego i zbudować produkt, który naprawdę trafia na rynek.