Jak wycenić gotowy SaaS bez przychodów?

Gotowy SaaS bez przychodów nie jest automatycznie wart zero. Nie można go jednak wycenić tak jak działającej firmy abonamentowej, ponieważ nie ma potwierdzonego ARR, marży ani retencji, do których dałoby się zastosować mnożnik. Wartość trzeba zbudować z odpowiedzi na trzy pytania:

1. Ile kosztowałoby dziś odtworzenie produktu o tej samej użyteczności?
2. Jakie są dowody, że produkt może zacząć generować przepływy pieniężne?
3. Jaką korzyść osiągnie konkretny kupujący, przejmując produkt zamiast budować go samodzielnie?

Najbardziej obronny wynik zwykle nie jest jedną liczbą. To przedział oparty na kilku metodach, wraz z opisem założeń, ryzyk i tego, co dokładnie przechodzi na kupującego.

Ten artykuł dotyczy sprzedaży gotowego produktu, jego aktywów albo spółki, która nie osiągnęła jeszcze przychodów. Nie dotyczy wyceny pre-money przy rundzie inwestycyjnej. Wycena inwestora obejmuje cenę kapitału, prawa przypisane do poszczególnych klas udziałów i oczekiwaną ścieżkę kolejnych rund; cena zakupu produktu lub firmy odpowiada innemu pytaniu. Tekst jest przewodnikiem do wstępnej kalkulacji, a nie indywidualną opinią z wyceny ani poradą prawną lub podatkową.

1. Najpierw zdefiniuj „gotowy” i „bez przychodów”

Produkt jest gotowy do wyceny jako działający SaaS, jeżeli można go uruchomić, przetestować i przekazać bez ponownego budowania podstawowych funkcji. Sam kod w repozytorium nie wystarcza. W praktyce kupujący będzie sprawdzał między innymi:

• działanie kluczowej ścieżki użytkownika w środowisku produkcyjnym;
• panel administracyjny, płatności, monitoring, kopie zapasowe i obsługę błędów;
• dokumentację architektury, wdrożenia i utrzymania;
• możliwość przekazania domen, kont chmurowych, analityki, kanałów marketingowych i integracji;
• prawa do kodu, projektu, treści, marki i baz danych;
• zależność produktu od założyciela, wykonawców oraz zewnętrznych usług.

„Bez przychodów” powinno znaczyć, że na dzień wyceny nie ma rozpoznanego przychodu ani płacących umów. Bezpłatne konta, pilotaże, lista oczekujących i listy intencyjne mogą być ważnymi dowodami popytu, ale nie są MRR ani ARR. Jeżeli istnieją płatne wdrożenia, przedpłaty lub podpisane odpłatne umowy, trzeba je opisać oddzielnie i sprawdzić, czy rzeczywiście mogą przejść na nabywcę.

Na początku ustal także przedmiot transakcji:

• sprzedaż aktywów — kupujący przejmuje uzgodnione prawa, kod, markę, domenę, dokumentację i inne składniki;
• sprzedaż udziałów lub akcji — kupujący przejmuje spółkę wraz z jej aktywami, umowami, zobowiązaniami i historią;
• licencja — właściciel zachowuje prawa i udziela kupującemu uprawnienia do korzystania z produktu w określonym zakresie.

To rozróżnienie wpływa na zakres badania, ryzyko i cenę. Polski KSWS „Ogólne zasady wyceny przedsiębiorstw” wymaga określenia celu, przedmiotu, założeń i standardu wartości, a w raporcie także daty wyceny. Bez tych elementów dwie osoby mogą wyceniać pod nazwą „SaaS” zupełnie inne rzeczy.

2. Zbuduj drabinę dowodów, zanim zbudujesz model

Przy braku przychodów największym ryzykiem nie jest dokładność arkusza, lecz brak dowodu, że ktoś będzie chciał zapłacić za produkt. Dlatego najpierw uporządkuj fakty od najsłabszych do najmocniejszych.

Dowody techniczne

• prototyp lub makiety;
• działające MVP;
• produkt wdrożony produkcyjnie;
• stabilny produkt z monitoringiem, dokumentacją i powtarzalnym procesem wdrożenia;
• niezależny audyt kodu, bezpieczeństwa lub infrastruktury.

Dowody popytu

• deklaracje z rozmów i ankiet;
• zapisy na listę oczekujących;
• aktywni użytkownicy bezpłatni i ich powroty do produktu;
• pilotaż z określonym zakresem, terminem i kryteriami sukcesu;
• list intencyjny, z rozróżnieniem postanowień wiążących i niewiążących;
• podpisana odpłatna umowa, nawet jeżeli świadczenie i przychód zaczną się później.

Liczba kont bez kontekstu niewiele mówi. Dla każdego sygnału pokaż źródło, datę, grupę użytkowników i zachowanie: ilu użytkowników aktywowało kluczową funkcję, ilu wróciło po tygodniu lub miesiącu, ilu zakończyło pilotaż i ilu zadeklarowało gotowość zakupu po konkretnej cenie.

