O co zapytać Software House przed podpisaniem umowy? (7 pytań, które uratują Twój budżet)

Wyobraź sobie, że stoisz przed drzwiami nowoczesnego biura (lub na wirtualnym spotkaniu na Google Meet). Po drugiej stronie ekranu siedzi zespół uśmiechniętych ekspertów. Prezentacja wygląda niesamowicie, używają modnych, angielskich słów, pokazują wykresy i zapewniają, że Twoja aplikacja zrewolucjonizuje rynek. Masz w ręku budżet – kilkadziesiąt, a może kilkaset tysięcy złotych – i genialny pomysł, w który wierzysz całym sercem. Jesteś o krok od podpisania umowy.

Zatrzymaj się. Weź głęboki oddech. To jest moment, w którym decyduje się przyszłość Twojego biznesu.

Większość nietechnicznych założycieli (Founderów) wchodzi we współpracę z agencjami IT z ogromną dawką zaufania. Niestety, branża technologiczna cierpi na gigantyczną asymetrię informacji. Software House wie o tworzeniu oprogramowania wszystko, a Ty wiesz o tym niewiele. To trochę jak pójście do mechanika z zepsutym silnikiem, gdy nie znasz się na samochodach – musisz wierzyć na słowo, że „bulbulator” faktycznie wymaga wymiany za 10 000 złotych.

Złe decyzje na etapie podpisywania umowy to nie tylko opóźnienia. To zrujnowane budżety, spory sądowe i, w najgorszym scenariuszu, oprogramowanie, do którego nie masz nawet praw autorskich.

Ten monumentalny, wyczerpujący poradnik został stworzony po to, by wyrównać szanse. Przedstawiamy 7 absolutnie krytycznych, bezkompromisowych pytań, które musisz zadać każdej agencji IT (w tym również nam) przed złożeniem podpisu na umowie. Te pytania obnażą każdą nierzetelną firmę i pozwolą Ci znaleźć prawdziwego partnera technologicznego, który dowiezie Twój projekt na czas i w budżecie.

Pytanie 1: Kto faktycznie jest właścicielem kodu i kiedy następuje przekazanie praw autorskich?

To najważniejsze pytanie ze wszystkich. Brak zrozumienia kwestii praw autorskich to powód, dla którego wiele startupów upada, zanim w ogóle zacznie generować zyski.

Wydaje Ci się to logiczne: „Skoro płacę za stworzenie aplikacji 100 000 zł, to kod jest mój, prawda?”.

Otóż w świetle polskiego (i międzynarodowego) prawa – absolutnie nie. Jeśli umowa wyraźnie tego nie precyzuje, domyślnym właścicielem kodu, który został wytworzony, jest jego twórca (programista lub Software House). Ty otrzymujesz jedynie licencję na jego użytkowanie.

Pułapka Licencji vs. Własność (Majątkowe Prawa Autorskie)

Jeśli podpiszesz umowę, w której agencja udziela Ci jedynie licencji na kod, wpadasz w tzw. Vendor Lock-in (Uzależnienie od dostawcy). Oznacza to, że:

• Nie możesz sprzedać swojej aplikacji innemu inwestorowi (bo nie masz praw do kodu).
• Nie możesz przenieść projektu do tańszego lub lepszego Software House’u.
• Jeśli agencja IT zbankrutuje, Twój projekt może zostać zablokowany lub całkowicie zniknąć.

Czego musisz wymagać?

W umowie musi znaleźć się obszerny paragraf o Przeniesieniu Majątkowych Praw Autorskich. Przeniesienie to powinno następować automatycznie z chwilą zapłaty za dany etap prac (tzw. Sprint) lub wystawienia faktury.

Dostęp do Repozytorium (Twojego wirtualnego sejfu)

Sam zapis na papierze to za mało. Kod to cyfrowe aktywo, które musi gdzieś fizycznie (lub w chmurze) istnieć. Programiści przechowują historię kodu w tzw. repozytoriach (najpopularniejsze to GitHub, GitLab, Bitbucket).

