Przejdź do treści
Codivine
Oprogramowanie

Ile kosztuje oprogramowanie na zamówienie?

Od czego zależy koszt projektu oprogramowania na zamówienie, jak czytać wycenę i dlaczego pozycja „utrzymanie” jest ważniejsza niż budowa.

Marta Szymczak3 min czytania

Każdy, kto podaje kwotę, zanim zrozumie Twój proces, zgaduje — a za to zgadywanie zapłacisz później, w zleceniach zmian albo w cięciu kosztów tam, gdzie tego nie widać. Uczciwie da się natomiast wyjaśnić, co wpływa na kwotę.

Pięć prawdziwych czynników kosztowych

1. Reguły biznesowe, a nie ekrany

Formularz jest tani. Formularz, którego pola zmieniają się zależnie od typu klienta, walidacja zależy od stanu magazynu, a powyżej progu uruchamiane są inne akceptacje — już nie. Przy wycenie liczymy reguły i wyjątki, bo tam jest praca.

Najwyraźniejszy sygnał drogiego projektu to zdanie zaczynające się od „zwykle działa to tak, poza sytuacją, gdy…”.

2. Role i uprawnienia

Jeden typ użytkownika jest prosty. Pięć ról z różną widocznością, prawami edycji i uprawnieniami do akceptacji mnoży zarówno budowę, jak i testy. Każda kombinacja musi działać poprawnie, a „poprawnie” często znaczy „zgodnie z prawem”.

3. Integracje

Każdy zewnętrzny system to mały projekt: uwierzytelnianie, mapowanie danych, obsługa błędów, ponawianie i ktoś, z kim da się porozmawiać, gdy coś się zepsuje. Nowoczesne, udokumentowane API to dzień lub dwa. Stary system z eksportem plików i bez wsparcia to dwa tygodnie i trwałe zobowiązanie do utrzymania.

4. Migracja danych

Przeniesienie ze starego systemu do nowego jest notorycznie niedoszacowane. Prawdziwe dane są bardziej chaotyczne, niż ktokolwiek pamięta: duplikaty, brakujące pola, wartości, które znaczą co innego zależnie od tego, kiedy je wpisano.

5. Wymagania pozafunkcjonalne

Oczekiwana dostępność, historia zmian, obowiązki wynikające z RODO, szyfrowanie, zasady przechowywania danych, dostępność dla osób z niepełnosprawnościami. Każde jest uzasadnione. Każde kosztuje. Powinny być określone na starcie, a nie odkryte podczas przeglądu bezpieczeństwa dwa tygodnie przed wdrożeniem.

Jak czytać wycenę

Dobra wycena:

  • jest przedziałem, a nie jedną liczbą, i mówi, co przesunęłoby kwotę na każdy z jego końców;
  • oddziela analizę, budowę, migrację i wdrożenie;
  • równie jasno wymienia to, czego nie obejmuje, jak to, co obejmuje;
  • pokazuje testy i zarządzanie projektem jako widoczne pozycje, zamiast je ukrywać;
  • podaje założenia, które da się sprawdzić.

Niepokojąca wycena: jedna liczba, zero założeń, brak etapu analizy i stawka godzinowa bez górnego limitu. To nie cena, tylko zaproszenie.

Cena stała czy rozliczenie za czas?

Oba modele są w porządku; błędem jest użycie niewłaściwego.

Cena stała działa, gdy zakres jest naprawdę znany — zwykle po etapie analizy. Masz pewność; wykonawca wycenia ryzyko, więc płacisz za nie premię. Zmiany wymagają formalnych zleceń.

Rozliczenie za czas i materiały działa, gdy coś dopiero badasz albo priorytety będą się zmieniać. Jest tańsze, gdy relacja jest dobra, i katastrofalne, gdy nie jest.

My wolimy: krótki, płatny etap analizy, a potem stałą cenę za określony zakres. Na koniec masz specyfikację, z którą możesz pójść do kogoś innego — i uważamy, że to właściwa motywacja, pod którą powinniśmy działać.

Pozycja, która ma największe znaczenie

Roczne utrzymanie na poziomie mniej więcej 15–25% kosztu budowy. Obejmuje hosting, aktualizacje zależności i bezpieczeństwa, zmiany w integracjach, gdy dostawca coś zmieni, naprawy błędów i drobne ulepszenia.

Firmy, które to pomijają, nie oszczędzają — tylko odkładają wydatek i płacą więcej później, gdy trzy lata zaległych aktualizacji trzeba zrobić naraz, zwykle w pośpiechu.

Gdzie pieniądze naprawdę się marnują

  • Budowanie od razu wersji trzeciej. Funkcje wyspecyfikowane, zanim ktokolwiek użył wersji pierwszej.
  • Przeinżynierowanie pod skalę, której nie ma. Projektowanie pod milion użytkowników przy stu to realny i częsty podatek.
  • Przepisywanie zamiast rozbudowy. Przepisywanie wyrzuca rozwiązane problemy, o których zapomniano, że je rozwiązano.
  • Pomijanie analizy. Najtańsza godzina w projekcie to ta, w której ktoś odkrywa, że wymaganie było błędne.

Jak dostać kwotę dla swojego projektu

Przynieś proces, a nie listę funkcji: co dzieje się dziś krok po kroku, kto to robi, ile to trwa i gdzie się sypie. Na tej podstawie w ciągu tygodnia podamy przedział, a po krótkiej analizie — stałą cenę.

Opisz nam proces albo najpierw przeczytaj, jak prowadzimy projekty oprogramowania.

Marta Szymczak

Sprzedaż i opieka nad kluczowymi klientami

Twoja osoba kontaktowa we wszystkich sprawach handlowych — zakres, komunikacja i pilnowanie, żeby projekt odpowiadał temu, czego firma naprawdę potrzebuje.

Więcej o zespole

Potrzebujesz w tym pomocy?

To jest praca, którą wykonujemy. Te strony wyjaśniają, jak do niej podchodzimy.

Masz podobny problem?

Opisz go własnymi słowami. Powiemy, co byśmy z nim zrobili — i czy w ogóle warto się tym zajmować.

Nie potrzebujesz specyfikacji. Opis problemu wystarczy, żeby zacząć.