Wytyczne IPEV z 2025 roku wskazują, że w przypadku inwestycji seed i early stage, które nie mają bieżących ani bliskich dodatnich przepływów, często stosuje się analizę kamieni milowych albo scenariuszy. Wśród istotnych przesłanek wymieniają między innymi akceptację produktu przez klientów, testy, wejście na rynek, sytuację konkurencyjną i zapotrzebowanie na dalsze finansowanie. IPEV dotyczy wartości godziwej inwestycji, a nie bezpośrednio ceny sprzedaży małego SaaS, ale dobrze pokazuje, dlaczego samo stwierdzenie „produkt jest gotowy” nie wystarcza.

3. Marka, społeczność i obecni użytkownicy

SaaS może nie mieć jeszcze przychodu, a jednocześnie posiadać aktywa, które skracają drogę do pierwszej sprzedaży: rozpoznawalną nazwę, domenę z ruchem organicznym, newsletter, profile społecznościowe oraz grupę użytkowników produktu. Nie należy jednak łączyć ich w jedną pozycję pod nazwą „zasięg”. Każdy element daje inny rodzaj korzyści i podlega innym ograniczeniom.

• Marka obejmuje nazwę, oznaczenia, reputację i skojarzenia, które mogą wpływać na decyzje klientów. Znak towarowy albo domena mogą być przedmiotem praw, ale sama rejestracja nie dowodzi jeszcze, że marka generuje wartość ekonomiczną.
• Kanały i społeczność dają możliwość dotarcia do określonej publiczności. Obserwujący nie są własnością firmy, a ich liczba nie mówi, ilu zobaczy komunikat, przejdzie na stronę lub kupi produkt.
• Użytkownicy produktu dostarczają dowodów na użyteczność i popyt. Konto utworzone rok temu, aktywna firma korzystająca co tydzień oraz uczestnik odpłatnego pilotażu nie mogą mieć tej samej wagi.
• Dane i relacje mogą pomagać w komercjalizacji tylko w zakresie, w jakim kupujący może je zgodnie z prawem przejąć i dalej wykorzystywać.

Jak ocenić markę

ISO 10668 wymaga, aby pieniężna wycena marki określała między innymi cel, podstawę wyceny, zastosowane podejście, dane i założenia. Marka nie powinna więc otrzymać arbitralnej premii za atrakcyjną nazwę lub liczbę publikacji. Trzeba wskazać korzyść ekonomiczną, którą może osiągnąć nabywca.

Według wyjaśnienia ISO dotyczącego oceny marek ich wpływ ekonomiczny może przejawiać się w wyższej cenie, niższych kosztach, większej sprzedaży albo lojalności klientów. W SaaS bez przychodów nie da się jeszcze potwierdzić premii cenowej ani powtarzalnych zakupów, dlatego warto szukać wcześniejszych dowodów:

• liczby wyszukiwań nazwy i udziału ruchu bezpośredniego;
• ruchu organicznego kierowanego na strony związane z problemem rozwiązywanym przez produkt;
• reakcji klientów na nazwę w badaniach, rozmowach i pilotażach;
• reputacji marki, wzmianek oraz ewentualnych sporów lub ryzyk wizerunkowych;
• praw do nazwy, domen, identyfikacji, tekstów i materiałów;
• zależności rozpoznawalności od osobistego profilu założyciela.

Ostatni punkt jest szczególnie ważny. Jeżeli odbiorcy śledzą konkretną osobę, a nie produkt, ich uwaga może nie przejść wraz z transakcją. Wycena powinna wtedy uwzględnić plan komunikacji, okres wsparcia założyciela i ryzyko spadku zasięgu po zmianie właściciela.

Jak ocenić social media, newsletter i ruch

Sama liczba obserwujących jest słabym dowodem. przewodnik Komisji Europejskiej dotyczący social mediów wskazuje, że nie istnieje jeden miernik pozwalający ocenić ich wpływ. Zaleca łączenie danych ilościowych i jakościowych, takich jak kliknięcia, reakcje, udostępnienia, profil odbiorców, ruch i sentyment.

Dla każdego kanału przygotuj eksport danych za spójny okres, najlepiej obejmujący co najmniej kilka cykli sprzedażowych. Kupujący powinien zobaczyć:

Newsletter należy analizować podobnie: liczba aktywnych adresów, źródło zapisu, wypisy, dostarczalność, kliknięcia i przejścia do produktu są ważniejsze niż łączna liczba rekordów. Trzeba też udokumentować treść zgód i podstawę dalszego kontaktu po transakcji.

Jak ocenić aktualną bazę użytkowników

Liczba zarejestrowanych kont powinna być początkiem analizy, a nie mnożnikiem wyceny. W modelu warto pokazać co najmniej:

• liczbę użytkowników i firm, które wykonały kluczową czynność aktywacyjną;
• retencję kohort, czyli ilu użytkowników wraca po określonym czasie;
• częstotliwość użycia funkcji, która realizuje główną obietnicę produktu;
• udział kont nieaktywnych, testowych, zduplikowanych i podejrzanych;
• wyniki pilotaży oraz przyczyny ich zakończenia;
• przejście od rejestracji do rozmowy o cenie, listu intencyjnego lub umowy;
• w B2B: liczbę aktywnych organizacji, użytkowników w organizacji i rolę osób podejmujących decyzję.

Dobór okresu musi odpowiadać sposobowi używania produktu. Miesięczna aktywność może mieć sens dla narzędzia księgowego, ale zaniży użyteczność aplikacji uruchamianej raz na kwartał. Definicję „aktywnego użytkownika” trzeba powiązać z konkretnym zdarzeniem w produkcie i stosować konsekwentnie we wszystkich kohortach.

Jak przełożyć te dowody na wartość

Marki, społeczności i użytkowników nie należy automatycznie wyceniać jako liczba × stawka. Bardziej obronna procedura wygląda następująco:

1. zbuduj bazowy scenariusz bez korzyści z istniejących kanałów;
2. na podstawie udokumentowanych danych oszacuj, czy kanały skracają czas wejścia na rynek, obniżają koszt pozyskania albo zwiększają prawdopodobieństwo konwersji;
3. przelicz wartość scenariuszy po zmianie tych założeń;
4. pokaż różnicę jako wpływ dowodów dotyczących marki i dystrybucji;
5. zastosuj korektę, jeżeli kanał, prawa lub dane nie mogą zostać skutecznie przekazane.

Nie dodawaj tej różnicy drugi raz jako osobnej „wartości marki”, jeśli wyższa konwersja i niższy koszt pozyskania są już ujęte w prognozowanych przepływach. Byłoby to podwójne liczenie tej samej korzyści.

Przenoszalność trzeba sprawdzić osobno dla każdej platformy. Przekazanie hasła nie zastępuje zmiany właściciela lub administratora zgodnej z regulaminem. Przykładowo umowa użytkownika LinkedIn zabrania przekazywania konta osobistego i połączeń, natomiast YouTube opisuje procedurę zmiany głównego właściciela kanału połączonego z kontem marki. Lista profili powinna więc zawierać typ konta, właściciela, administratorów, sposób przekazania i ryzyko utraty treści lub dostępu.

4. Cztery perspektywy wyceny

A. Koszt zastąpienia funkcjonalności

Podejście kosztowe nie pyta, ile założyciel wydał w przeszłości. Pyta, ile racjonalny uczestnik rynku musiałby wydać na dzień wyceny, aby uzyskać rozwiązanie o porównywalnej użyteczności.

W przypadku oprogramowania ważniejszy jest koszt zastąpienia funkcji niż koszt przepisania tych samych linii kodu. IVSC definiuje podejście kosztowe przez ekonomiczną zasadę, zgodnie z którą kupujący nie zapłaci więcej niż koszt uzyskania aktywa o tej samej użyteczności, chyba że znaczenie mają również czas, niedogodność, ryzyko lub inne czynniki. Najnowszy raport EUIPO o finansowaniu opartym na własności intelektualnej podkreśla zarazem, że wydatki poniesione na stworzenie aktywa mogą nie odpowiadać jego wartości ekonomicznej.

Praktyczny rachunek obejmuje:

1. zakres funkcji, które należałoby odtworzyć;
2. aktualny nakład pracy przy najbardziej efektywnym wiarygodnym sposobie realizacji, z uwzględnieniem AI, gotowych komponentów i usług zarządzanych, a nie historycznych kosztów założyciela;
3. projekt, testy, zarządzanie, konfigurację infrastruktury, dokumentację i bezpieczne wdrożenie;
4. koszt czasu potrzebnego do osiągnięcia porównywalnej gotowości;
5. korekty za dług techniczny, przestarzałe rozwiązania, brak dokumentacji, ryzyka bezpieczeństwa i ograniczenia licencji.

Koszt zastąpienia bywa użytecznym punktem odniesienia dla gotowego produktu bez trakcji. Nie jest gwarantowaną ceną minimalną. Jeżeli kupujący nie potrzebuje produktu albo może osiągnąć ten sam efekt taniej, rynek nie zwróci sprzedającemu wszystkich poniesionych nakładów.

Co AI zmienia w koszcie zastąpienia

Generowanie kolejnych linii kodu stało się bardzo tanie, a przy standardowym SaaS część implementacji może wykonać jedna osoba wspierana przez agentów AI, gotowy starter oraz zarządzane usługi płatności, uwierzytelniania i hostingu. Wycena sporządzona na podstawie liczebności tradycyjnego zespołu albo historycznej liczby roboczogodzin może więc istotnie zawyżać aktualny koszt zastąpienia.

