Ile kosztuje stworzenie aplikacji — rachunek zamiast widełek

Masz na biurku trzy wyceny tej samej aplikacji: 18 000 zł, 60 000 zł i 210 000 zł. Wszystkie od firm, które wyglądają poważnie. Pierwszy odruch to szukać w internecie, ile „powinna” kosztować aplikacja — i tu zaczyna się kłopot, bo odpowiedzi, której szukasz, nie ma. Nie dlatego, że nikt jej nie policzył, tylko dlatego, że w Polsce nie istnieje publiczny benchmark cen wytworzenia oprogramowania. Wszystko, co znajdziesz, to cenniki sprzedających.

Ten tekst nie doda kolejnych widełek do tego zbioru. Zamiast tego pokazuje rachunek, który możesz odtworzyć sam: skąd bierze się stawka godzinowa, dlaczego dwie oferty na to samo różnią się trzykrotnie, ile naprawdę kosztuje aplikacja po uruchomieniu i co musi zawierać wycena, żebyś mógł ją z czymkolwiek porównać. Liczby, które podajemy, mają podane źródło i datę. Tam, gdzie źródła nie ma, piszemy mechanizm zamiast liczby.

Dlaczego nikt nie poda Ci ceny aplikacji?

Bo nie ma czego podać. Nie istnieje instytucja ani organizacja branżowa, która publikowałaby ceny wytworzenia oprogramowania w Polsce — a to zupełnie co innego niż brak danych o branży IT w ogóle.

GUS publikuje wynagrodzenia. W comiesięcznej informacji o sytuacji społeczno-gospodarczej kraju znajdziesz przeciętne wynagrodzenie brutto w sekcji „Informacja i komunikacja” — w lipcu 2026 roku było to 15 334,67 zł wobec 9 509,02 zł w całym sektorze przedsiębiorstw (GUS, publikacja 25 sierpnia 2026). To dane o tym, ile zarabiają ludzie, a nie o tym, ile kosztuje projekt. Ceny wytworzenia oprogramowania nie są przedmiotem żadnej publikacji statystyki publicznej.

Organizacje branżowe też ich nie publikują. Software Development Association Poland ma w zakładce z raportami cztery pozycje — trzy edycje „Barometru Nastrojów Branży IT” i opracowanie o sprzedaży firm (sprawdzone 22 września 2026). Żadne z nich nie jest cennikiem ani rate cardem.

Zostają cenniki wykonawców. I tu widać, dlaczego nie da się z nich zrobić średniej. Dwa polskie serwisy publikują dziś ceny za tę samą etykietę. aplikacje-mobilne.biz wycenia aplikację „podstawową” na 4 000–19 000 zł. itcraftapps.com wycenia aplikację „prostą” na 30 000–100 000 zł. Dolna granica jednego cennika i dolna granica drugiego różnią się 7,5 razy. Żaden z nich nie podaje daty pomiaru, próby ani tego, co dokładnie mieści się w słowie „prosta”.

Warto też zobaczyć, co te cenniki mają wspólnego. Czytając kilkanaście polskich stron z cenami aplikacji, znajdziesz wszędzie tę samą konstrukcję: trzy przedziały nazwane „prosta”, „średnia” i „złożona”, pod nimi lista czynników wpływających na cenę, a w tytule bieżący rok. Rok w tytule jest sygnałem świeżości tekstu, nie datą pomiaru — pod spodem nie ma ani liczby obserwacji, ani okresu zbierania danych, ani definicji kategorii. Trudno się dziwić: te strony są materiałem sprzedażowym i nie mają obowiązku być badaniem.

To nie jest przypadek ani nieuczciwość jednej ze stron. To jest dowód, że słowo „prosta aplikacja” nie ma znaczenia, które dałoby się wycenić. Dopóki nie wiesz, ile ekranów, ile ról użytkowników, ile integracji i czyj czas jest w cenie, obie liczby są równie prawdziwe — opisują dwa różne produkty pod jedną nazwą.

Wniosek dla kupującego jest praktyczny, nie filozoficzny: przestań szukać ceny rynkowej, zacznij porównywać zakresy. Reszta tego tekstu pokazuje, jak to zrobić.

Z czego naprawdę składa się cena

Cena aplikacji to iloczyn trzech rzeczy: stawki, czasu i zakresu. Zakres opisuje Twoje wymagania, czas wynika z zakresu, a stawka jest jedyną liczbą, którą da się wyprowadzić z danych publicznych. Zróbmy to.