Pytanie, które musisz zadać na spotkaniu: „Czy jako klient otrzymam pełne prawa administratora (Owner/Admin) do repozytorium kodu na platformie GitHub/GitLab od pierwszego dnia trwania projektu?”

Jeśli Software House zaczyna kręcić, mówiąc: „Dajemy kod na koniec, jak już wszystko zrobimy” – uciekaj. To Twoje oprogramowanie, Ty za nie płacisz, i powinieneś mieć dostęp do swojego cyfrowego „placu budowy” 24 godziny na dobę, 7 dni w tygodniu.

Pytanie 2: Fixed Price czy Time & Material? (Czyli jak uniknąć wojny o każdą zmianę)

Kiedy prosisz o wycenę budowy domu, chcesz wiedzieć z góry, ile to będzie kosztować. Kiedy prosisz o wycenę aplikacji, naturalnie oczekujesz tego samego. Chcesz usłyszeć: „Zrobimy tę aplikację za 60 000 zł w 3 miesiące”.

Model ten w branży IT nazywa się Fixed Price (Stała Cena). Brzmi bezpiecznie, prawda? Niestety, w 90% innowacyjnych projektów technologicznych to najgorszy możliwy wybór, który prowadzi do konfliktów.

Dlaczego Fixed Price dla nowych aplikacji to iluzja?

Tworzenie innowacyjnej aplikacji to nie jest układanie płytek w łazience według ścisłego schematu. To proces twórczy. Pomyśl o tym w ten sposób:

Załóżmy, że podpisujesz umowę Fixed Price. W połowie prac pokazujesz aplikację grupie docelowej i nagle zdajesz sobie sprawę, że funkcja „Czat wideo”, na którą przewidziano 30% budżetu, jest nikomu niepotrzebna, a użytkownicy błagają o „Kalendarz rezerwacji”, którego nie ma w specyfikacji.

W modelu Fixed Price masz związane ręce. Software House powie: „Panie Janie, w załączniku nr 2 do umowy mamy wpisany czat wideo. Żeby dodać kalendarz, musimy zrobić Aneks, wstrzymać prace i wycenić to od nowa na dodatkowe 15 000 zł”. Efekt? Płacisz za funkcje, których nikt nie chce, tylko dlatego, że wymyśliłeś je 3 miesiące wcześniej. Ponadto, agencje w modelu Fixed Price doliczają do ceny tzw. „poduszkę bezpieczeństwa” (często 30-50% narzutu), by zabezpieczyć się przed ryzykiem.

Ratunek: Model Time & Material (T&M) + Agile

Nowoczesne, transparentne i uczciwe Software House’y proponują model Time & Material (Płacisz za przepracowany czas i materiały) w połączeniu z metodyką Agile (Zwinne Zarządzanie).

W tym modelu budżet jest elastyczny i rozliczany zazwyczaj co 2 tygodnie (tzw. Sprinty).

Jak sprawdzić uczciwość w modelu T&M?

Zadaj pytanie: „W jaki sposób będziecie raportować czas pracy zespołu?”.

Dobra agencja pokaże Ci dostęp do narzędzi (np. Jira, Toggl, Clockify), w których widzisz z dokładnością do minuty, ile czasu programista poświęcił na stworzenie konkretnego przycisku czy funkcji. Płacisz wyłącznie za realną, udowodnioną pracę.

Pytanie 3: Kto DOKŁADNIE będzie pisał mój kod? (Uwaga na pułapkę Juniorów)

To jedno z najbardziej niewygodnych pytań, jakie możesz zadać na spotkaniu sprzedażowym, ale jego moc ratuje biznesy.

Częstą, choć nieetyczną praktyką w dużych „fabrykach kodu” (korporacyjnych Software House’ach) jest model sprzedażowy nazywany Bait and Switch (Przynęta i zamiana). Na spotkaniach sprzedażowych i architektonicznych widzisz absolutnych ekspertów – Seniorów i Architektów z 15-letnim stażem. Opowiadają o architekturze chmurowej, bezpieczeństwie bankowym i skalowalności. Zachwycony podpisujesz stawkę godzinową na poziomie „Ekspert”.

