Ile naprawdę kosztuje oprogramowanie na zamówienie

Dostajesz trzy oferty. Jedna na 50 tysięcy, druga na 100 tysięcy, trzecia na 180 tysięcy. Wszystkie na to samo. Skąd masz wiedzieć, która jest właściwa?

Krótka odpowiedź: nie wiesz, bo nie kupujesz tego samego. I tu zaczyna się problem, który dręczy każdego, kto kiedykolwiek zamówił oprogramowanie na zamówienie.

Stawka godzinowa nic nie mówi

Najczęstszym wskaźnikiem porównawczym jest stawka godzinowa. Koder z firmy outsourcingowej za 150 zł/h wygląda taniej niż senior architekt za 500 zł/h. Ale to porównanie ma sens tylko wtedy, gdy wiesz, co każdy z nich wyprodukuje w ciągu godziny.

Senior architekt już w pierwszej wersji zaprojektuje model danych, który wytrzyma wzrost aplikacji przez trzy lata bez refactoru. Koder zaprojektuje go tak, jak mu się wydaje logiczne — a za rok zapłacisz za refactor, który będzie kosztować więcej niż oszczędność na stawce.

Stawka godzinowa to cena pracy. Wartość pracy to inna sprawa. Musisz znać obie.

Blended rate: średnia, która nic nie mówi

Agencje i większe zespoły często prezentują jedną stawkę za cały zespół — tzw. blended rate. To średnia po wszystkich rolach. Może wynosić 250 zł/h.

Tyle że 250 zł/h jako średnia z juniora za 150 zł/h i seniora za 400 zł/h mówi niewiele o tym, kto na twoim projekcie naprawdę decyduje. Jeśli architekt poświęcił na projekt systemu trzy dni, a resztę oddał juniorom bez nadzoru, zapłaciłeś średnią cenę za poniżejprzeciętny rezultat.

Właściwe pytanie nie brzmi „jaka jest wasza stawka godzinowa". Brzmi: kto recenzuje architekturę, kto podejmuje kluczowe decyzje, ile % czasu tej osoby dostanę?

Kiedy SaaS wystarczy, a kiedy nie

Istnieje oprogramowanie, którego nie ma sensu budować. Jeśli potrzebujesz fakturować, wysyłać maile, zbierać formularze albo przetwarzać płatności — dla każdej z tych rzeczy istnieje gotowy produkt za kilkadziesiąt złotych miesięcznie. Ma sens go użyć.

Punkt przełomowy następuje wtedy, gdy potrzebujesz, żeby to działało wewnątrz twojego systemu — nie obok niego.

Przykład: rozwiązanie SaaS do e-fakturowania w ramach KSeF poradzi sobie z wystawieniem faktury. Ale jeśli ta faktura musi powstać automatycznie z twojej bazy ERP, przejść przez workflow akceptacji, zapisać UPO (potwierdzenie od państwa) z powrotem do rekordu zamówienia i uruchomić zapis księgowy — produkt pudełkowy tu się zatnie. Albo tego nie potrafi, albo potrafi z taką liczbą kompromisów, że koszt integracji przewyższy oszczędność.

Pytanie przed każdą decyzją: potrzebuję tego jako izolowanego narzędzia, czy jako części procesu? Jeśli jako części procesu, policz integrację, a nie samą licencję.

Dlaczego cena fixed zawodzi

Cena fixed brzmi bezpiecznie. Wiesz, ile zapłacisz. Ryzyko bierze na siebie dostawca.

W teorii. W praktyce łamie się to w jednym miejscu: specyfikacja powstaje po ustaleniu ceny, nie przed.

Dostawca wycenia projekt na podstawie twojego słownego opisu. Potem pisze specyfikację. I dopiero tam po raz pierwszy okazuje się, co każdy rozumiał inaczej — jakie dane przyjdą ze starego systemu, kto akceptuje, co się dzieje przy błędzie, co system musi udźwignąć w styczniu, gdy naraz przyjdzie dziesięć tysięcy dokumentów.

Każdy punkt, w którym specyfikacja różni się od pierwotnego opisu, to spór. Albo dostawca go wchłonie i oszczędzi na jakości, albo przyśle ci zmianę zakresu. Jedno i drugie jest złe.