Krok 1: ile kosztuje miesiąc pracy jednej osoby

Największy portal ogłoszeniowy z obowiązkowymi widełkami publikuje raz w roku mediany tych widełek. W „Rynku pracy IT w Polsce 2025/2026” — ósmej edycji, opartej na ogłoszeniach opublikowanych między 1 stycznia a 31 grudnia 2025 roku — senior fullstack na kontrakcie B2B ma medianę dolnych widełek 23 520 zł i górnych 28 560 zł netto miesięcznie, plus VAT. Backend: 22 680–28 000. Frontend: 20 160–26 840. Mobile: 21 840–26 880. DevOps: 25 000–30 000. Testowanie: 20 160–25 000.

Dwa zastrzeżenia, które raport No Fluff Jobs podaje sam. Po pierwsze, to są kwoty z ogłoszeń, czyli deklaracje pracodawcy, a nie podpisane umowy — autorzy raportu zbadali to osobno i podają, że 71% osób otrzymało wynagrodzenie mieszczące się w widełkach z ogłoszenia, a 11% wyższe. Po drugie, to mediany widełek, nie mediana zarobków.

Niezależny pomiar inną metodą daje ten sam rząd wielkości. Bulldogjob nie czyta ogłoszeń, tylko pyta pracujących: w ankiecie prowadzonej od 15 stycznia do 16 lutego 2025 roku, na 4 331 odpowiedziach po weryfikacji jakości, mediana kontraktu B2B w całym IT wyniosła 20 800 zł, a dla seniorów 24 000 zł.

Krok 2: przeliczenie na godzinę

Przyjmijmy miesiąc roboczy 168 godzin, czyli 21 dni po 8 godzin. To założenie, nie fakt — możesz je podmienić i przeliczyć wszystko od nowa. Przy tym założeniu 23 520 zł daje około 140 zł za godzinę, a 28 560 zł około 170 zł. To jest stawka, po której pracuje sam programista, przy stu procentach godzin rozliczonych klientowi.

Krok 3: dlaczego oferta firmy jest wyższa

Nikt nie fakturuje stu procent swojego czasu. Rekrutacja, urlopy, chorobowe, spotkania sprzedażowe, przestoje między projektami, wewnętrzne przeglądy kodu — to wszystko jest czasem opłaconym, ale niesprzedanym. Załóżmy rozliczalność na poziomie 70% — to nasze założenie do tego rachunku, a nie dane rynkowe, i warto zapytać wykonawcę o jego własną. Przy takiej rozliczalności te same 140–170 zł staje się 200–243 zł za godzinę kosztu własnego. I to wciąż jest przed doliczeniem kierownika projektu, testera, administratora infrastruktury i jakiegokolwiek zysku.

Stąd biorą się stawki, które widzisz w ofertach. To nie jest marża, to jest arytmetyka. Nasza własna stawka to 220 zł za godzinę dla rynku polskiego — podajemy ją jako nasze założenie mieszczące się w powyższym przedziale, a nie jako stawkę rynkową, bo takiej nikt nie zmierzył.

Krok 4: dlaczego dwie oferty różnią się trzykrotnie

Zauważ, co wyszło z tego rachunku: stawka waha się mniej więcej dwukrotnie, od 140 do niecałych 300 zł za godzinę. Jeśli więc dostajesz wyceny różniące się trzy- albo dziesięciokrotnie, to różnica nie leży w stawce. Leży w liczbie godzin, czyli w zakresie.

To jest jedyne pytanie, które warto zadać wszystkim oferentom naraz: ile godzin zakładacie i na co. Oferta, która nie umie na nie odpowiedzieć, nie jest tańsza — jest nieokreślona.

Ile to kosztuje w praktyce

Skoro publicznego benchmarku nie ma, zrobiliśmy własny. Nasz raport o kosztach aplikacji webowych opiera się na 118 obserwacjach cenowych z 92 podmiotów, zebranych od marca do maja 2026 roku. W próbie jest 58 software house'ów, 10 agencji interaktywnych, 14 publikatorów benchmarków cenowych, 7 publikatorów cenników SaaS i 2 freelancerów.

Dwie liczby z tego raportu mają próbę na tyle dużą, żeby coś znaczyć:

Pozostałe kategorie w raporcie mają od dwóch do siedmiu obserwacji i celowo ich tutaj nie cytujemy — mediana z trzech liczb nie jest medianą, tylko środkową liczbą z trzech.