A potem projekt rusza. Architekt, z którym rozmawiałeś, przeskakuje do kolejnego klienta na sprzedaż, a kod Twojej aplikacji fizycznie pisze dwóch „Junior Developerów”, którzy zostali zatrudnieni miesiąc temu na stażu.

Jak zdemaskować skład zespołu?

Nie bój się zażądać transparentności. Budowanie aplikacji to praca drużynowa, w której każdy ma przypisaną rolę, jak w armii lub kuchni w restauracji z gwiazdką Michelin.

Zapytaj: „Chcę zobaczyć ślepe CV (tzw. Blind CV – bez nazwisk, ale z doświadczeniem) osób, które będą dedykowane na 100% czasu do mojego projektu. Jakie będzie „Seniority” (poziom zaawansowania) mojego zespołu?”

Idealny, zbalansowany zespół projektowy dla aplikacji od zera powinien wyglądać mniej więcej tak:

1. Project Manager (PM) / Scrum Master: Twój adwokat wewnątrz firmy. Pilnuje, by projekt szedł do przodu i tłumaczy Ci język IT na język ludzki.
2. Senior Backend Developer / Architekt: Mózg operacji. Osoba, która musi zaprojektować fundamenty (bazę danych, serwery, bezpieczeństwo). Nie można na tym oszczędzać.
3. Mid/Regular Frontend/Mobile Developer: Solidny, samodzielny pracownik. Przenosi design na ekrany telefonów. Pod nadzorem Seniora radzi sobie świetnie.
4. UX/UI Designer: Ktoś, kto sprawia, że aplikacja jest nie tylko ładna, ale też wygodna dla użytkownika. Zespoły składające się wyłącznie z programistów (bez designera) zazwyczaj tworzą potwornie brzydkie i trudne w obsłudze systemy.
5. QA Specialist (Tester): Człowiek, którego jedynym zadaniem jest próba „zniszczenia” Twojej aplikacji przed jej premierą, by znaleźć luki.

Upewnij się w umowie, że kluczowi członkowie zespołu nie mogą zostać usunięci z projektu bez Twojej zgody i odpowiedniego okresu na wdrożenie nowej osoby (tzw. Knowledge Transfer).

Pytanie 4: Jakie są koszty i plany „Dzień po premierze”? (SLA, Gwarancja i Utrzymanie)

Naiwnością jest sądzić, że aplikacja mobilna to obraz, który malujesz, wieszasz na ścianie i o nim zapominasz. Oprogramowanie to żywy organizm. To bardziej jak utrzymanie luksusowego samochodu – nawet jeśli nim nie jeździsz, musisz płacić ubezpieczenie, robić przeglądy i wymieniać zużywające się części.

Najwięcej awantur między klientami a agencjami wybucha dzień po wrzuceniu aplikacji do Apple App Store i Google Play.

„Dlaczego po wczorajszej aktualizacji iPhone’a moja aplikacja przestała działać? Naprawcie to za darmo!” – krzyczy klient.

„Zgodnie z umową projekt został zamknięty. Naprawa kosztuje 5000 zł” – odpowiada agencja.

Aby tego uniknąć, przed podpisaniem pierwszej umowy zapytaj o koszty i zasady wsparcia powdrożeniowego.

Trzy filary powdrożeniowe, które musisz znać:

1. Gwarancja na Błędy (Bug-fixing)

Dobra umowa powinna zawierać okres gwarancji (zazwyczaj od 3 do 12 miesięcy) na błędy ukryte. Błąd ukryty to sytuacja, w której oprogramowanie zachowuje się niezgodnie z zaakceptowaną specyfikacją.

• Przykład: Użytkownik klika „Zaloguj”, a aplikacja się zawiesza. Agencja naprawia to w ramach gwarancji za darmo.
• Co nie jest gwarancją: Użytkownik klika „Zaloguj”, ale stwierdzasz, że ten przycisk jednak powinien być czerwony i migający. To nowa funkcja – musisz za nią zapłacić.

