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.
01 / KompetencjePytania 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.
02 / PieniądzePytania 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.
03 / PrawoPytania, 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ę.
04 / OstrzeżeniaSześć 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.
05 / FreelancerJedna 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.
06 / PodsumowanieTrzy 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.
Freelancer z Warszawy. Buduję szybkie strony, aplikacje webowe i systemy szyte na miarę - od projektu po wdrożenie. Zwolennik zasady „im mniej kodu, tym lepiej”.