Nie ma jednak rzetelnej podstawy do stosowania jednego „dyskonta AI”. przegląd OECD z 2025 roku opisuje duże wzrosty produktywności w wybranych eksperymentach programistycznych, ale wskazuje też różnice zależne od doświadczenia oraz fakt, że większa liczba linii kodu nie musi oznaczać większej wartości. W opublikowanym w 2026 roku badaniu obejmującym 4867 programistów dostęp do asystenta AI zwiększył średnią liczbę ukończonych zadań o 26,08%, przy większym efekcie wśród mniej doświadczonych osób.

Wynik nie jest uniwersalny. Eksperyment METR przeprowadzony na początku 2025 roku wykazał 19-procentowe spowolnienie doświadczonych twórców pracujących we własnych, dużych repozytoriach. aktualizacja METR z lutego 2026 roku sugeruje poprawę przy nowszych agentach, ale autorzy uznali oszacowanie jej skali za obciążone istotnymi błędami doboru próby. DORA w raporcie z 2025 roku opisuje AI jako wzmacniacz istniejącego procesu: szybsze tworzenie kodu przynosi wartość wtedy, gdy firma ma odpowiednie testy, przeglądy, bezpieczeństwo i platformę wdrożeniową.

Dlatego w modelu AI-native warto rozdzielić:

• wytworzenie kodu, którego koszt krańcowy może być bardzo niski;
• zdefiniowanie produktu i architektury, czyli ustalenie, co system ma robić i jakie przypadki brzegowe obsłużyć;
• integrację, w tym płatności, uwierzytelnianie, dane, e-maile i zależności zewnętrzne;
• weryfikację, obejmującą testy, bezpieczeństwo, wydajność i zgodność;
• uruchomienie oraz przekazanie, czyli infrastrukturę, monitoring, kopie zapasowe, dokumentację i usunięcie zależności od twórcy.

Jeżeli kupujący potrafi odtworzyć te elementy za pomocą AI i gotowych usług w kilka tygodni, wycena powinna korzystać właśnie z tego niższego kosztu. Sam fakt, że pierwotny zespół pracował nad produktem rok, nie tworzy przewagi ekonomicznej.

B. Scenariusze ważone prawdopodobieństwem

Jeżeli istnieją dowody popytu, można oszacować wartość oczekiwanych korzyści w kilku rozłącznych scenariuszach. Każdy scenariusz powinien zawierać:

• czas i koszt potrzebny do rozpoczęcia sprzedaży;
• liczbę klientów oraz cenę, które mają oparcie w testach lub rozmowach;
• koszty pozyskania, wdrożenia, obsługi i dalszego rozwoju;
• churn albo prawdopodobny czas korzystania z produktu;
• dodatkowe finansowanie potrzebne przed osiągnięciem dodatnich przepływów;
• wartość produktu w razie niepowodzenia;
• prawdopodobieństwo scenariusza oparte na dostępnych dowodach.

Wartość oczekiwana ma postać:

Wartość = suma (prawdopodobieństwo scenariusza × wartość bieżąca w tym scenariuszu)

Najpierw oszacuj wartość bieżącą przepływów w każdym scenariuszu, a dopiero potem zastosuj prawdopodobieństwa. Ryzyka uwzględnione w scenariuszach nie powinny zostać drugi raz mechanicznie doliczone przez arbitralne podniesienie stopy dyskontowej. Przy dużej niepewności pokaż analizę wrażliwości: jak wynik zmieni się po opóźnieniu sprzedaży, niższej cenie lub dodatkowym koszcie rozwoju.

IPEV ostrzega, że przy braku istotnych przychodów, zysków lub dodatnich przepływów metoda mnożnika zysku jest na ogół nieodpowiednia, a DCF może służyć jako sprawdzenie tylko wtedy, gdy ma wiarygodne wsparcie w innych danych. Prognoza nie staje się dowodem wyłącznie dlatego, że została zdyskontowana.

C. Porównania rynkowe

Porównania mogą pomóc, lecz dla gotowego SaaS bez przychodów są zwykle najsłabszą samodzielną metodą. Nie istnieje mianownik dla EV/ARR, jeżeli ARR wynosi zero. Zastosowanie mnożnika do prognozowanego przychodu jest możliwe jedynie jako element scenariusza, po sprawdzeniu prawdopodobieństwa osiągnięcia tej prognozy i kosztu dojścia do niej.

Do porównania mogą nadawać się:

• sprzedaże podobnych produktów lub praw do oprogramowania;
• transakcje dotyczące firm na takim samym etapie produktu i komercjalizacji;
• ceny licencji na podobną technologię;
• rzeczywista, niedawna oferta zakupu od niezależnego podmiotu;
• runda finansowania, jeżeli jej warunki, prawa inwestora i okoliczności są znane.

Każdy z tych punktów wymaga korekt za zakres aktywów, etap, geografię, jakość technologii, prawa własności, strukturę transakcji i datę. Wycena z rundy nie jest automatycznie ceną sprzedaży: inwestor kupuje określony instrument, często z dodatkowymi prawami, a pieniądze zwykle trafiają do spółki i finansują jej dalszy rozwój.

