Niemal każdy potencjalny klient zadaje w pewnym momencie jakąś wersję tego pytania, a każda uczciwa odpowiedź zaczyna się od słów „to zależy”. To nie jest wykręcanie się od tematu — koszt aplikacji webowej tworzonej na zamówienie może realnie wynosić od kilku tysięcy funtów aż po siedmiocyfrowe kwoty, a różnicę między tymi liczbami w całości tłumaczy zakres projektu, ryzyko i sposób jego realizacji. Zamiast podawać jedną liczbę, która bez kontekstu nic by nie znaczyła, warto raczej pokazać, jak samodzielnie oszacować, gdzie prawdopodobnie znajdzie się Twój projekt.
Zacznij od złożoności, nie od budżetu
Większość projektów tworzonych na zamówienie mieści się w jednej z trzech przybliżonych kategorii — i warto szczerze odpowiedzieć sobie, o którą z nich naprawdę pytasz, zanim zaczniesz zbierać wyceny.
- Prosty MVP lub narzędzie wewnętrzne: kilka głównych ekranów, podstawowe uwierzytelnianie, jedna lub dwie integracje, minimalny design na zamówienie. Coś w rodzaju formularza rezerwacji podpiętego pod bazę danych albo wewnętrznego panelu zastępującego arkusz kalkulacyjny.
- Aplikacja średniej klasy: kilka ról użytkowników, dopracowany system projektowy (design system), kilka integracji zewnętrznych (płatności, CRM, e-mail), umiarkowanie skomplikowana logika biznesowa oraz założenie dalszych iteracji po uruchomieniu.
- Budowa klasy enterprise lub w środowisku silnie regulowanym: złożone procesy, integracja z systemami legacy, ścisłe wymogi zgodności i bezpieczeństwa, wysokie wymagania co do dostępności oraz struktura realizacji obejmująca wiele zespołów.
Każdy kolejny stopień to nie liniowy wzrost kosztu — to bliżej wzrostu wykładniczego, bo złożoność mnoży się w obszarze designu, inżynierii, testów i kosztów koordynacji. Projekt, który wygląda jak „ta sama aplikacja, tylko z dwiema dodatkowymi funkcjami”, może naprawdę podwoić koszt, jeśli te funkcje dotykają uprawnień, integralności danych albo systemu zewnętrznego, nad którym nie masz kontroli.
Jeśli nie jesteś pewien, do której kategorii pasuje Twój projekt, to całkiem normalne — właśnie do tego służy rzetelna faza discovery. Każdą wycenę podaną przed doprecyzowaniem zakresu traktuj jako szacunek, nie zobowiązanie.
Wykonawca zmienia cenę tak samo mocno, jak sam projekt
To samo zapytanie może wygenerować bardzo różne wyceny w zależności od tego, kto je realizuje — a różnice nie sprowadzają się wyłącznie do stawki godzinowej.
- Zespół wewnętrzny: najwyższy koszt stały (wynagrodzenia, rekrutacja, koszty zarządzania, benefity), ale też największa kontrola długoterminowa i wiedza organizacyjna. Zwykle opłacalny tylko wtedy, gdy oprogramowanie jest kluczowym elementem bieżącej działalności firmy, a nie jednorazowym projektem.
- Agencja lub firma konsultingowa: rozwiązanie pośrednie — płacisz za zebrany zespół kompetencji, zarządzanie projektem i odpowiedzialność za wynik, bez kosztów utrzymania stałych pracowników. Stawki dzienne różnią się znacząco w zależności od regionu i specjalizacji, przy czym studia z Londynu zwykle są droższe niż zespoły z innych części Wielkiej Brytanii.
- Freelancerzy: często najtańsi w przeliczeniu na godzinę, ale ryzyko koordynacji bierzesz na siebie — samodzielnie szukasz, weryfikujesz, zarządzasz przekazywaniem zadań i uzupełniasz luki, jeśli ktoś w trakcie projektu przestaje być dostępny.
- Zespoły offshore lub nearshore: mogą obniżyć nominalne stawki dzienne, choć rzeczywista oszczędność mocno zależy od pokrywania się stref czasowych, kosztów komunikacji i tego, ile nadzoru musisz dołożyć po swojej stronie. Do każdej konkretnej wyceny oszczędności procentowej podchodź z rezerwą, dopóki nie sprawdzisz jej na realnym zadaniu.
Jeśli zamiast agencji lub pracowników angażujesz brytyjskich kontraktorów, warto wcześnie zasięgnąć porady w kwestii statusu IR35 — błędna klasyfikacja relacji roboczej może rodzić zobowiązania po stronie firmy zlecającej, a przepisy przesunęły odpowiedzialność w sposób, który zaskakuje osoby po raz pierwszy korzystające z pracy kontraktorów. To kwestia prawna i podatkowa, nie coś, co można wywnioskować z wpisu na blogu — sprawdź aktualne wytyczne na gov.uk lub porozmawiaj z księgowym, zanim zdecydujesz się na konkretną strukturę współpracy.
Cena stała, rozliczenie czasowe (time and materials), czy najpierw discovery?
Sposób komercyjnego ustrukturyzowania współpracy wpływa na Twoją ekspozycję na ryzyko równie mocno, jak na ostateczną fakturę.
- Cena stała: przewidywalna, ale sprawdza się dobrze tylko wtedy, gdy zakres jest naprawdę dobrze zdefiniowany od początku. Dostawcy wliczają w cenę bufor na nieznane, więc możesz zapłacić za ryzyko, które nigdy się nie zmaterializuje — albo zakres zostanie po cichu okrojony, by chronić marżę.
- Rozliczenie czasowe (time and materials): bardziej elastyczne i często korzystniejsze, jeśli wymagania będą ewoluować, ale wymaga zaufania i aktywnego zarządzania budżetem po Twojej stronie, bo bez oddzielnie uzgodnionego limitu nie ma naturalnej górnej granicy.
- Najpierw discovery: krótka, płatna faza mająca rzetelnie doprecyzować problem, zanim ustali się cenę za budowę. Kosztuje z góry, ale zwykle daje dużo dokładniejsze szacunki na dalszych etapach, bo większość przekroczeń budżetu ma źródło w zakresie, który nie został właściwie zrozumiany na etapie wyceny.
Dostawca, który upiera się przy fazie discovery, zanim poda stałą cenę budowy, nie robi trudności — zwykle stara się uniknąć dwóch scenariuszy, których nikt nie chce: zaniżonej wyceny, która rozpada się w trzecim miesiącu, albo zawyżonej, napompowanej po to, by pokryć niepewność, za którą i tak płacisz w jednej lub drugiej formie.
Cena budowy to nie cały koszt
Liczba, na której najczęściej skupiają się klienci, to koszt zbudowania pierwszej wersji. Rzadko kiedy to pełny obraz sytuacji. Rozmowa o budżecie powinna uwzględniać także pracę nad designem i UX przed rozpoczęciem developmentu, nakład pracy na QA i testy (który rośnie wraz z tym, jak poważne konsekwencje ma awaria aplikacji), koszty hostingu i infrastruktury, które ponosi się bezterminowo, opłaty za usługi zewnętrzne i integracje, a także bieżące utrzymanie po uruchomieniu aplikacji — łatki bezpieczeństwa, aktualizacje zależności, poprawki błędów i drobne, iteracyjne usprawnienia. Żadna z tych rzeczy nie jest opcjonalnym dodatkiem — to część posiadania oprogramowania, w przeciwieństwie do jednorazowego zakupu produktu.
Budowa to początek kosztów, a nie ich koniec.
Rozsądną — choć zmienną w zależności od projektu — regułą jest przyjęcie, że roczne koszty bieżącego utrzymania i hostingu stanowią znaczącą część pierwotnego kosztu budowy, a nie traktowanie wydatków po uruchomieniu jako marginalnej pozycji. Jeśli otrzymana wycena w ogóle nie porusza kwestii tego, co dzieje się po uruchomieniu, po prostu zapytaj — sam brak takiej rozmowy jest już informacją.
Jak realnie z tego skorzystać
Zamiast pytać „ile kosztuje aplikacja webowa”, spróbuj przeformułować pytanie pod kątem własnego projektu: w której kategorii złożoności realnie się on mieści, kto najlepiej nadaje się do jego realizacji, biorąc pod uwagę Twoją tolerancję na ryzyko i wewnętrzne zasoby, który model komercyjny pasuje do tego, jak dobrze doprecyzowane są dziś Twoje wymagania, oraz jaki jest całkowity koszt posiadania w perspektywie dwóch–trzech lat, a nie tylko faktura za pierwszą wersję. Każdy dostawca, z którym warto współpracować, powinien być gotów przejść z Tobą przez te rozważania, zanim padną konkretne liczby — i powinien od razu zaznaczyć, że wczesne szacunki są dokładnie tym, czym są: szacunkami, dopóki zakres nie zostanie właściwie zrozumiany.