2. SLA (Service Level Agreement)

Jeśli prowadzisz aplikację dla kurierów i w piątek o 18:00 pada główny serwer, nie możesz czekać do poniedziałku rano, aż programista przyjdzie z kawą do biura, bo przez ten czas tracisz tysiące złotych.

SLA to formalna umowa utrzymaniowa. Płacisz stały abonament miesięczny (tzw. Retainer) w zamian za to, że Software House gwarantuje czas reakcji (np. „Podejmiemy próbę naprawy serwera w maksymalnie 4 godziny od zgłoszenia błędu krytycznego, w trybie 24/7”).

3. Koszty Infrastruktury Osobnej (Chmura i API)

Niektóre Software House’y ukrywają przed nietechnicznymi klientami miesięczne koszty usług zewnętrznych, żeby wycena końcowa wyglądała atrakcyjniej. Zapytaj wprost o prognozy kosztów dla:

• Serwerów w chmurze (AWS, Google Cloud, Azure): Ile będzie to kosztować przy 1000 użytkowników, a ile przy 10 000?
• Konta deweloperskie: Apple App Store (ok. 99 USD rocznie) i Google Play (jednorazowo 25 USD).
• Zewnętrznych API: Czy używamy płatnych map Google? Serwisów do wysyłania SMS-ów autoryzacyjnych (np. Twilio)? Serwerów pocztowych?

Zmuszenie agencji do rozpisania tych kosztów przed startem uchroni Cię przed zawałem serca po otrzymaniu pierwszych faktur utrzymaniowych.

Pytanie 5: Jak wygląda proces testowania i kontroli jakości (Quality Assurance)?

Słynne powiedzenie inżynierskie mówi: „Każdy kod posiada błędy. Różnica polega na tym, kto je znajdzie pierwszy: my w biurze, czy Twój najcenniejszy klient w recenzji na 1 gwiazdkę”.

Jednym z najczęstszych miejsc, w którym nieuczciwe lub tanie agencje obcinają koszty, są testy (QA – Quality Assurance). Pozornie oszczędzasz 15% budżetu na braku testera. Realnie – wypuszczasz dziurawy produkt, który kompromituje Twoją markę.

O co konkretnie zapytać w kwestii QA?

1. „Czy w moim zespole jest dedykowany tester (QA), czy programiści testują swój własny kod?”
   • Jeśli usłyszysz, że programiści testują własny kod – uciekaj. Psychologia udowodniła, że twórca nie widzi własnych błędów, ponieważ używa aplikacji dokładnie tak, jak to sobie zaplanował („ścieżka szczęśliwa”). Prawdziwy tester QA jest bezlitosny – klika w pięć przycisków naraz, wpisuje znaki chińskie do pola na numer telefonu i wyłącza Wi-Fi w trakcie pobierania pliku. Tego potrzebujesz.
2. „Czy i jak stosujecie testy automatyczne?”
   • Testy ręczne są fajne na początku. Ale kiedy aplikacja rośnie, sprawdzenie całego systemu przed każdą małą aktualizacją ręcznie potrwa tydzień. Automatyzacja testów to kod, który testuje inny kod. Zapytaj, czy kluczowe, biznesowe ścieżki (np. proces logowania, proces płatności w koszyku) będą pokryte testami automatycznymi (Unit Tests / E2E).
3. UAT (User Acceptance Testing) – Kiedy Ty testujesz?
   • Upewnij się, że umowa przewiduje odpowiedni czas (np. 14 dni po zakończeniu prac) na testy odbiorcze po Twojej stronie (UAT). Zanim podpiszesz protokół odbioru końcowego, musisz mieć czas na poklikanie w gotowy produkt z własnego telefonu, we własnym łóżku, a nie tylko podczas kontrolowanej prezentacji na rzutniku.

Pytanie 6: Co się stanie, jeśli po 3 miesiącach zrezygnuję? (Exit Strategy i Dokumentacja)