Na polskim rynku problemem jest również dostępność danych. raport CMT Advisory i Fordata o transakcjach IT zidentyfikował 29 polskich transakcji od października 2024 do września 2025 roku, w tym 12 dotyczących SaaS. W tabeli dla większości transakcji nie podano wartości pakietu ani mnożników. Nawet dane o działających firmach nie tworzą więc reprezentatywnego „polskiego mnożnika” dla produktu bez przychodów.

D. Wartość strategiczna dla kupującego

Konkretny kupujący może zapłacić więcej niż typowy uczestnik rynku, jeżeli przejęcie:

• skróci wejście na rynek;
• pozwoli uniknąć kosztu i ryzyka własnego projektu;
• uzupełni istniejący produkt lub kanał sprzedaży;
• udostępni technologię, zespół, domenę lub prawa trudne do odtworzenia;
• zablokuje kosztowny brak w jego ofercie.

Taką wartość można oszacować przez model „z zakupem i bez zakupu”. Od korzyści kupującego odejmij koszt integracji, migracji, koniecznych poprawek i utrzymania. Wynik jest granicą ekonomicznej opłacalności dla tego kupującego, a nie automatyczną ceną. Część synergii zazwyczaj pozostaje po jego stronie, ponieważ to on wnosi bazę klientów, markę, zespół sprzedaży albo kapitał.

Nie mieszaj tej perspektywy z wartością rynkową. Jeżeli tylko jeden nabywca potrafi wykorzystać produkt w wyjątkowy sposób, mówimy o wartości specyficznej dla tego nabywcy.

5. Co naprawdę przechodzi na kupującego

Gotowy produkt ma wartość tylko wtedy, gdy nabywca może legalnie i operacyjnie z niego korzystać. Repozytorium kodu nie dowodzi jeszcze własności praw.

Tekst jednolity polskiej ustawy o prawie autorskim i prawach pokrewnych ogłoszony w Dz.U. 2025 poz. 24 stanowi, że programy komputerowe podlegają ochronie jak utwory literackie, a umowa przenosząca autorskie prawa majątkowe wymaga formy pisemnej pod rygorem nieważności. Umowa powinna też wyraźnie wskazywać pola eksploatacji. Przy współpracy z programistami B2B sama faktura, dostęp do GitHuba albo zapłata za pracę nie zastępują sprawdzenia umów.

Przed wyceną przygotuj:

• listę wszystkich twórców kodu, projektu, tekstów i materiałów;
• umowy o pracę, umowy z wykonawcami i dokumenty przeniesienia praw;
• rejestr komponentów open source wraz z licencjami i obowiązkami;
• wykaz domen, znaków towarowych, kont i licencji na narzędzia z informacją o możliwości cesji;
• architekturę, instrukcję wdrożenia, klucze i proces bezpiecznego przekazania dostępów;
• spis danych oraz podstaw ich przetwarzania;
• listę wad, długu technicznego, incydentów i koniecznych aktualizacji.

European IP Helpdesk wskazuje, że przy transakcji technologicznej błędy w zakresie własności lub ochrony IP mogą obniżyć wycenę albo zablokować transakcję. Wymienia wprost kontrolę umów dotyczących oprogramowania, poufności i wcześniejszych licencji. Dla komponentów open source przydatnym punktem odniesienia jest ISO/IEC 5230 opisany przez OpenChain, który porządkuje proces zgodności z licencjami.

Dane użytkowników nie są zwykłym składnikiem magazynowym

Baza użytkowników może potwierdzać trakcję i pomagać w analizie produktu, ale danych osobowych nie można traktować jak swobodnie zbywalnego pliku. RODO wymaga zgodności z prawem, ograniczenia celu, minimalizacji i bezpieczeństwa przetwarzania. Trzeba ustalić role stron, podstawę prawną przekazania i dalszego użycia, obowiązki informacyjne oraz zgodność nowego celu z celem, dla którego dane zebrano.

Europejska Rada Ochrony Danych w stanowisku dotyczącym fuzji podkreśla potrzebę pełnej oceny skutków połączenia dla ochrony danych i przejrzystego wypełnienia obowiązków wynikających z RODO. Jeżeli transfer lub dalsze wykorzystanie danych jest wątpliwe, nie przypisuj bazie pełnej wartości w scenariuszu sprzedaży.

6. Przykład wyceny w PLN

Poniższy przykład jest fikcyjny i pokazuje mechanikę. Kwoty, stawki oraz prawdopodobieństwa nie są benchmarkiem dla polskiego rynku.

Załóżmy, że wyceniany jest B2B SaaS z działającym środowiskiem produkcyjnym, dokumentacją i 20 firmami w bezpłatnym pilotażu. Nie ma płacących klientów. Dwanaście firm użyło kluczowej funkcji w co najmniej trzech z ostatnich czterech tygodni, a trzy podpisały niewiążące listy intencyjne z proponowaną ceną. Produkt ma także 4800 obserwujących na profilach firmowych i 1350 subskrybentów newslettera. Dane analityczne z ostatnich 12 miesięcy przypisują siedem zgłoszeń do pilotażu kanałom własnym, ale nie ma jeszcze umowy sprzedażowej.

