TL;DR · 30 SEKUND
- 62% przekroczeń budżetu IT to rozdęty zakres (PMI 2025). 50% projektów IT dotyka go w trakcie. Najczęstsza przyczyna: brak zdefiniowanego SOW przed podpisaniem.
- Siedem czerwonych flag w cennikach i umowach: cena pewna bez zakresu, własny framework (vendor lock-in), brak buforu w wycenie, etap rozpoznania z template’u, brak transferu kodu po starcie, stawka seniora przy pracy juniora, niewłaściwa klauzula IP.
- Kluczowe pytania przed podpisaniem: komu należą prawa autorskie, gdzie hostowane będą repozytoria, kto konkretnie pracuje (imiona, nie role), co jest poza zakresu, jakie są warunki rozwiązania umowy.
- Cztery sygnały, że już Cię okradają: faktury za zmiany przed pierwszym milestone’em, repozytoria na koncie agencji, brak działającego prototypu po 4 tygodniach, dokumenty rozpoznania w PowerPoint zamiast Figmie i wiążącym dokumencie zakresu.
SOW (Statement of Work) kontra umowa. Dwa różne dokumenty. Umowa to ramy prawne (kto, kiedy, ile, kary, IP, rozwiązanie). SOW to zakres pracy (co dokładnie powstaje, jakie integracje, jakie kryteria odbioru). 90% pułapek siedzi w tym, że SOW jest „orientacyjny” albo go w ogóle nie ma. Bez SOW każda zmiana w trakcie projektu to dodatkowa faktura.
Założyciel siada do faktury po sześciu miesiącach projektu. Podstawowa kwota umowy: 80 tysięcy PLN. Faktura miesięczna: kolejne 12 tysięcy za „rzeczy poza zakresu”. Sumarycznie projekt kosztował już 140 tysięcy. Kod jest dostarczony, ale dokumentacja to README z trzema linijkami. Hosting na koncie agencji, klucze API w ich password managerze. Założyciel wysyła email z prośbą o transfer. Agencja odpisuje, że transfer kosztuje dodatkowe 8 tysięcy.
Znasz to uczucie. Niedowierzanie, frustracja, bezradność. Bo umowa wyglądała standardowo, dostawca wyglądał profesjonalnie, oferta brzmiała uczciwie. A teraz patrzysz na fakturę i nie wiesz, kiedy podpisałeś się pod tym, że transfer Twojego własnego kodu kosztuje ekstra.
Trzech klientów w 12 miesięcy
Brzmi przesadnie? To opis trzech klientów, którzy przyszli do nas w ciągu ostatnich 12 miesięcy. Każdy z nich zapłacił już za pierwszą wersję u kogoś innego, w przekonaniu, że umowa którą podpisał była „standardowa”. Wszyscy się mylili.
Kto naprawdę Cię zdziera
Software house Cię nie zdziera. Ty podpisujesz umowę, w której on Cię może zedrzeć później. Różnica jest w tym, jaką umowę przeczytasz przed podpisaniem.
Klauzule, które wyglądają jak standard, a nim nie są
Najgorsze klauzule nie są napisane fontem 6 w nocie prawnej. Są napisane fontem 12, wyglądają jak standard branżowy i pojawiają się w 80% kontraktów IT. Nie są standardem. Są mapą pola minowego rozłożoną na 12 miesięcy projektu. Każda klauzula to mina, która wybucha w innym miesiącu, jeśli jej nie zauważysz przed podpisaniem.
Co dostajesz w tym artykule
Wdrażaliśmy konfiguratory i panele klienta dla kilkudziesięciu firm B2B w Polsce. Większość przyszła do nas po pierwszej, nieudanej współpracy. Mamy mapę miejsc, w których ich poprzednia agencja ich okradła. Te miejsca są przewidywalne i powtarzalne. Można je rozpoznać w ofercie, można je rozpoznać w umowie.
Tekst pokazuje 7 czerwonych flag w cennikach i umowach z software house plus 5 pytań, które trzeba zadać każdemu dostawcy zanim podpiszesz, plus 4 sygnały że projekt jest już w trakcie obsuwy (jeśli umowa jest podpisana, ale jeszcze nie za późno żeby przerwać).
|
Po pierwszej nieudanej współpracy? 30 minut rozmowy diagnostycznej. Przegadamy Twoją obecną umowę i listę pytań do następnego dostawcy. Bez slajdów, bez pitchu. |
Wypełnij formularz |
Czemu te 7 flag łatwo przegapić w ofercie?
Bo wszystkie wyglądają jak standard branżowy. Sprzedawca powie „tak robimy zawsze”, a Ty pomyślisz „skoro robią zawsze, to musi być OK”. Realnie standard branżowy w Polsce jest na korzyść agencji, nie klienta. To nie jest spisek, to jest konsekwencja tego, że agencje mają więcej projektów niż klienci, więc dyktują warunki. Podobny mechanizm występuje przy wdrożeniach CRM, gdzie 70% nieudanych wdrożeń pada przez brak akceptacji użytkowników . opisaliśmy to w osobnym artykule dlaczego wdrożenie CRM się nie udaje.
Druga rzecz: większość klauzul które Cię zaboli za 6 miesięcy, brzmi neutralnie przy podpisywaniu. „IP ownership remains with contractor until full payment” wygląda jak kwestia formalna. Realnie znaczy, że dostawca ma prawa do kodu i może go odsprzedać. „Scope changes will be billed separately” wygląda jak fair play. Realnie znaczy, że każda zmiana w produkcie, którą uznajesz za doprecyzowanie, dla agencji jest dodatkową fakturą.
Trzecia rzecz: presja czasu. Agencja Ci mówi „decyzja musi być w tym tygodniu, zespół rezerwujemy”. Klient nie ma czasu na drugiego prawnika, drugą opinię, due diligence. Podpisuje pod wpływem urgency. Sztucznie podtrzymywana presja czasu to sama w sobie czerwona flaga, ale o niej dziś nie piszemy, bo to byłaby ósma.
Siedem czerwonych flag w umowach i cennikach
Czerwona flaga #1. „Cena pewna, zakres orientacyjny”
Klasyczny pattern w polskiej branży IT: dostawca daje cenę 80 tysięcy PLN po 30-minutowej rozmowie. Bez zdefiniowanego SOW (Statement of Work), bez listy konkretnych ekranów, integracji i kryteriów odbioru. Każda zmiana w trakcie projektu = doliczenie ekstra po stawce godzinowej.
Dowód twardy: według Project Management Institute 2025 62% przekroczeń budżetu w projektach IT to rozdęty zakres. 50% projektów IT dotyka tego problemu w trakcie. Główna przyczyna: brak zdefiniowanego SOW przed podpisaniem.
Reframe: cena pewna bez SOW to nie umowa, tylko zaproszenie do negocjacji w trakcie projektu. Jeśli dostawca nie chce wpisać konkretów do umowy, oznacza to jedno z dwóch . albo nie wie, co zrobi (ryzyko jakości), albo wie i celowo zostawia sobie pole do dodatkowych faktur (ryzyko budżetowe). Realne widełki cenowe MVP rozpisaliśmy w osobnym artykule: ile kosztuje aplikacja webowa w 2026. Kwota tam to baseline, do którego porównujesz każdą pewną cenę.
Co zapytać: „Możemy dodać do umowy załącznik SOW z listą funkcji, ekranów i kryteriów odbioru, oraz definicją procedury zmian?” Jeśli odpowiedź to „nie robimy tak” albo „za dużo formalizmu” . pierwsza pułapka potwierdzona.
Czerwona flaga #2. „Mamy własny CMS, własny framework, własną platformę”
Dostawca pisze na własnym frameworku, którego nie zna nikt poza ich zespołem. Brzmi jak zaleta („mamy gotowe rozwiązanie, szybciej”). Realnie to klasyczny vendor lock-in, czyli sytuacja, w której klient nie może zmienić dostawcy bez nadmiernych kosztów.
Polski kontekst prawny: vendor lock-in jest opisany w polskiej praktyce IT (kancelarie RPMS, BCLA). Występuje wtedy, kiedy klient nie ma operacyjnego dostępu do kodu źródłowego, dokumentacji technicznej albo narzędzi administracyjnych. Wyjście z tego stanu kosztuje więcej niż przepisanie aplikacji od zera u nowego dostawcy.
Reframe: custom framework agencji jest zarobkiem agencji, nie Twoim. Standardowy stack (React, Next.js, Node.js, Postgres, Python z Django) ma w Polsce 100 tysięcy deweloperów. Custom framework agencji X ma 8 deweloperów, którzy wszyscy pracują dla agencji X.
Co zapytać: „W jakim stacku piszecie? Czy używacie własnych bibliotek czy publicznych? Kto poza Wami umiałby utrzymać ten kod za 2 lata?” Jeśli odpowiedź to „nasz framework jest lepszy bo dedykowany” . to mina rozbrojona przed wybuchem.
Czerwona flaga #3. „Estymata = oferta” (brak buforu w wycenie)
Dostawca estymuje 80 godzin pracy, w ofercie wpisuje 80 godzin po stawce 250 PLN. Cena ostateczna: 20 tysięcy PLN. Wygląda przejrzyście, brzmi uczciwie. Pułapka w tym, że zero buforu znaczy zero zapasu na nieoczekiwane.
W projekcie IT nieoczekiwane są standardem. Klient zmieni jedno wymaganie, regulacja prawna się zmieni, integracja okaże się trudniejsza niż zakładano. Bez buforu dostawca ma dwie opcje: zaakceptować stratę (i dostarczyć minimum, byle skończyć), albo doliczyć każdą zmianę po stawce godzinowej (po cenie 1.5-2× wyższej niż wycena pierwotna).
Reframe: realna wycena to estymata plus 20-30% buforu na nieoczekiwane. Bez buforu albo dostawca dostarczy minimum, albo Cię obciąży po fakcie. Trzecia opcja (dostawca wchłonie stratę, dostarczy świetną jakość bez doliczeń) zdarza się rzadziej niż myślisz.
Co zapytać: „Jaki bufor zakładacie w estymacie na nieoczekiwane? A co się dzieje, jeśli zakres zmienia się o 10% w trakcie?” Odpowiedź „nie zakładamy buforu, jesteśmy precyzyjni” jest sygnałem ostrzegawczym, nie zaletą.
Czerwona flaga #4. „Etap rozpoznania? Mamy gotowy template”
Rozmowa wstępna, czyli etap rozpoznania, to fundament każdego projektu IT. Definiuje co dokładnie powstanie, jakie są edge case’y, jakie są integracje, jakie regulacje obowiązują. Realny etap rozpoznania trwa 1-2 tygodnie i kosztuje 5-15 tysięcy PLN dla średniego projektu.
Niektóre agencje sprzedają rozmowa wstępna jako „darmowy” lub „wliczony”. Wygląda jak bonus dla klienta. Realnie znaczy, że używają template’u z poprzedniego projektu, zmieniają nazwy, dodają logo klienta i przedstawiają jako „output rozpoznania”. Edge case’y Twojej branży nie są zbadane. Pierwsze tygodnie po podpisaniu = klient płaci za naukę agencji o swoim biznesie.
Reframe: generic rozmowa wstępna to czerwona flaga, nie zaleta. Realny etap rozpoznania zajmuje czas i kosztuje pieniądze. Ten koszt zwraca się 5-krotnie w ciągu projektu, bo unikasz kosztownych zmian w trakcie.
Co zapytać: „Pokażcie rozmowa wstępna output z poprzedniego projektu w naszej branży. Jakie edge case’y wykryliście?” Jeśli output to ogólnik typu „użytkownik loguje się, wybiera produkt, otrzymuje ofertę” . to nie jest rozmowa wstępna, to jest opis każdej aplikacji.
Czerwona flaga #5. „Po starcie produkcyjnym jesteście u nas”
Hosting na koncie agencji, repozytoria w ich GitHub, klucze API w ich password managerze, certyfikaty SSL w ich panelu. Klient ma link do produkcji i to wszystko. Każda zmiana, każda aktualizacja, każdy bugfix wymaga zlecenia agencji.
Polski kontekst prawny: klauzula transferu kodu źródłowego, dokumentacji i poświadczeń (hosting, domeny, certyfikaty, klucze API) musi być w umowie wprost. Bez niej dostawca ma prawo zatrzymać operacyjną kontrolę nawet po zapłacie. Polskie prawo autorskie nie przekazuje praw automatycznie i nie zmusza dostawcy do oddania środowisk produkcyjnych bez explicit klauzuli.
Reframe: bez transferu kodu i środowisk nie kupiłeś aplikacji. Kupiłeś subskrypcję usługi software house, w której produkt fizycznie jest u nich. Agencja może podnieść cenę utrzymania o 50% w drugim roku, a Ty nie masz alternatywy bez przepisania od zera.
Co zapytać: „Czy od dnia 1 repozytorium będzie na naszym koncie GitHub/GitLab? Gdzie przechowywane są klucze API i hasła hostingowe w trakcie projektu? Po zapłacie ostatniej faktury otrzymujemy pełen dump kodu, dokumentacji i poświadczeń?”
Czerwona flaga #6. „Stawka seniora w ofercie, praca juniora w realnym projekcie”
Agencja sprzedaje stawkę 250-300 PLN za godzinę, opisując zespół jako „mid-senior”. Realnie pracuje junior z konsultacją seniora raz w tygodniu (godzinowo, na rozmowie 1:1). Klient widzi delivery wolny, kod niskiej jakości i bugi, agencja zarabia 60% marży zamiast standardowych 30-40% (bo płaci juniorowi 70 PLN/h, sprzedaje za 280 PLN/h).
Pattern jest legalny. Umowa zwykle nie precyzuje, kto pracuje, ile godzin senior, ile junior. Agencja wpisuje w ofercie nazwy ról zamiast nazw osób. „Senior backend developer (200h)” wygląda profesjonalnie. Realnie znaczy „ktoś z zespołu, kto zostanie przydzielony, najprawdopodobniej junior z code review seniora raz w tygodniu”.
Reframe: pytaj o imiona, lata doświadczenia osób wpisanych w ofertę, ich daily availability i godziny przydzielone. Nie role, nie tytuły, nie „senior backend”. Konkretne osoby z konkretnym czasem.
Co zapytać: „Kto konkretnie pracuje na projekcie? Imię, nazwisko, lata doświadczenia w stacku, ile godzin tygodniowo na nasz projekt?” Jeśli odpowiedź to „przydział będzie po podpisaniu umowy, mamy pulę zasobów” . zatrzymaj negocjacje i poszukaj dalej.
Czerwona flaga #7. „Klauzula IP? Standard”
Najgorsza klauzula umowna w polskim IT brzmi mniej więcej tak: „Prawa autorskie do kodu pozostają u wykonawcy do momentu pełnej zapłaty”. Wygląda jak standard. Klient płaci, prawa się przenoszą, koniec sprawy.
Polski kontekst prawny: w prawie polskim prawa autorskie nie przenoszą się automatycznie. Wymagają explicit klauzuli „przeniesienie majątkowych praw autorskich na zamawiającego na wszystkich polach eksploatacji” plus listy tych pól (wprowadzenie do obrotu, modyfikacja, sublicencjonowanie, użytek komercyjny). Bez tego pełnego zapisu klient ma jedynie licencję, nie własność.
Konsekwencja braku przeniesienia praw autorskich
Zapłaciłeś 50 tysięcy PLN za aplikację, ale formalnie masz tylko licencję na użytkowanie. Dostawca może kod sprzedać innemu klientowi (jeśli go uogólni), zatrzymać prawa do publikacji jako case study, albo użyć fragmentów w innych projektach. Twój konkurent może kupić bardzo podobną aplikację u tej samej agencji za 60% Twojej ceny, bo bazują na Twojej pracy.
Co zapytać: „Czy w umowie jest klauzula przeniesienia majątkowych praw autorskich na nas, na wszystkich polach eksploatacji, z chwilą zapłaty ostatniej faktury? Czy umowa zakazuje wykorzystania fragmentów kodu w projektach dla innych klientów bez naszej zgody?” Jeśli klauzula „przeniesienie” jej nie ma . zatrzymaj negocjacje.
| Element umowy | ✗ Wersja niebezpieczna (red flag) | ✓ Wersja zabezpieczająca klienta |
| Zakres pracy | „Wytworzenie aplikacji webowej zgodnej z wymaganiami klienta” | Załącznik SOW: lista ekranów, integracji, kryteriów odbioru |
| Procedura zmian | „Zmiany rozliczane będą po stawce godzinowej” | Pisemna procedura: wniosek o zmianę, estymata, akceptacja klienta przed wykonaniem |
| Prawa autorskie | „IP pozostaje u wykonawcy do pełnej zapłaty” | „Przeniesienie majątkowych praw autorskich na klienta na wszystkich polach eksploatacji z chwilą zapłaty ostatniej faktury” |
| Transfer kodu i środowisk | „Po zakończeniu projektu klient otrzymuje dostęp do produkcji” | Repozytoria na koncie klienta od dnia 1, klucze API w jego password managerze, dump dokumentacji w 7 dni od ostatniej faktury |
| Zespół | „Mid-senior backend developer, 200h” | Konkretne imiona z latami doświadczenia, daily availability, godzinami przydzielonymi |
| Rozwiązanie umowy | „Strony mogą rozwiązać za porozumieniem” | Klient może rozwiązać z 30-dniowym wypowiedzeniem, dostawca w 7 dni przekazuje kod i dokumentację, niezapłacone godziny na podstawie ewidencji |
| Odpowiedzialność | „Wykonawca nie odpowiada za szkody” | Limit odpowiedzialności do wysokości umowy plus klauzula gwarancji jakości na 12 miesięcy |
Cztery sygnały, że projekt jest już w trakcie obsuwy
Jeśli umowa jest podpisana i te sygnały już występują . nie panikuj, ale zatrzymaj projekt na 48 godzin i skonsultuj się z prawnikiem IT. Każdy z tych sygnałów jest naprawialny w pierwszych 90 dniach. Po 90 dniach koszt naprawy podwaja się każdego miesiąca.
- Faktury za zmiany pojawiają się przed pierwszym milestone’em. Agencja powinna w pierwszych 4-6 tygodniach realizować zakres podstawowy. Jeśli już w 2-3 tygodniu pojawia się faktura „prace dodatkowe” . SOW był nieprecyzyjny i wchodzi pattern doliczania.
- Repozytoria są na koncie agencji, nie Twoim. Jeśli po 2 tygodniach od kickoff projektu logujesz się do GitHuba i widzisz organizację dostawcy zamiast Twojej . przekazanie kodu po launchu będzie trudne.
- Brak działającego prototypu po 4 tygodniach. Co tydzień dostajesz slide z agendą, slajd z postępami, ale nie ma URL-a, na który możesz wejść i zobaczyć produkt. Realne projekty mają działający prototyp (nawet niepełny) w 3-4 tygodniu.
- Output rozmowa wstępna to PowerPoint, nie Figma plus dokument. Realne rozmowa wstępna wytwarza 3 rzeczy: makiety w Figmie (klikalne), dokument zakresu w formie wiążącej (lista funkcji, kryteria odbioru, edge case’y) i listę założeń technicznych (stack, integracje, infrastruktura). PowerPoint z ogólnikami nie zastępuje żadnej z nich.
Pięć pytań, które musisz zadać każdej agencji ZANIM podpiszesz
Te pytania nie wymagają znajomości prawa. Wymagają konkretnej, pisemnej odpowiedzi przed podpisaniem umowy. Jeśli agencja odmawia odpowiedzi pisemnej („przedyskutujemy w trakcie”) . to jest siódma czerwona flaga.
PYTANIE 1
Komu należą prawa autorskie?
Powinno być: Tobie, z chwilą zapłaty ostatniej faktury, na wszystkich polach eksploatacji.
PYTANIE 2
Gdzie hostowane są repozytoria?
Powinno być: na Twoim koncie GitHub/GitLab od dnia 1, agencja ma uprawnienia jako współpracownik.
PYTANIE 3
Kto konkretnie pracuje?
Powinno być: imię, nazwisko, lata doświadczenia, godziny przydzielone tygodniowo. Nie nazwy ról.
PYTANIE 4
Co dokładnie obejmuje SOW?
Powinno być: lista ekranów, integracji, kryteriów odbioru, plus pisemna procedura zmian zakresu.
PYTANIE 5
Jakie są warunki rozwiązania?
Powinno być: 30-dniowe wypowiedzenie, transfer kodu i dokumentacji w 7 dni, rozliczenie godzinowe na podstawie ewidencji.
Co NIE robimy w JSON Crew (i czemu to dobre dla Ciebie)
Po czterech latach pracy widzimy, że agencje ogólne, które „robią wszystko”, są albo cienkie w każdym obszarze, albo drogie w każdym, albo jedno i drugie. Wybraliśmy odwrotną drogę: specjalizację niszową w cyfrowej transformacji sprzedaży B2B.
Co robimy
- Konfiguratory produktowe (Three.js, dedykowane silniki reguł cenowych)
- Panele klienta i portale ofertowe
- Dashboardy IoT (energetyka, produkcja, smart home)
- Automatyzacje sprzedaży (CRM, ofertowanie, integracje ERP)
- Plus dla istniejących klientów rozwijamy JSON Hub (nasz produkt SaaS łączący CRM, ofertowanie, zarządzanie projektem i konfigurator w jednym ekosystemie)
Czego NIE robimy
- Serwisów społecznościowych
- Gier i oprogramowania do gier
- Ogólnych platform SaaS bez jasnego przypadku użycia
- Sklepów typu Shopify czy WooCommerce
- Projektów blockchain i kryptowalutowych
- Startupów AI bez zdefiniowanego problemu biznesowego
Każdy z tych obszarów wymaga dedykowanej ekspertyzy, której nie posiadamy w głębi. Odsyłamy projekty, których realnie nie zrobimy lepiej niż wyspecjalizowany konkurent.
Co stoi w naszych umowach standardowo
- Załącznik SOW z listą funkcji, integracji i kryteriów odbioru
- Pisemna procedura zmian zakresu (wniosek, estymata, akceptacja klienta)
- Przeniesienie majątkowych praw autorskich na klienta na wszystkich polach eksploatacji z chwilą zapłaty ostatniej faktury
- Repozytoria na koncie klienta od dnia 1
- Stack publiczny (React, Next.js, Node.js, Postgres, Python z Django) . zero własnego frameworka
- Konkretne imiona zespołu w ofercie z godzinami przydzielonymi
- 30-dniowe wypowiedzenie z transferem kodu i dokumentacji w 7 dni
Jeśli któryś punkt jest dla Ciebie problemem (np. nie chcesz konta GitHub, wolisz że hostujemy), pisemnie negocjujemy odstępstwo. Domyślnie te zabezpieczenia są dla klienta. Jeśli budujesz konfigurator produktu B2B, panel klienta, panel IoT albo automatyzację sprzedaży, jesteśmy w samym środku tego co robimy. A jeśli Twój pomysł jest poza tym zakresem . z chęcią polecimy Ci zaufanego konkurenta.
Co dalej. Zacznij od rozmowy o umowie, nie o cenniku
Cennik w Twojej obecnej ofercie to mapa, nie kosztorys. Twoja konkretna umowa ma swój zakres, swój kontekst, swoje klauzule i swoje pułapki. Realna ocena tego, co podpisujesz, wymaga 30 minut rozmowy o aktualnej ofercie albo umowie, którą rozważasz.
Dobra wiadomość: umowa nie musi być mapą pola minowego. Może być zabezpieczeniem. Te same 7 czerwonych flag, które okradają jednych klientów, są dla innych po prostu listą pytań, którą zadali na drugiej rozmowie z dostawcą. Różnica jest w tym, czy wiedziałeś co czytać przed podpisaniem.
Rozmowa diagnostyczna jest bezpłatna i bez slajdów. Wyjdziesz z niej z trzema rzeczami: listą czerwonych flag w Twojej obecnej ofercie (jeśli już ją masz), listą pytań do dostawcy przed podpisaniem (jeśli jeszcze negocjujesz), oraz mapą tego, co MUSI być w umowie żebyś po roku nie wracał z fakturami za scope creep.
Jeśli okaże się, że jesteśmy w Twoim zakresie, opowiemy o naszym sposobie pracy. W przeciwnym razie dostaniesz listę kontrolną i zaoszczędzisz 6 miesięcy lekcji na własnym projekcie.
OPCJA 1 · ROZMOWA DIAGNOSTYCZNA
Pogadajmy o Twojej umowie, nie o naszym cenniku
30 minut. Bez slajdów, bez pitchu. Wyjdziesz z listą czerwonych flag i pytań do dostawcy.
OPCJA 2 · WYBÓR DOSTAWCY
Jak wybrać software house po złym doświadczeniu
7 pytań przed podpisaniem umowy plus 7 czerwonych flag. Pillar dla foundera po pierwszej nieudanej współpracy.
Najczęstsze pytania o umowy z software house
Pytania o zakres i cenę
Co znaczy red flag w umowie z software house?
Czerwona flaga to klauzula lub pattern w ofercie albo umowie, który wygląda jak standard branżowy, ale realnie działa na Twoją niekorzyść. Przykłady: brak zdefiniowanego SOW, własny framework dostawcy, brak transferu kodu po starcie produkcyjnym, klauzula IP która nie przenosi praw autorskich. Nie są to pułapki w sensie nielegalnym (są w 80% kontraktów IT), ale są pułapkami w sensie ekonomicznym . kosztują klienta 1.5-2× więcej niż wycena pierwotna.
Czemu cena „pewna” w umowie zwykle nie jest pewna?
Bo cena jest pewna tylko dla zdefiniowanego zakresu (SOW). Bez SOW każda zmiana w trakcie projektu jest „poza zakresu” i jest doliczana po stawce godzinowej. PMI 2025 raportuje, że 62% przekroczeń budżetu IT to rozdęty zakres, a 50% projektów IT dotyka go w trakcie. Realna umowa „cena pewna” zawiera załącznik SOW z listą funkcji, integracji, kryteriów odbioru i pisemną procedurą zmian zakresu.
Pytania o IP i kod źródłowy
Czy prawa autorskie do kodu przechodzą automatycznie po zapłacie?
Nie. W prawie polskim majątkowe prawa autorskie nie przenoszą się automatycznie. Wymagają explicit klauzuli „przeniesienie majątkowych praw autorskich na zamawiającego na wszystkich polach eksploatacji” plus listy tych pól (modyfikacja, dystrybucja, sublicencjonowanie, użytek komercyjny, publikacja). Bez tego pełnego zapisu klient ma jedynie licencję na użytkowanie, nie własność. Polska kancelaria specjalizująca się w IT (RPMS, BCLA) potwierdza to w publicznych analizach.
Co to jest vendor lock-in i jak go uniknąć?
Vendor lock-in to sytuacja, w której klient nie może zmienić dostawcy bez nadmiernych kosztów (typowo 1.5-2× ceny pierwotnego projektu). Występuje, gdy dostawca pisze na własnym frameworku, trzyma kod w swoim repozytorium, hostuje na swoim koncie. Aby uniknąć: standardowy stack (React, Node.js, Postgres), repozytoria na koncie klienta od dnia 1, klauzula transferu wszystkich poświadczeń (klucze API, hasła, certyfikaty) w 7 dni od ostatniej faktury.
Pytania o zespół i delivery
Czemu w ofercie powinny być imiona zespołu, nie nazwy ról?
Bo nazwa „mid-senior backend developer 200h” w ofercie nie zobowiązuje agencji do przydziału konkretnej osoby. Po podpisaniu umowy agencja może wstawić juniora z konsultacją seniora raz w tygodniu. Stawka jest seniorska (250-300 PLN/h), realnie pracuje junior (koszt agencji 70 PLN/h). Marża 60% zamiast standardowych 30%. Klient widzi delivery wolny i kod niskiej jakości. Pytaj o imiona, lata doświadczenia w stacku i godziny przydzielone tygodniowo na Twój projekt.
Po jakim czasie powinien być działający prototyp w projekcie?
Realne projekty mają działający prototyp (URL produkcyjny lub staging) w 3-4 tygodniu od kickoff projektu, nawet jeśli prototyp pokrywa tylko jeden user flow. Brak prototypu po 4 tygodniach to czerwona flaga. Co tygodniowy slide z agendą bez działającej aplikacji to drugi sygnał ostrzegawczy. Jeśli oba występują . zatrzymaj projekt na 48 godzin i porozmawiaj z prawnikiem IT przed kolejną fakturą.
O autorze. Jędrzej Siewierski. CEO i współzałożyciel JSON Crew. Wycenia konfiguratory produktowe, panele klienta, panele IoT i automatyzacje sprzedaży dla firm B2B w Polsce, Niemczech i Wielkiej Brytanii. W standardowej umowie JSON Crew kod, dokumentacja i hosting transferują się do klienta z chwilą zapłaty ostatniej faktury, repozytoria są na koncie klienta od dnia 1, a stack jest publiczny (React, Next.js, Node.js, Postgres). Więcej o autorze · LinkedIn
