Ile kosztuje stworzenie dedykowanego systemu dla firmy w 2026 roku?

Pytanie, na które nie da się odpowiedzieć jednym zdaniem

„Ile kosztuje system dla firmy?” — to jedno z pierwszych pytań w niemal każdej rozmowie o nowym projekcie. Pytanie jest w pełni uzasadnione: trudno podjąć decyzję inwestycyjną, nie znając nawet rzędu wielkości. Uczciwa odpowiedź przypomina jednak odpowiedź na pytanie o koszt budowy domu. Inaczej wycenia się domek letniskowy, a inaczej budynek z garażem podziemnym, windą i własną kotłownią — choć jedno i drugie to „dom”.

Dedykowanego oprogramowania nie da się rzetelnie wycenić na podstawie jednego zdania. Da się natomiast dość szybko określić, czy mowa o projekcie za kilkadziesiąt, czy za kilkaset tysięcy złotych. Od ponad 10 lat zawodowo zajmuję się tworzeniem aplikacji dla firm i wielokrotnie widziałem, jak „prosta aplikacja” okazywała się po bliższym przyjrzeniu się znacznie większym projektem — i odwrotnie: jak rozbudowany pomysł dawał się sprowadzić do rozsądnej pierwszej wersji.

W tym artykule opisuję orientacyjne przedziały cenowe, czynniki, które najmocniej wpływają na koszt aplikacji, oraz sposób, w jaki przygotowujemy wycenę w Griff Software. Jeżeli decyzja o budowie własnego rozwiązania jeszcze nie zapadła, warto najpierw zastanowić się, czy w ogóle warto budować własne oprogramowanie — w wielu przypadkach gotowe narzędzie jest lepszym wyborem.

Orientacyjne przedziały cenowe

Poniższe kwoty to przykładowe widełki rynkowe, a nie cennik Griff Software ani oferta. Służą wyłącznie do zgrubnej orientacji — konkretna wycena zawsze wynika z zakresu konkretnego projektu.

Granice między przedziałami są umowne. Proste MVP z płatnościami online i aplikacją mobilną może trafić do drugiego przedziału, a system z kilkoma modułami, ale bez integracji, czasem zmieści się w pierwszym. Kwoty dotyczą wytworzenia i uruchomienia systemu — nie obejmują późniejszego utrzymania, hostingu ani dalszego rozwoju.

Podobnie jest z pytaniem, ile kosztuje aplikacja webowa. Portal klienta, panel administracyjny i wewnętrzny system do obsługi zleceń to wszystko aplikacje webowe, a ich koszty mogą różnić się kilkukrotnie. Rodzaje systemów, które realizujemy — od aplikacji webowych i portali, przez backend i API, po aplikacje mobilne i integracje — opisujemy na stronie Usługi.

Co wpływa na koszt oprogramowania?

Koszt aplikacji to w praktyce suma czasu potrzebnego na zaprojektowanie, zbudowanie, przetestowanie i uruchomienie każdej funkcji. Liczba ekranów mówi o tym zaskakująco mało. Poniżej czynniki, które najczęściej decydują o tym, w którym przedziale znajdzie się projekt.

Procesy, role i uprawnienia

Najprostszą miarą wielkości systemu jest liczba procesów biznesowych, które ma obsługiwać. Przyjmowanie zamówień to jeden proces. Przyjmowanie zamówień, planowanie realizacji, rozliczanie zleceń i obsługa reklamacji to cztery — a każdy z nich ma własne wyjątki, statusy i reguły.

Podobnie z rolami użytkowników. System, w którym wszyscy widzą wszystko, jest znacznie prostszy niż taki, w którym klient widzi tylko swoje zamówienia, handlowiec tylko swoich klientów, a kierownik wszystko poza danymi płacowymi. Każda rola oznacza osobne widoki, reguły dostępu i przypadki do przetestowania.

Logika działająca „pod spodem”