Podajemy liczbę obserwacji przy każdej medianie nie z pedanterii, tylko dlatego, że bez niej mediana jest nie do sprawdzenia. Dobrze to widać na przykładzie, który raport zgłasza sam: kategoria „pełna aplikacja” wypada w nim niżej niż kategoria „średnia złożoność”, co jest arytmetycznie możliwe tylko wtedy, gdy obie nazwy oznaczają w cennikach różne rzeczy. To ta sama choroba, co w akapicie o „prostej aplikacji” — etykiety nie mają wspólnej definicji, więc porównuje się je na własne ryzyko.

Jak z tego korzystać? Mediana MVP na poziomie 30 000 zł mówi, że jeśli Twoje wymagania mieszczą się w jednej ścieżce użytkownika i dostajesz wycenę na 8 000 zł, to prawdopodobnie kupujesz coś innego, niż myślisz. A jeśli dostajesz 150 000 zł — albo Twój projekt nie jest MVP, albo rozmawiasz z kimś, kto wycenia inny zakres. W obu przypadkach odpowiedź brzmi „dopytaj o zakres”, nie „negocjuj cenę”.

Nasze ceny i co za nimi stoi

Teraz część, w której musimy być bardzo precyzyjni, żeby nie wyszło, że sami sobie przeczymy. Mediana 30 000 zł za MVP to rynek, zmierzony na cudzych cennikach. Nasza linia cenowa wygląda tak: Lean MVP od 10 000 zł, MVP od 30 000 zł — a ostateczna kwota zawsze wynika z indywidualnej wyceny. Aplikacja standard startuje u nas od 145 000 zł, a system enterprise od 500 000 zł.

To, że nasze „od 30 000 zł” pokrywa się z medianą rynku, nie znaczy, że liczymy to samo co cenniki. Mediana rynkowa to liczba nagłówkowa z cennika — kwota, od której zaczyna się rozmowa. U nas pozycje zwykle pomijane w cennikach są osobnymi, widocznymi liniami: faza discovery z badaniem i makietami kosztuje przy MVP dodatkowe 8 000 zł, hosting w chmurze zarządzanej to 400 zł miesięcznie, dyżur techniczny z SLA — 1 500 zł miesięcznie, a każda integracja z systemem zewnętrznym 8 000 zł. Nasz kalkulator pokazuje wynik jako przedział ±15%, bo tyle wynosi uczciwa niepewność na etapie briefu.

Nie jest więc tak, że płacisz u nas za „więcej funkcji” niż w ofercie z cennika. Jest tak, że reszta rachunku jest wypisana od początku, zamiast dopisana później.

Żeby było jasno: nie twierdzimy, że nasza cena jest ceną rynku, ani że mediana rynku jest tym, co u nas zapłacisz. To dwie różne liczby, mierzone dwoma różnymi sposobami, i obie są w tym tekście po to, żebyś umiał je od siebie odróżnić w każdej ofercie, którą dostaniesz.

Co realnie podnosi koszt, a co nie

Po przeliczeniu kilkudziesięciu projektów widać, że budżet rozjeżdża się zawsze w tych samych miejscach — i prawie nigdy tam, gdzie klient się tego spodziewa.

Integracje z cudzymi systemami. Każde połączenie z zewnętrznym systemem — płatnościami, ERP, kurierem, systemem księgowym — to osobna praca: uwierzytelnienie, mapowanie danych, obsługa błędów drugiej strony i testy na środowisku, którego nie kontrolujesz. W naszym kalkulatorze to 8 000 zł za sztukę i jest to pozycja, która najczęściej mnoży się w trakcie projektu.

Role i uprawnienia. „Administrator widzi wszystko, użytkownik swoje” to jedna reguła. Pięć ról z częściowo nachodzącymi się uprawnieniami to macierz, którą trzeba zaprojektować, zaimplementować i przetestować w każdej kombinacji. To zwykle różnica między aplikacją a systemem.

Migracja danych. Dane z poprzedniego systemu nigdy nie są czyste. Duplikaty, braki, trzy formaty daty i pola używane niezgodnie z nazwą to praca, której nie widać w demo i której nie da się wycenić bez obejrzenia bazy.

