Firmę do stworzenia aplikacji webowej wybiera się na podstawie czterech rzeczy: działających wdrożeń, których możesz dotknąć, jasnych zasad rozliczenia, zapisanych praw do kodu oraz odpowiedzi na pytanie, kto konkretnie napisze Twój kod. Portfolio ze zrzutami ekranu, wycena bez zakresu i umowa bez klauzuli o przeniesieniu praw autorskich to trzy najczęstsze sygnały ostrzegawcze. Poniżej dwanaście pytań, które warto zadać przed podpisaniem.
Piszę to jako osoba po drugiej stronie stołu — i świadoma, że część tych pytań jest niewygodna także dla mnie. Ale klient, który wie, o co pytać, jest lepszym klientem: rozmowa jest krótsza, oczekiwania realne, a projekt rzadziej kończy się rozczarowaniem.
Pytania o to, czy potrafią
1. Czy mogę zobaczyć trzy działające wdrożenia z ostatniego roku?
Nie zrzuty ekranu — adresy. Wejdź na nie, kliknij, sprawdź na telefonie, zmierz czas ładowania w PageSpeed Insights. Portfolio złożone wyłącznie z grafik oznacza jedno z dwóch: projekty nie powstały albo nie przetrwały. Zapytaj też, które części danego wdrożenia robiła ta firma — bywa, że „realizacja" oznacza podmianę kolorów w cudzym projekcie.
2. Kto konkretnie będzie pisał mój kod?
W większych agencjach rozmawiasz z handlowcem, a kod pisze ktoś, kogo nigdy nie poznasz — czasem podwykonawca z innego kraju. To nie musi być złe, ale musisz to wiedzieć. Zapytaj wprost o imię, doświadczenie i o to, ile projektów ta osoba prowadzi równolegle.
3. Czy realizowaliście coś w mojej branży?
Przydatne, ale nie decydujące. Procesy powtarzają się między branżami częściej, niż się wydaje — obieg dokumentów w kancelarii i w firmie transportowej wygląda podobnie. Ważniejsze od branży jest doświadczenie z podobnym typem problemu: płatnościami, rolami użytkowników, integracją z systemem zewnętrznym.
4. Co poszło źle w ostatnim projekcie i jak to rozwiązaliście?
Najlepsze pytanie z całej listy. Każdy, kto zrobił kilkanaście wdrożeń, ma taką historię. Odpowiedź „u nas nigdy nic nie idzie źle" oznacza albo brak doświadczenia, albo brak szczerości — i obie możliwości są kosztowne.
Wykonawca, który potrafi opowiedzieć o swojej pomyłce, prawdopodobnie powie Ci też, gdy projekt zacznie się sypać. Ten drugi moment jest znacznie ważniejszy.
Pytania o rozliczenie
5. Co dokładnie zawiera ta kwota i czego w niej nie ma?
Wycena bez zakresu jest bezwartościowa. Poproś o rozbicie na etapy z terminami i o listę rzeczy wyraźnie wyłączonych: hosting, licencje, teksty, zdjęcia, integracje, szkolenie. Najczęstsze niespodzianki biorą się nie z tego, co w wycenie jest, tylko z tego, czego w niej nie było.
6. Jak wyceniacie zmiany w trakcie projektu?
Zmiany będą — to normalne. Nienormalne jest dowiadywanie się o ich koszcie z faktury. Ustal zasadę: każda zmiana zakresu wyceniana przed wykonaniem, na piśmie, z decyzją po Twojej stronie. Zapytaj też, co firma traktuje jako „drobną korektę w cenie", a co jako zmianę zakresu.
7. Jak wygląda harmonogram płatności?
Standard rynkowy to zaliczka 30–50% i reszta po odbiorze, a przy większych projektach podział na etapy powiązane z kamieniami milowymi. Żądanie 100% z góry jest sygnałem ostrzegawczym. Płatność w całości po wykonaniu też bywa podejrzana — zwykle oznacza, że koszt ryzyka jest wliczony gdzie indziej.
8. Ile kosztuje utrzymanie po wdrożeniu?
Zapytaj o to przed podpisaniem, nie po. Hosting, domena, opieka techniczna, stawka za prace poza abonamentem. Dla typowej aplikacji firmowej realny koszt utrzymania to kilkaset złotych rocznie plus opcjonalna opieka — jeśli słyszysz kwoty rzędu kilku tysięcy miesięcznie, dopytaj, co dokładnie za nie dostajesz.
Pytania, które chronią Cię po projekcie
9. Czy dostanę pełne prawa autorskie do kodu?
To musi być zapisane w umowie, a nie ustalone ustnie. Bez przeniesienia praw majątkowych możesz zapłacić za aplikację, której formalnie nie wolno Ci rozwijać u kogoś innego. Sprawdź też, czy przeniesienie obejmuje wszystkie pola eksploatacji i czy nie jest warunkowe.
10. Czy dostanę dostęp do repozytorium i infrastruktury?
Kod, baza danych, domena, hosting, konta w usługach zewnętrznych — wszystko powinno być zarejestrowane na Ciebie albo przekazane po zakończeniu. Klasyczna pułapka: domena zarejestrowana na wykonawcę „dla wygody", która staje się kartą przetargową przy rozstaniu.
11. Co się stanie, jeśli przestaniemy współpracować?
Zadaj to pytanie na pierwszym spotkaniu i obserwuj reakcję. Dobra odpowiedź opisuje procedurę: przekazanie kodu, dokumentacji i dostępów. Zła odpowiedź to zmiana tematu. Aplikacja, której nikt poza autorem nie potrafi rozwijać, to nie aktywo, tylko zobowiązanie.
12. Czy kod będzie udokumentowany i w jakim stopniu?
Nie potrzebujesz opasłej dokumentacji technicznej. Potrzebujesz tyle, żeby inny programista mógł przejąć projekt bez archeologii: opis architektury, instrukcja uruchomienia, wyjaśnienie nieoczywistych decyzji. Zapytaj, czy to wchodzi w cenę.
Sześć sygnałów, przy których warto się wycofać
- Wycena bez rozmowy o zakresie. Kwota podana w odpowiedzi na trzy zdania w mailu jest zgadywana. Albo zostanie zrewidowana w trakcie, albo zawiera ogromny bufor.
- Portfolio bez adresów. Same grafiki, żadnych działających wdrożeń.
- Presja czasowa. „Ta cena obowiązuje do piątku" przy projekcie na kilkadziesiąt tysięcy złotych to technika sprzedażowa, nie oferta.
- Brak pytań o Twój biznes. Jeśli wykonawca nie pyta, jak działa Twój proces, zbuduje to, co buduje zawsze.
- Obietnica bez zastrzeżeń. „Zrobimy wszystko" oznacza, że nikt nie przeanalizował, czy dana integracja jest w ogóle możliwa.
- Umowa bez klauzuli o prawach autorskich. Punkt bez dyskusji — bez tego nie podpisuj.
Wyślij wszystkim dokładnie ten sam opis procesu i poproś o rozbicie wyceny na etapy. Jeśli oferty różnią się kilkukrotnie, to zwykle nie kwestia stawek, tylko tego, że każda firma zrozumiała zakres inaczej. Wtedy dopytaj — różnica w rozumieniu zakresu jest ważniejsza niż różnica w cenie.
Jedna osoba, agencja czy software house?
| Freelancer | Mała agencja | Software house | |
|---|---|---|---|
| Koszt | Najniższy | Średni | Najwyższy |
| Kontakt | Bezpośrednio z wykonawcą | Zwykle opiekun projektu | Handlowiec, potem project manager |
| Ryzyko przy nieobecności | Wysokie | Średnie | Niskie |
| Elastyczność | Wysoka | Średnia | Niska |
| Duże, wieloletnie projekty | Trudne | Możliwe | Naturalne środowisko |
Uczciwie: pracuję sam, więc mam tu interes. Dlatego powiem też o minusie — jedna osoba to jeden punkt awarii. Jeśli zachoruję, projekt czeka. Rekompensuję to przekazywaniem kodu i dokumentacji na bieżąco, tak żeby dowolny programista mógł przejąć projekt, ale ryzyko nie znika i warto je uwzględnić przy dużych, krytycznych wdrożeniach.
W drugą stronę: przy projekcie za 20–50 tysięcy złotych software house często oznacza, że Twoje zlecenie jest u niego najmniejsze — z odpowiadającym temu priorytetem.
Trzy pytania, jeśli masz czas tylko na trzy
- „Pokażcie trzy działające wdrożenia z ostatniego roku." Weryfikuje kompetencje w minutę.
- „Co dokładnie zawiera ta kwota i czego w niej nie ma?" Eliminuje 90% późniejszych sporów.
- „Czy dostanę pełne prawa do kodu i dostęp do repozytorium?" Decyduje o tym, czy kupujesz aktywo, czy uzależnienie.
Jeśli chcesz sprawdzić te odpowiedzi u mnie — wszystkie moje wdrożenia mają adresy i działają na żywo, widełki cenowe są publiczne, a prawa do kodu przechodzą na klienta po ostatniej fakturze. Umów bezpłatną konsultację i zadaj mi te dwanaście pytań. Odpowiadam w 24 h w dni robocze.
Web developer z Warszawy. Buduję aplikacje webowe, systemy CRM i strony dla firm — od projektu po wdrożenie, bez podwykonawców.