Formularz, który zapisuje dane w bazie, kosztuje niewiele. Formularz, który po zapisaniu sprawdza dostępność terminu, rezerwuje go, nalicza rabat zależny od historii klienta i uruchamia trzy kolejne czynności, kosztuje znacznie więcej — choć na ekranie wygląda tak samo. Większość kosztu systemu informatycznego dla firmy jest dla użytkownika niewidoczna: to reguły biznesowe, obliczenia, zadania wykonywane w tle i obsługa sytuacji wyjątkowych.

Do tej samej kategorii należy raportowanie, które bywa niedoszacowane. Lista z filtrem to kilka godzin pracy. Zestawienie łączące dane z kilku modułów, liczące wskaźniki w czasie i eksportowane do Excela w formacie wymaganym przez księgowość to osobne zadanie projektowe.

Integracje, płatności, e-mail i SMS

Każde połączenie z zewnętrznym systemem — programem księgowym, ERP, sklepem internetowym, systemem kurierskim — to dodatkowa praca, a jej koszt w dużej mierze zależy od drugiej strony. Dobrze udokumentowane API to zwykle kilka dni pracy. Starszy system bez API, z którym trzeba wymieniać pliki, może kosztować wielokrotnie więcej. Więcej o tym, jak podchodzimy do łączenia systemów, w opisie usługi integracje systemów.

Płatności online to nie tylko przycisk „zapłać”, ale też statusy transakcji, zwroty, płatności nieudane i powiązanie z fakturami. Z kolei samo wysłanie wiadomości e-mail czy SMS jest proste; więcej pracy wymagają szablony, harmonogramy wysyłki, obsługa błędów doręczenia i zgody na komunikację.

Aplikacja mobilna

Aplikacja mobilna to w praktyce dodatkowy produkt: osobny interfejs, publikacja w Google Play i App Store, powiadomienia push, a często także praca bez dostępu do internetu i późniejsza synchronizacja danych. Jeżeli użytkownicy korzystają z systemu głównie przy biurku, aplikacja webowa dobrze działająca na telefonie bywa wystarczająca — i wyraźnie tańsza.

Migracja danych

Przeniesienie danych z arkuszy lub starego systemu rzadko sprowadza się do jednego importu. Dane trzeba oczyścić, ujednolicić, uzupełnić brakujące powiązania i zdecydować, co zrobić z rekordami, które nie pasują do nowego modelu. Przy kilkuletniej historii prowadzonej w Excelu migracja potrafi być osobnym etapem projektu.

Bezpieczeństwo i testy

Dane osobowe, płatności czy dokumenty finansowe wymagają przemyślanego modelu uprawnień, rejestrowania operacji, szyfrowania i kopii zapasowych. Testy automatyczne podnoszą koszt wytworzenia, ale obniżają koszt każdej kolejnej zmiany. Bez nich każda modyfikacja niesie ryzyko, że coś przestanie działać w zupełnie innym miejscu systemu.

Projekt interfejsu (UX/UI)

Interfejs zbudowany ze sprawdzonych komponentów jest tańszy niż projekt graficzny tworzony od zera. W systemach wewnętrznych zwykle wystarcza czytelny i spójny interfejs. W portalu dla klientów lub produkcie sprzedawanym na rynku warto zainwestować więcej w projektowanie doświadczenia użytkownika, bo od niego zależy, czy klienci w ogóle zaczną z systemu korzystać.

Infrastruktura, wdrożenie i utrzymanie

System trzeba gdzieś uruchomić: na serwerze lub w chmurze, ze środowiskiem testowym, kopiami zapasowymi, monitoringiem i automatycznym procesem wdrażania. Po uruchomieniu pojawiają się koszty stałe — hosting, aktualizacje bezpieczeństwa, poprawki i rozwój. Warto od początku zarezerwować na nie budżet, bo system, który dobrze działa w firmie, niemal zawsze dostaje kolejne wymagania. Zakres takiej opieki opisujemy w usłudze modernizacja i utrzymanie.

Przykład: szkoła pływania, która wyrosła z Excela

Poniższy przykład jest fikcyjny — to zestawienie typowych potrzeb firmy usługowej, a nie opis realizacji dla konkretnego klienta.