Zgodność i audyty. Wymogi formalne potrafią przewyższyć koszt samej aplikacji. W naszej konfiguracji poziomy zgodności typu SOC 2, ISO 27001, HIPAA czy PCI to od 80 000 do 140 000 zł jednorazowo i dodatkowo od 2 000 do 4 000 zł miesięcznie. Jeśli Twoja branża tego wymaga, to jest pierwsza pozycja do ustalenia, nie ostatnia.

Tempo. Według danych z naszego kalkulatora skrócenie harmonogramu o 30% podnosi cenę o 40%, a o połowę — dwukrotnie. Nie dlatego, że ktoś korzysta z Twojego pośpiechu, tylko dlatego, że równoległa praca większego zespołu wymaga więcej koordynacji na jednostkę efektu.

Twój własny czas. Najrzadziej liczona pozycja, bo nie pojawia się na żadnej fakturze. Brief, warsztaty, odbiory, testy akceptacyjne, decyzje, na które czeka zespół — to godziny kogoś z Twojej firmy. Projekt, w którym po Twojej stronie nie ma osoby z czasem na decyzje, kosztuje więcej niezależnie od stawki wykonawcy, bo przestoje też są płatne.

A teraz to, co wbrew obiegowej opinii nie jest głównym motorem kosztu. Wybór technologii — o ile mieścisz się w rozwiązaniach powszechnie używanych — zmienia budżet w granicach kilku procent, bo stawki specjalistów w popularnych stosach są zbliżone, co widać w tabelach No Fluff Jobs. „Ładniejszy” interfejs też nie: praca projektowa rośnie z liczbą różnych ekranów i stanów, a nie z tym, jak bardzo dopracowany jest jeden z nich. Jeżeli czyjaś oferta różni się od pozostałych o 200% i tłumaczy to technologią albo jakością designu — to nie jest wyjaśnienie różnicy w zakresie.

Ile kosztuje aplikacja po uruchomieniu

To jest pytanie, na które najczęściej dostaniesz odpowiedź w procentach. „Utrzymanie to 15–20% wartości projektu rocznie” albo „przyjmuje się 20%” — ten drugi wariant znajdziesz choćby w cenniku, który cytowaliśmy wyżej. Szukaliśmy źródła pierwotnego tej reguły i go nie ma. Są za to blogi cytujące inne blogi, z rozrzutem od 10% do 30%, bez ani jednej próby, metodologii czy okresu pomiaru. Nasze własne teksty też podawały cztery różne wartości w czterech miejscach — dlatego w tym artykule nie znajdziesz ani jednego procentu utrzymania.

Zamiast procentu: rachunek z pozycji. Zacznijmy od tej, którą najłatwiej sprawdzić.

Serwer jest najtańszą linią tego rachunku. W cenniku OVHcloud maszyna wirtualna z 2 rdzeniami, 4 GB pamięci i 40 GB dysku NVMe kosztuje 16,32 zł netto miesięcznie, a mocniejsza — 8 rdzeni, 24 GB pamięci, 200 GB dysku — 85,08 zł netto, w obu przypadkach z codzienną kopią zapasową i ochroną przed atakami wolumetrycznymi w standardzie. Dwadzieścia parę do stu złotych miesięcznie. Jeśli ktoś tłumaczy Ci opłatę za utrzymanie kosztem serwera, właśnie zobaczyłeś, ile ten serwer kosztuje.

Opłaty sklepów są stałe i publiczne. Apple Developer Program to 99 USD za rok członkostwa, przy czym cena w złotówkach pokazywana jest dopiero w procesie rejestracji, więc nie podajemy przeliczenia. Konto dewelopera w Google Play to 25 USD jednorazowo — nie rocznie. Korygujemy tu własną liczbę: w starszym naszym artykule widnieje „400 zł (Google) i 500 zł rocznie (Apple)”. Pierwsza z nich jest zawyżona kilkukrotnie.

Cała reszta to czyjaś praca. I tu przydaje się podział, który wprowadza norma ISO/IEC/IEEE 14764 — opublikowana 21 stycznia 2022 roku, opisująca utrzymanie oprogramowania jako proces iteracyjny, z planowaniem zaczynającym się jeszcze w trakcie wytwarzania. Utrzymanie dzieli się w niej na cztery rodzaje: korekcyjne (naprawa błędów wykrytych po wdrożeniu), adaptacyjne (dostosowanie do zmian w otoczeniu — nowa wersja systemu operacyjnego, zmienione API dostawcy płatności, nowy przepis), perfekcyjne (poprawa wydajności i łatwości utrzymania) i prewencyjne (usuwanie problemów, zanim się ujawnią). Norma jest opisem procesu, nie cennikiem — i to jest właśnie powód, dla którego nie wynika z niej żaden procent.