Kiedy bierzesz ślub, nikt nie chce myśleć o rozwodzie (intercyzie). W biznesie IT brak przemyślenia „rozwodu” z góry to czyste samobójstwo.

Załóżmy tragiczny scenariusz: Zespół po miesiącu pracy okazuje się koszmarnie wolny. Komunikacja leży. Aplikacja się sypie. Rozwiązujesz umowę (o ile zadbałeś o okres wypowiedzenia np. 1-miesięczny, o który MUSISZ zadbać). Co zostaje w Twoich rękach po rozstaniu?

Jeśli o to nie zadbasz z góry, zostajesz z gigantyczną paczką niezrozumiałego kodu. Idziesz z tym do innej firmy IT, a oni po jednym spojrzeniu mówią: „Panie, to spaghetti code (kod tak splątany, że nie da się go czytać). Taniej będzie napisać wszystko od zera niż to naprawiać”. Setki tysięcy złotych wyrzucone do kosza.

Polisa ubezpieczeniowa przed utratą kodu:

Zabezpiecz się na wypadek ewakuacji zadając to jedno pytanie:

„Jakie standardy dokumentacji technicznej prowadzicie w projekcie i czy otrzymuję ją na bieżąco?”

Każdy dobrze prowadzony projekt IT musi posiadać aktualizowaną na bieżąco dokumentację. Składa się ona m.in. z:

• Readme.md: Pliku w głównym katalogu, który zawiera absolutne podstawy. Instrukcję krok po kroku (dla nowego programisty z zewnątrz), jak uruchomić aplikację na czystym komputerze w mniej niż godzinę.
• Komentarzy w kodzie: Trudne, skomplikowane algorytmy matematyczne czy biznesowe mają nad sobą linijkę zwykłego tekstu wyjaśniającą: „Ten moduł liczy zniżkę lojalnościową dla stałych klientów”.
• Dokumentacji API (np. Swagger): Dokumentacji pokazującej, jak w przyszłości podłączyć do aplikacji nowe systemy z zewnątrz.

Jeśli agencja stosuje międzynarodowe standardy kodowania, tzw. Czysty Kod (Clean Code), przejście z tym projektem do innego Software House’u zajmie nowej ekipie około 1-2 tygodni (tzw. proces Onboardingu). Jeśli agencja tworzy autorskie, ukryte rozwiązania (tzw. własne, zamknięte Frameworki) – jesteś do nich przywiązany łańcuchem na zawsze, bo nikt inny na rynku nie wie, jak to działa.

Pytanie 7: Jak wyglądają codzienne spotkania i jak często będę widział produkt?

Ostatnie, ale równie istotne z punktu widzenia psychicznego komfortu współpracującego z agencją i zarządzania własnym stresem. Częstym modelem w archaicznych firmach jest proces tzw. Waterfallowy (Kaskadowy): podpisujesz umowę, przekazujesz wytyczne, agencja znika w czarnej dziurze na 4 miesiące i po tym czasie wraca do Ciebie z gotowym systemem (który bardzo często w ogóle nie wygląda tak, jak chciałeś).

Wyobraź sobie budowę domu, w której nie masz prawa wejść na plac budowy przez pół roku, a po zakończeniu odbierasz klucze i odkrywasz, że sypialnia jest w piwnicy, a kuchnia na strychu.

Wymagaj pełnej przejrzystości operacyjnej

Profesjonalny Software House, pracujący w zwinnych metodykach, zaprosi Cię do bezpośredniej i ciągłej kooperacji. Pytania, które powinieneś tu zadać to:

• „Gdzie i jak będziemy się komunikować na co dzień?”
  • Mail jest do wymiany faktur i formalnych decyzji. Odcięcie się na mailach spowalnia projekt o 400%. Powinieneś dostać zaproszenie do wspólnego komunikatora (np. Slack, Microsoft Teams, Discord), gdzie jako klient masz swój własny kanał i bezpośredni kontakt z Project Managerem lub zespołem. Pytasz o coś rano – dostajesz odpowiedź w kilka minut.