Rozwiązaniem jest odwrócenie kolejności. Najpierw specyfikacja, potem cena. Nazywa się to podejściem spec-first i to jedyny sposób, w jaki cena fixed ma sens. Specyfikacja to pracochłonny dokument — ale to właśnie ten dokument, za który płacisz, bo z niego potem wiesz dokładnie, co dostaniesz.

Trzy modele cenowe

T&M (czas i materiał): Płacisz za przepracowane godziny. Przejrzysty, elastyczny na zmiany, ale bez sufitu. Odpowiedni, gdy nie wiesz dokładnie, czego chcesz — albo gdy wiesz, że to będzie się zmieniać.

Fixed scope: Płacisz za rezultat, nie za godziny. Działa tylko wtedy, gdy masz gotową specyfikację przed startem. Każda zmiana w trakcie to nowa runda negocjacji.

FLEX: Mniej popularny model, ale w niektórych sytuacjach ma sens. Płacisz etapami albo jako udział w osiągniętych rezultatach (na przykład w oszczędności, która powstała w sposób udowodniony). Klient jest właścicielem kodu od pierwszego dnia, żadnego vendor lock-in. Dostawca ma interes w rezultacie, nie w maksymalizacji godzin. Sprawdza się tam, gdzie rezultat da się zmierzyć.

Każdy model ma sens w innych warunkach. Jeśli firma zaoferuje ci tylko jeden — bez wyjaśnienia dlaczego — pytaj.

Ile naprawdę kosztuje tańszy wariant

Najtańsza oferta prawie nigdy nie jest najtańszym projektem.

Sekwencja jest przewidywalna: szybka implementacja, brak architektury, brak testów. Rok działa. Potem dodajesz funkcję i psuje się coś innego. Przychodzi nowy programista, orientuje się trzy tygodnie, potem dokłada swój kod obok starego. Po trzech latach masz aplikację, w której nikt nie chce w niczym grzebać, bo nikt nie wie, co to zepsuje.

Rework nadejdzie. Pytanie tylko, czy za rok, czy za trzy. A rework całej aplikacji kosztuje więcej niż zrobienie tego dobrze za pierwszym razem.

Ten rachunek mało kto robi z wyprzedzeniem, bo rework jest w przyszłości, a oszczędność jest teraz.

O co pytać, zanim podpiszesz

Kilka pytań, które oszczędzą ci nerwów:

• Kto projektuje architekturę i ile % jego czasu dostanę?
• Macie doświadczenie z tym typem integracji, czy będziecie to robić pierwszy raz?
• Jak wygląda specyfikacja, na podstawie której wyceniacie? Czy mogę ją zobaczyć przed podpisem?
• Co się stanie, gdy w trakcie pojawi się nowy wymóg? Jak go obsłużycie?
• Kto jest właścicielem kodu i dokumentacji po zakończeniu projektu?

Dobry dostawca odpowie na te pytania bez wahania. Zły zmieni temat.

---

FAQ

Dlaczego wyceny tak się różnią?

Bo każdy wycenia inny projekt. Bez szczegółowej specyfikacji każdy wycenia swoje wyobrażenie o tym, co usłyszał. Jeden liczy proste REST API, drugi pełnotekstowe wyszukiwanie i audit log. Zakres się różni, więc różni się i cena. Jedyną drogą do porównywalnych ofert jest dostarczenie wszystkim oferentom tego samego wejścia — czyli specyfikacji.

Kiedy SaaS, a kiedy custom?

SaaS ma sens, dopóki oprogramowanie istnieje obok twoich procesów — jako narzędzie, które otwierasz, używasz i zamykasz. Gdy tylko potrzebujesz, żeby było głęboko powiązane z twoim ERP, przepływami danych, procesem akceptacji albo raportowaniem, SaaS się zatnie. Koszty integracji i kompromisy w designie łatwo wtedy przewyższają cenę rozwiązania custom. Policz całkowity koszt posiadania za trzy lata, nie samą licencję.

Co to jest model FLEX?

FLEX to model cenowy, w którym płacisz stopniowo — etapami albo jako udział w mierzalnym rezultacie (oszczędność czasu, zmniejszenie błędowości, zautomatyzowany wolumen). Klient od początku jest właścicielem kodu, dzięki czemu odpada vendor lock-in. Dostawca ma bezpośrednie powiązanie z rezultatem, nie z liczbą godzin. Sprawdza się tam, gdzie rezultat jest mierzalny, a obie strony ufają sobie na tyle, by ustalić metrykę z wyprzedzeniem.