# Kiedy wykonawca odradza własny zakres > Oddaliśmy około jednej piątej zakresu zewnętrznemu dostawcy, bo własny rdzeń zjadłby harmonogram przed walidacją hipotezy. Dwa przypadki z projektów MVP. - **Adres kanoniczny:** https://appwave.dev/pl/blog/kiedy-wykonawca-odradza-wlasny-zakres - **Język:** pl - **Aktualizacja:** 2026-08-20 --- - **Publikacja:** 2026-08-20 - **Autor:** Jakub Dulas - Co-Founder, Backend Developer - **LinkedIn:** https://www.linkedin.com/in/jakubdulas/ - **Czas czytania (min):** 5 - **Tematy:** MVP, Wybór dostawcy, Ryzyko ![Ciągła biała sinusoida na czarnym tle, której jeden odcinek przechodzi na cieńszą równoległą linię i wraca do głównego przebiegu.](https://cms.appwave.dev/uploads/kiedy_wykonawca_odradza_wlasny_zakres_1cfb68710e.webp) W jednym z projektów odradziliśmy klientowi budowę rdzenia systemu u nas i oddaliśmy około jednej piątej zakresu zewnętrznemu dostawcy. Powód nie był uprzejmy: przy terminie 63 dni roboczych własny rdzeń zjadłby harmonogram, zanim ktokolwiek sprawdziłby, czy produkt jest komuś potrzebny. To nie jest nasza reguła, tylko sytuacja, w której tak robimy. Rynek dostawców AI odpowiada dziś na pytanie „czy dowieziecie” jednym słowem i wszyscy mówią to samo słowo. Zdanie nic nie kosztuje, więc nic nie znaczy. Kosztuje natomiast rekomendacja, po której zarabiasz mniej, i to jest jedyny rodzaj dowodu, którego konkurent nie przepisze z twojej strony. Poniżej dwa przypadki z naszych projektów. W pierwszym zmniejszyliśmy własny zakres. W drugim dołożyliśmy pracę, za którą klient nie zapłacił. Opisujemy sam mechanizm, bez nazw projektów i bez nazwy dostawcy, bo taka jest granica ustalona z klientami. ## Co dokładnie oddaliśmy i komu Klient chciał agenta głosowego jako w pełni własny, niezależny komponent. Nie dodatek do systemu, tylko jego rdzeń, docelowo bez zależności od kogokolwiek z zewnątrz. Zamówienie było jasne i moglibyśmy je przyjąć w całości. Odradziliśmy budowanie silnika agenta głosowego od zera u nas. Zaproponowaliśmy rdzeń oparty o sprawdzonego zewnętrznego dostawcę, a resztę systemu, czyli logikę, integracje, panel i dane, u nas. Zakres, który mógł być nasz, poszedł do kogoś innego z naszej rekomendacji. Klient nie zrezygnował z niezależności. Przesunął ją w czasie: własny komponent buduje się po walidacji, a nie przed nią. Dziś system działa na zewnętrznym dostawcy, a decyzja o własnym rdzeniu czeka na moment, w którym będzie wiadomo, że jest za co ją podejmować. ## Dlaczego rdzeń przed walidacją jest złym zakupem Solidnie przetestowany rdzeń to kilka tygodni pracy. Nie działające demo, tylko komponent, któremu można powierzyć rozmowę z prawdziwym klientem. W projekcie z terminem 63 dni roboczych te kilka tygodni zabiera znaczną część harmonogramu i zabiera ją na początku, czyli wtedy, gdy nikt jeszcze nie wie, czy produkt w tej formie kogokolwiek interesuje. Drugi powód był poważniejszy od czasu i to on przeważył w rozmowie. Własny agent głosowy to nasza odpowiedzialność za każdy błąd w rozmowie z użytkownikiem. Przy hipotezie biznesowej, której nikt jeszcze nie potwierdził, klient brałby na siebie ryzyko techniczne komponentu, którego wartości nie zna. Zewnętrzny dostawca robi warstwę głosową jako swój główny produkt, więc to ryzyko leży u niego. Czas był trzeci, nie pierwszy. Kolejność ma znaczenie, bo argument z terminem brzmi jak wymówka wykonawcy, a argument z ryzykiem opisuje, co się stanie z pieniędzmi klienta. ## Drugi raz poszło w przeciwną stronę W innym projekcie klient przyszedł z zakresem, w którym nie było mechanizmu zarządzania zgodami RODO. Nie z niedbałości. Przy planowaniu pierwszej wersji produktu myśli się o funkcjach, a nie o tym, co jest potrzebne, żeby te funkcje legalnie udostępnić. Dorzuciliśmy moduł zgód z własnych zasobów: wersjonowanie i potwierdzanie zgód. Nie było go w wycenie i klient za niego nie zapłacił. Kosztowało nas to kilka dni pracy, obniżonych przez kod wielokrotnego użytku z wcześniejszych projektów tego typu. Bez tego modułu problem nie ujawniłby się od razu. Ujawniłby się w najgorszym możliwym momencie, czyli po walidacji w zamkniętej becie, przy przejściu do szerszego grona użytkowników. Zamiast skalować produkt o potwierdzonej wartości, klient musiałby się zatrzymać i dobudować warstwę, o której nikt nie pomyślał na starcie. ## Ile nas kosztowały obie decyzje Pierwsza kosztowała około jednej piątej projektu. To nie było peryferium ani miła drobnostka do oddania, tylko rdzeń systemu, czyli ta część, którą wykonawca zwykle chce zatrzymać najbardziej. Druga kosztowała kilka dni pracy poza zakresem. Mniej, ale też realnie: to były godziny, za które nikt nam nie zapłacił, wykonane dlatego, że bez nich produkt nie nadawał się do uruchomienia. Piszemy o tym, bo bez liczby cała ta historia jest opowieścią o tym, jacy jesteśmy mili. Jedna piąta projektu to konkretna dziura w fakturze. Jeśli ktoś czyta ten tekst jako materiał sprzedażowy, to jest moment, w którym powinien się zatrzymać i zapytać, czy takiej rekomendacji nie wydaje się przypadkiem po to, żeby wyglądać na uczciwego. Odpowiedź brzmi: sprawdź to na małym płatnym etapie, zanim podpiszesz duży. ## Czym to się różni od zapewnienia, że dowieziemy Obietnica jest darmowa i dlatego wszyscy jej używają. Dowód kosztuje, więc pojawia się rzadziej i daje się sprawdzić. Mechanizm, który za tym stoi, brzmi u nas prosto: termin jest stały, zakres negocjujemy. Dopóki negocjacja idzie w stronę powiększania zakresu, to zdanie jest sloganem korzystnym dla nas. Znaczenie dostaje dopiero wtedy, gdy negocjacja idzie w drugą stronę i kończy się mniejszą fakturą. Jeśli szukasz sposobu, żeby to sprawdzić u kogokolwiek, a nie tylko u nas, zacznij od pytań, które zadaje kupujący, a nie od portfolio. Zebraliśmy je osobno w tekście o [siedmiu pytaniach do software house'u](https://appwave.dev/pl/blog/jak-wybrac-software-house-siedem-pytan). Tam jest lista. Tutaj jest dowód, że odpowiedzi na nią czasem działają przeciwko odpowiadającemu. ## Kiedy tego nie robimy Nie odradzamy zakresu za każdym razem. Odradzamy wtedy, gdy widzimy dwie rzeczy naraz: komponent zjada harmonogram przed walidacją, a jego wartość nie jest jeszcze potwierdzona. Przy potwierdzonej hipotezie i przy produkcie, który już ma użytkowników, budowanie własnego rdzenia bywa dokładnie tym, co trzeba zrobić. Nie dorzucamy też pracy poza zakresem jako gestu. Dorzucamy wtedy, gdy bez niej produkt nie nadaje się do uruchomienia, a my wiemy o tym wcześniej niż klient, bo widzieliśmy to już w poprzednich projektach. To jest różnica między prezentem a naprawieniem czegoś, co i tak trzeba naprawić. ## Zanim napiszesz Nie obiecujemy, że w każdym projekcie znajdziemy zakres do oddania. W większości nie ma czego oddawać i cała praca zostaje u nas. Nie prowadzimy też projektów, w których zakres jest zamknięty przed pierwszą rozmową o ryzyku, bo wtedy nie mamy jak zaproponować zmiany, która się opłaca klientowi. Jeśli budujesz pierwszą wersję produktu i chcesz sprawdzić, jak wygląda rozmowa o zakresie, zanim podpiszesz umowę: [zobacz, co obejmuje MVP z AI](https://appwave.dev/pl/services/mvp-ai). Cena i termin są tam podane wprost. ## Pytania i odpowiedzi (FAQ) ### Skąd mam wiedzieć, że wykonawca nie zaniża zakresu tylko po to, żeby wygrać cenę? Po tym, czego dotyczy zaniżenie. Rezygnacja z peryferium obniża cenę i nie zmienia ryzyka, a rezygnacja z rdzenia zmienia oba naraz. Poproś o wskazanie, która część zakresu jest krytyczna dla działania produktu, i sprawdź, czy proponowane cięcie jej dotyczy. ### Czy oddanie części zakresu na zewnątrz nie znaczy, że nie umiecie tego zbudować? Umiemy i klient planuje to zbudować, tylko po walidacji. Pytanie nie brzmi, czy da się zbudować własny rdzeń, tylko kiedy się to opłaca. Naszym zdaniem po tym, jak ktoś potwierdzi, że produkt jest potrzebny w tej formie, a nie przed. ### Co, jeśli chcę mieć wszystko własne od pierwszego dnia? Wtedy to robimy i mówimy, ile to kosztuje w czasie. Własny rdzeń przesuwa moment, w którym produkt trafia do użytkowników, i przenosi odpowiedzialność za jego jakość na nas. Obie rzeczy da się wycenić przed startem, żeby decyzja była twoja, a nie nasza. ### Ile kosztuje pierwsza wersja produktu i ile trwa? Dedykowane oprogramowanie wyceniamy jednorazowo, od 35 000 zł netto, w 63 dni robocze liczone od podpisania zakresu. Widełki zależą od liczby integracji i od tego, czy w zakresie jest warstwa, której nie da się przyspieszyć budżetem. --- ## O AppWave AI software house z Łodzi. Budujemy dedykowane oprogramowanie AI, agentów do automatyzacji i aplikacje webowe. Współtworzymy je z klientem i dajemy gwarancję na każdy dostarczony system. - **Nazwa prawna:** AppWave sp. z o.o. - **Adres:** ul. Kolumny 147E/1, 93-611 Łódź, Polska - **Telefon:** +48 538 441 413 - **E-mail:** office@appwave.dev - **Godziny pracy:** poniedziałek-piątek, 09:00-17:00 - [Bezpłatna konsultacja](https://appwave.dev/pl/appointment)