Krok 1: koszt zastąpienia

Przykład zakłada niewielki produkt o typowych procesach B2B, bez branży regulowanej i bez nietypowych wymagań wydajnościowych. Kupujący może użyć dojrzałego startera SaaS, usług zarządzanych oraz jednego doświadczonego programisty pracującego z agentami AI. Nie odtwarza ręcznie każdej linii kodu. Szacuje, że uzyskanie porównywalnej, sprawdzonej użyteczności wymagałoby dziś:

• analizy produktu, architektury i UX: 12 000 zł;
• implementacji wspomaganej AI oraz integracji: 38 000 zł;
• testów, bezpieczeństwa, infrastruktury, wdrożenia i dokumentacji: 30 000 zł;
• narzędzi, usług i środowisk potrzebnych w okresie budowy: 5 000 zł.

Łączny koszt zastąpienia wynosi 85 000 zł. Audyt wykazuje jednak konieczność poprawy autoryzacji oraz uzupełnienia dokumentacji dwóch integracji. Kupujący szacuje te prace na 15 000 zł.

85 000 − 15 000 = 70 000 zł

Kwota 70 000 zł jest wskazaniem z podejścia kosztowego. Nie jest ceną minimalną ani zwrotem nakładów poniesionych przez założyciela. Przy prostszym produkcie lub kupującym posiadającym własny zespół i komponenty wielokrotnego użytku koszt może być jeszcze niższy. Produkt z nietypowymi integracjami, wymaganiami bezpieczeństwa albo złożoną migracją danych może kosztować więcej mimo wykorzystania AI.

Krok 2: scenariusze

Następnie powstają trzy rozłączne scenariusze. Wartości w ostatniej kolumnie są już wartościami bieżącymi na dzień wyceny, po uwzględnieniu kosztów komercjalizacji i czasu.

11 250 + 56 000 + 67 500 = 134 750 zł

Wartość oczekiwana wynosi 134 750 zł. Nie oznacza to, że transakcja powinna zostać zawarta dokładnie za tę kwotę. Wynik jest szczególnie wrażliwy na 15-procentowe prawdopodobieństwo sukcesu i wartość scenariusza korzystnego. W arkuszu trzeba pokazać, co stanie się po zmniejszeniu tego prawdopodobieństwa do 10%, opóźnieniu sprzedaży o sześć miesięcy albo wzroście kosztów pozyskania klientów.

Krok 2a: wpływ marki, kanałów i użytkowników

Wagi 45%, 40% i 15% można obronić tylko wtedy, gdy aktywność pilotów, źródła zgłoszeń oraz możliwość przekazania kanałów zostały zweryfikowane. Sama liczba 4800 obserwujących i 1350 subskrybentów nie uzasadnia tych prawdopodobieństw.

Załóżmy, że podczas due diligence nie udało się potwierdzić źródeł ruchu, profile zależą od osobistego konta założyciela, a powtarzalne użycie produktu wykazuje tylko sześć firm. Analityk zmienia wtedy prawdopodobieństwa na 50% dla niepowodzenia, 38% dla umiarkowanego wzrostu i 12% dla sukcesu, pozostawiając wartości scenariuszy bez zmian:

50% × 25 000 + 38% × 140 000 + 12% × 450 000 = 119 700 zł

Różnica między 134 750 zł a 119 700 zł wynosi 15 050 zł. W tym modelu pokazuje ona wpływ potwierdzonej aktywności użytkowników i dystrybucji na ryzyko komercjalizacji. Nie jest uniwersalną wyceną społeczności ani kwotą, którą należy ponownie dodać do wyniku. Te same dane mogą mieć inną wartość dla kupującego z własnym kanałem sprzedaży, a inną dla podmiotu, który kupuje produkt właśnie po to, aby uzyskać dostęp do rynku.

Krok 3: uzgodnienie wyników

Podejście kosztowe wskazało 70 000 zł, a scenariusze około 135 000 zł. Zamiast automatycznie wyciągać średnią, należy wyjaśnić różnicę. W tym przykładzie przewaga wyniku scenariuszowego wynika z pilotaży i szansy na komercjalizację, której sam koszt zastąpienia nie mierzy.

Rozsądny wstępny przedział mógłby wynosić 70 000–135 000 zł, jeżeli audyt praw, kodu i danych nie ujawni kolejnych problemów. Kupujący strategiczny może uzasadnić wyższą kwotę, gdy produkt oszczędza mu czas i pasuje do istniejącego kanału sprzedaży. Kupujący finansowy bez takich synergii może nie zaakceptować nawet dolnej granicy.