Szkoła pływania prowadzi zajęcia dla dzieci i dorosłych w kilku grupach i na kilku basenach. Dziś działa w oparciu o:

• arkusz Excel z listą uczestników, grup i płatności;

• e-maile i telefony, przez które rodzice zapisują dzieci i zgłaszają nieobecności;

• SMS-y o odwołanych zajęciach, wysyłane ręcznie z prywatnego telefonu;

• papierowe umowy i zgody rodziców, przechowywane w segregatorach.

Właściciel chciałby mieć:

• bazę klientów i uczestników;

• grupy z poziomami zaawansowania i limitami miejsc;

• harmonogram zajęć z przypisanymi instruktorami i basenami;

• umowy i zgody akceptowane online;

• automatyczne wiadomości e-mail i SMS;

• zgłaszanie nieobecności i odrabianie zajęć.

Na pierwszy rzut oka to „strona z zapisami”. W rzeczywistości to system biznesowy, ponieważ:

• dane są ze sobą powiązane: uczestnik należy do grupy, grupa ma termin, instruktora i basen, a płatność dotyczy konkretnego okresu;

• obowiązują reguły: limity miejsc, lista rezerwowa, zasady odrabiania nieobecności, terminy płatności;

• są co najmniej trzy role — rodzic, instruktor i administrator — i każda widzi coś innego;

• umowy online wymagają wersjonowania treści, zapisu momentu akceptacji i bezpiecznego przechowywania dokumentów;

• automatyczne wiadomości wymagają szablonów, harmonogramów i obsługi zgód;

• dane z Excela trzeba przenieść i uporządkować.

Pełny zakres opisany powyżej zazwyczaj mieści się w przedziale średniego systemu. Wersja okrojona — baza uczestników, grupy, harmonogram i powiadomienia e-mail, bez płatności online i aplikacji mobilnej — może zmieścić się w przedziale MVP. Dodanie płatności, aplikacji mobilnej dla rodziców i integracji z programem księgowym przesuwa projekt wyżej.

Rozsądną strategią jest często podział na etapy: najpierw to, co dziś zabiera najwięcej czasu (zwykle grupy, harmonogram i powiadomienia), później umowy online, a na końcu płatności i aplikacja mobilna. Pierwsza wersja zaczyna oszczędzać czas, zanim powstanie cały system.

Stała cena czy rozliczenie za czas pracy?

Istnieją dwa podstawowe modele rozliczania projektów programistycznych. Żaden nie jest uniwersalnie lepszy — każdy sprawdza się w innych warunkach.

Fixed price (stała cena) oznacza kwotę ustaloną z góry dla precyzyjnie opisanego zakresu. Zaletą jest przewidywalny budżet. Warunkiem — dokładna specyfikacja przed startem, a każda zmiana w trakcie wymaga aneksu i dodatkowej wyceny. Wykonawca uwzględnia w cenie ryzyko niedoszacowania, więc stała cena bywa wyższa niż suma faktycznie przepracowanych godzin.

Time & Material (rozliczenie za czas pracy) oznacza płatność za faktycznie przepracowany czas, zwykle w ramach uzgodnionego budżetu orientacyjnego i z regularnym raportowaniem postępów. Zaletą jest elastyczność: priorytety można zmieniać w trakcie, a w cenie nie ma narzutu na ryzyko. Warunkiem — przejrzystość po stronie wykonawcy i aktywny udział po stronie zamawiającego.

W praktyce często sprawdza się podejście mieszane: stała cena za etap analizy, a następnie rozliczenie za czas pracy z ustalonym budżetem dla kolejnych etapów — albo stała cena dla dobrze opisanego pierwszego etapu i elastyczne rozliczanie dalszego rozwoju.

Kiedy warto zacząć od etapu analizy (discovery)?

Discovery, czyli warsztat analityczny, to krótki, osobno wyceniany etap przed właściwym programowaniem. Jego wynikiem są opis procesów, lista funkcji z priorytetami, model danych, makiety ekranów, plan etapów i wycena oparta na konkretach zamiast założeń.