• „Jak często będę mógł testować / „klikać” w to, co produkujecie?”
  • Jedyną poprawną odpowiedzią jest: Zazwyczaj co dwa tygodnie. Praca w Sprintach polega na tym, że po 14 dniach pracy zespół pokazuje Ci Demo. Nie obrazki na slajdach, ale namacalny element aplikacji. „Panie Janie, przez ostatnie dwa tygodnie pracowaliśmy nad rejestracją i odzyskiwaniem hasła. Proszę, oto link testowy, niech Pan spróbuje założyć konto”.
• „Co się stanie, jeśli z mojej strony braknie czasu na szybkie odpowiedzi?”
  • To ważne pytanie do samego siebie jako Foundera. Wymagając od agencji szybkości, musisz zadeklarować własną dyspozycyjność (tzw. Product Owner). Zespół programistów to kosztowna maszyna (często spalająca 2000-4000 zł dziennie na roboczogodzinach). Jeśli programista utknie w martwym punkcie, czekając na Twoją decyzję (np. „integrujemy płatności Stripe czy Przelewy24?”), nie może pracować efektywnie. Ustal zasady, jak szybko zobowiązujesz się odpisywać w kluczowych kwestiach.

Podsumowanie i Checklist’a na pierwsze spotkanie

Wiedza, którą właśnie przyswoiłeś, sprawia, że stajesz się trudnym, ale jednocześnie idealnym partnerem do współpracy dla każdego profesjonalnego zespołu IT na świecie. Wymagasz od partnera uczciwości, bo sam jesteś świadomy tego, za co płacisz. Pamiętaj: agencja, która obraża się na trudne pytania lub próbuje zbyć Cię „korpo-żargonem”, nie jest agencją, której powinieneś powierzyć pieniądze. Najlepsi w branży z przyjemnością i uśmiechem na twarzy wezmą z Tobą pod lupę każdy z wymienionych tu punktów.

Oto szybka ściągawka (Zrób z niej screena i miej na spotkaniu wideo przed oczami):

1. Prawa Autorskie: Kiedy i jak przechodzą na moją firmę majątkowe prawa autorskie do kodu? Czy dostanę uprawnienia Admina do repozytorium GitLab/GitHub na start?
2. Model Rozliczeń: Czy pracujemy elastycznie na podstawie transparentnych Sprintów (T&M) ze stałym dostępem do narzędzi mierzących czas pracy?
3. Skład Zespołu: Czy mogę zobaczyć ślepe CV członków zespołu, którzy będą fizycznie tworzyć kod? Czy przewidujecie udział kogoś na poziomie Seniora w projekcie?
4. SLA i Gwarancja: Jaki jest okres darmowej naprawy ukrytych błędów po premierze i ile będzie wynosić szacunkowy koszt serwerów w chmurze przy startowym ruchu?
5. Testy (QA): Kto w zespole będzie obiektywnie testował moją aplikację z ułamaniem „ścieżek szczęśliwych”?
6. Exit Strategy: Czy tworzycie dokumentację techniczną (Readme) i piszecie w standardach Clean Code, bym mógł bez problemu zabrać projekt z Waszej firmy w dowolnym momencie?
7. Komunikacja: Jak często odbywają się spotkania DEMO, na których będę mógł wyklikać na własnym telefonie to, co zakodowaliście?

Wybór Software House’u nie powinien być loterią ani skokiem na głęboką wodę z zasłoniętymi oczami. W budowie cyfrowych produktów najbardziej innowacyjne rozwiązania powstają na styku pełnej transparencji między wizją biznesową klienta a inżynierią, nad którą czuwają najlepsi w swoim fachu programiści. Dokładnie z takiego, szczerego założenia wychodzimy, tworząc projekty dla naszych klientów w przestrzeni cyfrowych, skalowalnych technologii.

Masz pomysł i chcesz sprawdzić naszą wiedzę w ogniu tych 7 pytań na bezpłatnej, luźnej rozmowie strategicznej? Jesteśmy gotowi. Skonfrontuj swoje wytyczne i upewnij się, że Twój budżet od pierwszego dnia powędruje we właściwe miejsce.