3 sygnały z rynku, które razem układają się w jeden wyraźny obraz i kilka wniosków, które wyciągnęliśmy z własnych projektów.
AI zmienia sposób, w jaki software house’y wyceniają, sprzedają i dostarczają projekty. Tradycyjne modele rozliczenia (Time & Material), podejście do estymacji i definicja wartości firmy. Wszystkie 3 przestają działać tak jak dotychczas. W tym artykule pokazujemy, co konkretnie się zmienia i co zrobiliśmy z tym w fireup.pro.
Dlaczego model Time & Material przestaje działać w erze AI
Model Time & Material (T&M) rozlicza pracę w godzinach. Im szybciej działa zespół, tym mniej zarabia. AI przyspiesza pracę a to oznacza, że T&M strukturalnie nagradza wolne tempo i karze efektywność.
To napięcie widać coraz wyraźniej w rozmowach z klientami i partnerami: firmy, które postawiły na AI w codziennej pracy, zaczęły dostarczać więcej w krótszym czasie i natychmiast wpadły na problem. Stary model rozliczeń sprawia, że zysk z tej efektywności trafia do klienta, nie do zespołu. To nie jest błąd implementacji. To wada konstrukcyjna T&M.
Alternatywy zaczynają przebijać się do mainstreamu: stały budżet maksymalny z elastycznym zakresem, outcome-based pricing, modele hybrydowe. My w fireup.pro obserwujemy to samo napięcie po stronie klientów coraz częściej słyszymy pytania „co dokładnie dostaniemy za tę kwotę?” zamiast „ile godzin to zajmie?”. To nie jest przypadek. Godziny i wartość to dwie różne rzeczy.
Jak AI zmienia wycenę software house’ów przez inwestorów
Inwestorzy coraz rzadziej patrzą na liczbę programistów. Coraz częściej pytają: „co jest waszym produktem?”.
Na rynku pojawia się coraz więcej analiz, które wskazują na wyraźny trend: firmy z ustandaryzowanym delivery, własnym IP i przewidywalnym pipeline’em dostają wyższe mnożniki wyceny. Te, które żyją z body leasingu coraz niższe. AI spłaszcza przewagę „mamy dostępnych developerów”, bo z Copilotem i podobnymi narzędziami dostępni developerzy są wszędzie. Pytanie brzmi już nie „czy macie zasoby”, ale „co konkretnie budujecie i dla kogo”.
W fireup.pro naszym IP jest specjalizacja w regulated industries: znajomość MDR, HIPAA, HL7 FHIR, doświadczenie w środowiskach wymagających certyfikacji. Tego nie zastąpi generyczny zespół wspierany przez AI. Ale żeby to sprzedać i żeby inwestorzy lub klienci mogli to ocenić trzeba to najpierw nazwać. Wiele firm z naszego regionu ma już zalążki productized services. Po prostu tego nie widzi.
Jak estymować projekty AI – trzecia zmienna, której nie ma w arkuszach
W tradycyjnym IT estymujesz czas i funkcje. W projektach AI estymujesz czas, funkcje i dokładność modelu i ta trzecia zmienna jest najtrudniejsza do przewidzenia.
Dokładność modelu nie zależy tylko od zespołu. Zależy od jakości danych klienta a tę często odkrywasz dopiero po rozpoczęciu projektu. Audyt danych to regularnie pierwsza rzecz, która rozsadza ramy czasowe i budżet. Klient, który przychodzi z oczekiwaniem 100% accuracy, musi usłyszeć szczerą rozmowę o tym, że tego nikt nie zagwarantuje na etapie oferty.
Z naszego doświadczenia wynika jedna odpowiedź: podejście etapowe. PoC first, nie jako formalność, ale jako realna walidacja hipotezy technicznej i biznesowej. Każda faza odkrywa kolejne karty. Klient oczekujący fixed-price na pełne wdrożenie AI od pierwszego spotkania musi zrozumieć, że to nie jest wycena, to prognoza.
Co z tym zrobić – 3 zmiany, które warto wdrożyć teraz
Po pierwsze: przejrzyj model rozliczeniowy. Jeśli wciąż sprzedajesz wyłącznie godziny, masz strukturalny problem, bo AI sprawia, że godziny tańszeją.
Po drugie: nazwij swój produkt. Większość firm z regionu CEE ma już zalążki productized services nie widzi ich, bo nigdy ich nie nazwała. Specjalizacja branżowa, własne narzędzia, powtarzalne procesy delivery to jest IP, nie „zasoby ludzkie”.
Po trzecie: zmień podejście do estymacji projektów AI. Przestań estymować całość od razu. Zacznij od fazy discovery i PoC, które odkrywają kolejne karty i dopiero potem wyceniaj dalsze etapy.
Jeśli chcesz porozmawiać o tym, jak to wygląda w praktyce w projektach healthcare lub fintech – odezwij się.