W raporcie należy zachować także wyniki odrzuconych scenariuszy i opisać, skąd pochodzą prawdopodobieństwa. W przeciwnym razie przedział będzie tylko pozornie precyzyjny.

7. Jak przygotować pakiet wycenowy

Rzetelny materiał dla kupującego powinien umożliwić zmianę założeń bez przebudowy całego modelu. Przygotuj:

1. jednostronicowy opis transakcji — co jest sprzedawane, na jaki dzień i w jakim wariancie prawnym;
2. demo oraz opis gotowości — działające środowisko, kluczowe procesy, architekturę i instrukcję wdrożenia;
3. kosztorys zastąpienia — zakres, roboczogodziny, stawki, koszty pośrednie i korekty za braki;
4. dowody popytu i dystrybucji — dane z pilotaży, kohorty aktywności, eksporty z analityki, źródła ruchu, wyniki kanałów, rozmowy cenowe, listy intencyjne i umowy;
5. model scenariuszowy — co najmniej niepowodzenie, ograniczona komercjalizacja i sukces, wraz z analizą wrażliwości;
6. rejestr praw i zależności — twórców, umowy, licencje, open source, znaki, domeny, dostawców i możliwość cesji;
7. pakiet danych i zgodności — role w RODO, podstawy przetwarzania, retencję, incydenty i plan przekazania;
8. raport techniczny — dług techniczny, bezpieczeństwo, koszty chmury, monitoring i zakres prac po przejęciu;
9. listę potencjalnych nabywców — wraz z konkretną hipotezą wartości strategicznej dla każdego z nich.

Ten pakiet zwiększa jakość rozmowy o cenie, ponieważ oddziela fakty od założeń. Kupujący może zakwestionować prawdopodobieństwo, koszt albo zakres, zamiast dyskutować o jednej liczbie bez źródła.

8. Najczęstsze błędy

1. Zsumowanie wszystkich historycznych wydatków. Czas poświęcony na nietrafione funkcje i naukę nie tworzy automatycznie wartości dla kupującego.
2. Zastosowanie mnożnika do prognozowanego ARR jak do wyniku osiągniętego. Prognoza musi uwzględniać prawdopodobieństwo, czas i koszty dojścia do sprzedaży.
3. Traktowanie bezpłatnych użytkowników jak klientów. Aktywność może potwierdzać popyt, ale nie dowodzi gotowości do zapłaty.
4. Wycenianie całego TAM. Wielkość rynku nie pokazuje, jaką część potrafi zdobyć konkretny produkt i za jaką cenę.
5. Użycie wyceny z rundy jako ceny sprzedaży. Runda i przejęcie mają inną strukturę, cel oraz rozkład ryzyka.
6. Podwójne liczenie ryzyka. To samo ryzyko trafia do scenariusza, prawdopodobieństwa, stopy dyskontowej i dodatkowego dyskonta.
7. Pomijanie kosztu komercjalizacji. Gotowy produkt nadal może wymagać sprzedaży, marketingu, wsparcia, zgodności i finansowania.
8. Założenie, że prawa przeszły razem z kodem. Brak skutecznego przeniesienia praw może obniżyć cenę lub zatrzymać transakcję.
9. Przypisanie pełnej wartości bazie danych bez analizy RODO. Użyteczność danych zależy od zgodności ich przekazania i dalszego wykorzystania z prawem.
10. Ukrywanie długu technicznego. Kupujący zwykle policzy koszt i ryzyko z większym marginesem niż sprzedający, który ujawni je i przedstawi plan naprawy.
11. Przeliczanie obserwujących na cenę. Liczba profili nie pokazuje dopasowania publiczności, zasięgu, konwersji ani możliwości przekazania kanału.
12. Podwójne liczenie marki. Korzyść z niższego kosztu pozyskania trafia do scenariusza przepływów, a następnie po raz drugi jest dodawana jako osobna premia.
13. Wycena według kosztu programowania sprzed AI. Kupującego interesuje aktualny koszt uzyskania tej samej użyteczności przy użyciu agentów, gotowych komponentów i usług, a nie czas historycznie poświęcony na ręczne tworzenie kodu.

9. Jaki wynik można obronić

Wycena gotowego SaaS bez przychodów powinna prowadzić do przedziału, a nie do przypadkowego mnożnika. Jednym z punktów odniesienia jest aktualny koszt uzyskania porównywalnej użyteczności po korektach. Dowody popytu, scenariusze przyszłych przepływów i synergie konkretnego kupującego mogą wskazać inną wartość, ale wymagają jawnych założeń.

AI zmniejsza znaczenie historycznych nakładów na programowanie i zwiększa względne znaczenie tego, czego nie da się odtworzyć jednym poleceniem: potwierdzonego problemu, aktywnych użytkowników, dystrybucji, praw, danych, integracji oraz zaufania do produktu. Dlatego sam kod coraz rzadziej uzasadnia wysoką wycenę produktu bez przychodów.