Praktyczny rachunek wygląda więc tak: hosting plus domena, kopie zapasowe o określonej częstotliwości, monitoring dostępności i wydajności, aktualizacje zależności w ustalonym rytmie, czas reakcji na awarię zapisany w umowie serwisowej, a osobno budżet na zmiany wymuszone z zewnątrz. Nasz własny model utrzymania liczy dokładnie tak — kwotami miesięcznymi za każdą z tych pozycji, bez odwoływania się do wartości projektu. Umowa serwisowa, która podaje jedną kwotę i słowo „opieka”, nie mówi Ci, za co płacisz.

Jak czytać wycenę, którą dostałeś

Skoro różnica między ofertami leży w zakresie, to porównywalne są tylko te wyceny, które zakres opisują. Dobra wycena ma cztery części i po ich braku poznasz, że dostałeś cennik zamiast oferty.

Ostatni wiersz jest najważniejszy, bo tam mieszka większość konfliktów. W rozliczeniu ryczałtowym (fixed-price) masz z góry znany budżet i mniejsze ryzyko niespodzianki, ale każda zmiana zakresu wymaga aneksu — a im sztywniejsza umowa, tym większy bufor wykonawca wliczy w cenę. W rozliczeniu godzinowym (time and material) płacisz za faktycznie przepracowany czas i możesz zmieniać kierunek w trakcie, ale to Ty pilnujesz, żeby zakres nie rósł bez końca. Częsty kompromis to ryczałt na zdefiniowany rdzeń i godziny na wszystko poza nim.

Pytania, które warto zadać każdemu oferentowi tym samym zdaniem:

• Ile godzin zakładacie i jak rozkładają się na etapy?
• Co konkretnie jest poza zakresem tej kwoty?
• Czy testy i poprawki błędów są w cenie, czy rozliczane osobno?
• Do kogo należy kod źródłowy i gdzie będzie trzymany?
• Jaki jest czas reakcji na awarię po wdrożeniu i ile kosztuje?

I słowo o ofertach wyraźnie tańszych od reszty. Nie chodzi o to, że taniej znaczy gorzej — chodzi o to, że po stronie wykonawcy obowiązuje ta sama arytmetyka z sekcji o stawce. Jeśli cena jest o rząd wielkości niższa, to albo zakres jest inny, albo w cenie nie ma testów, dokumentacji i wsparcia, albo ktoś policzył projekt z błędem, który wyjdzie w trakcie — i to jest wariant najgorszy, bo poprawiać go będziecie oboje.

Od czego zacząć

Zacznij od najmniejszej wersji, która rozwiązuje jeden prawdziwy problem — czyli od MVP. Nie dlatego, że jest tańsza o jakiś procent (tego nikt nie zmierzył), tylko dlatego, że to jedyny sposób, żeby dowiedzieć się, czego naprawdę potrzebujesz, zanim zapłacisz za wersję pełną. Zakres, którego nie umiesz opisać, jest najdroższą rzeczą w tym rachunku.

Praktycznie: wypisz ścieżkę użytkownika krok po kroku, zaznacz, gdzie aplikacja musi rozmawiać z innym systemem, policz role i powiedz, które dane trzeba przenieść ze starego rozwiązania. Z tym dokumentem możesz iść po wyceny, które da się porównać.

Wróćmy do trzech wycen z początku. Mając taki dokument, zadaj wszystkim trzem oferentom to samo pytanie o liczbę godzin i o wyłączenia, a potem porównaj odpowiedzi, nie kwoty. W dziewięciu przypadkach na dziesięć okaże się, że rozjazd siedzi w trzech albo czterech konkretnych pozycjach — integracje, role, migracja, wsparcie po wdrożeniu — i po ich wyrównaniu oferty schodzą się na tyle, że decyzja przestaje być loterią.

Jeśli chcesz najpierw zobaczyć rząd wielkości, kalkulator kosztu aplikacji webowej pokaże wynik razem z pozycjami, z których się składa. Po drodze warto przeczytać, jak wygląda proces po stronie wykonawcy i co przygotować przed startem. Jeśli rozważasz aplikację na telefon, koszty tej rodziny opisujemy osobno w tekście o tworzeniu aplikacji mobilnych. A jeśli wolisz porozmawiać o konkretnym zakresie, robimy takie systemy na zamówienie.