Discovery ma sens, gdy system obejmuje kilka procesów lub działów, gdy planowane są integracje, gdy nie wiadomo jeszcze, które funkcje są niezbędne w pierwszej wersji, albo gdy budżet musi zatwierdzić zarząd na podstawie konkretnego dokumentu. Przy małym, jasno określonym projekcie ten etap można pominąć. Przebieg współpracy krok po kroku opisujemy na stronie Współpraca.

Dlaczego tania wycena może okazać się droga

Dwie wyceny tego samego projektu potrafią różnić się kilkukrotnie. Nie musi to oznaczać, że któraś strona zawyża cenę — częściej obie wyceny obejmują po prostu inny zakres. Niska kwota bywa wynikiem tego, że część pracy nie została w niej uwzględniona:

• Niekompletne wymagania — wycena obejmuje tylko podstawową ścieżkę, a wyjątki, uprawnienia i raporty wychodzą w trakcie projektu jako dodatkowo płatne zmiany.

• Brak testów — system działa w dniu odbioru, ale każda późniejsza zmiana psuje coś w innym miejscu.

• Słaba architektura — pierwsza wersja powstaje szybko, ale dodanie kolejnego modułu wymaga przebudowy fundamentów.

• Nieudokumentowany kod — tylko jedna osoba wie, jak działa system, a zmiana wykonawcy oznacza kosztowne odtwarzanie wiedzy.

• Brak automatycznego wdrażania — każda aktualizacja jest ręczną, ryzykowną operacją, którą odkłada się tak długo, jak to możliwe.

• Brak planu utrzymania — nikt nie odpowiada za aktualizacje bezpieczeństwa, kopie zapasowe ani monitoring.

Porównując oferty software house'ów, warto pytać nie tylko o cenę, ale też o to, co dokładnie się w niej mieści: testy, dokumentacja, wdrożenie, środowisko testowe, gwarancja, przekazanie kodu źródłowego i autorskich praw majątkowych.

Jak przygotowujemy wycenę w Griff Software

1. Rozmowa wstępna — 30–45 minut o tym, jaki problem ma rozwiązać system, kto będzie z niego korzystać i jak proces wygląda dzisiaj. Gotowa specyfikacja nie jest potrzebna.

2. Zrozumienie procesu biznesowego — przechodzimy przez proces krok po kroku: skąd przychodzą dane, kto je przetwarza, gdzie powstają błędy i opóźnienia, z jakimi systemami trzeba się połączyć.

3. Wstępny przedział cenowy — na tej podstawie podajemy rząd wielkości. Często już na tym etapie wiadomo, czy projekt ma sens w zakładanym budżecie — albo czy lepiej sprawdzi się gotowe narzędzie.

4. Discovery przy większych systemach — gdy zakres jest duży lub niejasny, proponujemy warsztat analityczny, po którym powstają specyfikacja, makiety i szczegółowy kosztorys.

5. Plan wdrożenia — dzielimy system na etapy tak, aby pierwsza użyteczna wersja trafiła do użytkowników możliwie wcześnie.

6. Development — praca w iteracjach trwających 1–2 tygodnie, z regularnym pokazywaniem działającego oprogramowania na środowisku testowym.

Przykłady wdrożonych projektów, wraz z opisem architektury i zastosowanych technologii, można znaleźć w zakładce Realizacje.

Podsumowanie

Koszt dedykowanego systemu dla firmy zależy przede wszystkim od liczby procesów, ról i integracji oraz od wymagań dotyczących jakości i bezpieczeństwa — a nie od liczby ekranów. Orientacyjnie: proste MVP to kilkadziesiąt tysięcy złotych, średni system biznesowy to zwykle od kilkudziesięciu do około 150 tysięcy złotych, a rozbudowane platformy kosztują więcej. Najbardziej wiarygodną wycenę daje rozmowa o konkretnym procesie, a przy większych projektach — krótki etap analizy.