Najważniejsza praca odbywa się przed otwarciem arkusza: trzeba potwierdzić, co jest gotowe, kto posiada prawa, czy produkt można przekazać i jakie zachowania użytkowników rzeczywiście zmniejszają ryzyko komercjalizacji. Im słabsze są te dowody, tym większą część ceny kupujący będzie chciał uzależnić od przyszłego wyniku, na przykład przez płatność etapową albo earn-out.

Jeżeli SaaS ma już powtarzalne przychody, zastosowanie znajdą inne metody opisane w artykule jak wycenić SaaS przed sprzedażą. Przed rozpoczęciem rozmów warto również ustalić kryteria potencjalnego kupującego i przygotować proces sprzedaży bez utraty poufności.

Bibliografia

1. Polska Federacja Stowarzyszeń Rzeczoznawców Majątkowych, „KSWS — Ogólne zasady wyceny przedsiębiorstw”, 2011; polski standard dobrej praktyki opisujący cel, przedmiot, założenia, standardy wartości oraz podejścia do wyceny przedsiębiorstw.
2. Paweł Głodek i Paweł Pietras, Polska Agencja Rozwoju Przedsiębiorczości, „Finansowanie komercjalizacji technologii i przedsięwzięć innowacyjnych opartych na wiedzy”, 2011, s. 80–82; starsze polskie źródło uzupełniające opis podejścia kosztowego, rynkowego i dochodowego do aktywów niematerialnych.
3. European Union Intellectual Property Office, „IP-backed finance in Europe: state of play and future perspectives”, 13 kwietnia 2026 r.; w szczególności część 3.2 o podejściach do wyceny własności intelektualnej.
4. International Private Equity and Venture Capital Valuation Board, „International Private Equity and Venture Capital Valuation Guidelines”, 11 grudnia 2025 r.; sekcje dotyczące inwestycji seed, startup i early stage oraz analizy scenariuszy.
5. International Valuation Standards Council, „International Valuation Standards”, wydanie obowiązujące od 31 stycznia 2025 r.; w szczególności IVS 200 i IVS 210.
6. Obwieszczenie Marszałka Sejmu RP z 6 grudnia 2024 r., tekst jednolity ustawy o prawie autorskim i prawach pokrewnych, Dz.U. 2025 poz. 24; w szczególności art. 41, 53 i 74.
7. Parlament Europejski i Rada UE, Rozporządzenie (UE) 2016/679, czyli RODO; w szczególności art. 5 i 6.
8. Europejska Rada Ochrony Danych, „Statement on the privacy implications of mergers”, 19 lutego 2020 r.
9. European IP Helpdesk, „ISO 56005: Intellectual Property Due Diligence: Preparing for a Transaction, Partnership, or International Operation”, 31 sierpnia 2026 r.
10. OpenChain Project, „OpenChain ISO/IEC 5230 – License Compliance”; międzynarodowy standard procesu zgodności z licencjami open source.
11. CMT Advisory i Fordata, „Raport M&A Branża IT 2025”, listopad 2025 r.; polskie i europejskie dane o transakcjach oraz dostępności ich warunków.
12. International Organization for Standardization, „ISO 10668:2010 — Brand valuation — Requirements for monetary brand valuation”; standard dotyczący celu, podstaw, metod, danych i raportowania pieniężnej wyceny marki, potwierdzony w 2023 r.
13. International Organization for Standardization, „What’s in a Brand? Quite a bit, actually”, 10 marca 2020 r.; omówienie ekonomicznego wpływu marki i metod stosowanych w jej ocenie.
14. Komisja Europejska, „EU Grants: Horizon Europe Social Media Guide”, wersja 1.0 z 1 października 2023 r., s. 13–14; instytucjonalne wskazówki dotyczące łączenia ilościowych i jakościowych mierników wpływu social mediów.
15. LinkedIn, „User Agreement”; oficjalne warunki dotyczące własności i zakazu przekazywania kont osobistych oraz połączeń.
16. YouTube Help, „Zmiana właścicieli i menedżerów kanału na koncie marki”; oficjalna procedura zarządzania rolami i zmiany głównego właściciela kanału.
17. OECD, „The effects of generative AI on productivity, innovation and entrepreneurship”, OECD Artificial Intelligence Papers, 2025; przegląd badań eksperymentalnych, w tym dotyczących programowania.
18. Kevin Zheyuan Cui, Mert Demirer, Sonia Jaffe, Leon Musolff, Sida Peng i Tobias Salz, „The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers”, „Management Science”, publikacja internetowa z 27 lutego 2026 r.; randomizowane eksperymenty obejmujące 4867 programistów.
19. DORA, „State of AI-assisted Software Development 2025”; badanie wpływu AI na cały proces dostarczania oprogramowania, a nie wyłącznie szybkość generowania kodu.
20. METR, „We are Changing our Developer Productivity Experiment Design”, 24 lutego 2026 r.; aktualizacja eksperymentów produktywności wraz z opisem niepewności i błędów doboru próby.