Techniczne due diligence przy przejęciach SaaS: przewodnik sektorowy

Każde techniczne due diligence przygląda się tym samym szerokim obszarom: architekturze, jakości kodu, infrastrukturze, bezpieczeństwu, skalowalności, zespołowi. Ale generyczna lista kontrolna zastosowana do spółki SaaS pomija to, co realnie decyduje o wyniku transakcji SaaS. W modelu software as a service kilka faktów technicznych leży bezpośrednio pod liczbami, na których kupującemu zależy najbardziej - marżą brutto, retencją przychodu netto, wiarygodnością planu wzrostu - i zachowują się inaczej niż w firmie usługowej, w licencjonowanym produkcie on-premise czy w marketplace.

Ten przewodnik jest właśnie o tej różnicy. Prowadzi przez te wymiary badania technicznego, które ważą najwięcej, gdy przejmowana spółka to SaaS, przez sygnały ostrzegawcze charakterystyczne dla tego modelu oraz przez to, jak czytać ustalenie techniczne jako sygnał wyceny, którym zwykle jest. Perspektywa jest cały czas po stronie kupującego: co nabywca musi zrozumieć przed podpisaniem umowy i dlaczego model SaaS nagradza dokładniejsze przyjrzenie się jednym miejscom niż innym.

Dlaczego SaaS zmienia to, czego szuka badanie techniczne

Spółka SaaS zarabia na tym samym oprogramowaniu wielokrotnie, na wielu klientach, i to właśnie daje modelowi jego marże oraz skalowalność. To samo sprawia, że techniczne fundamenty są tu wyjątkowo nośne. W firmie usługowej ograniczeniem są ludzie. W SaaS jest nim architektura. Ten jeden fakt na nowo porządkuje priorytety badania technicznego.

Wynikają z niego trzy konsekwencje. Po pierwsze, ekonomika infrastruktury przesuwa się z kwestii zaplecza do rdzenia wyceny, bo w SaaS koszt utrzymania oprogramowania jest kosztem wytworzenia i wpływa wprost na marżę brutto. Po drugie, zdolność do dostarczania - dokładania funkcji, spełniania wymagań klientów korporacyjnych i integrowania się z ich środowiskiem - decyduje o tym, czy retencja przychodu netto się kumuluje, czy wycieka, więc tempo dostarczania jest metryką handlową, a nie tylko inżynierską. Po trzecie, architektura wielodostępna, która czyni SaaS wydajnym, jednocześnie koncentruje ryzyko: błąd bezpieczeństwa albo granica skalowalności nie są problemem jednego klienta, są problemem wszystkich klientów naraz. Badanie techniczne spółki SaaS musi odpowiednio ważyć te trzy obszary, zamiast traktować wszystkie osiem pól oceny jako jednakowo rozstrzygające.

Wymiary, które ważą najwięcej

Wielodostępność i architektura pod marżą

Pierwsze pytanie w badaniu technicznym SaaS brzmi, jak naprawdę działa wielodostępność. Czysto wielodostępna platforma, na której klienci bezpiecznie współdzielą infrastrukturę i która jest zaprojektowana tak, by przyjąć kolejny tysiąc najemców bez liniowego wzrostu kosztów, to fundamentalnie inne aktywo niż system, który w praktyce po cichu stał się jednodostępny i uruchamia dedykowane zasoby dla każdego klienta, bo prawdziwej izolacji nigdy nie zbudowano. Ten drugi wygląda w rachunku wyników jak SaaS, dopóki wzrost tego nie obnaży, a wtedy marża przestaje rosnąć wraz ze skalą. To jedno z najbardziej brzemiennych w skutki ustaleń w tym sektorze i zarazem jedno z najsłabiej widocznych z zewnątrz, bo oba modele sprzedają tę samą subskrypcję.

Koszt infrastruktury jako udział w przychodzie

Blisko z tym związane i warte wyodrębnienia jako osobna pozycja jest to, ile utrzymanie platformy kosztuje w stosunku do tego, ile ona zarabia, śledzone w czasie. W SaaS ten stosunek jest bezpośrednim odczytem jakości marży brutto i tego, czy model skaluje się tak, jak zakłada plan. Rosnący udział infrastruktury przy stałej lub rosnącej liczbie klientów sygnalizuje nadmiarowe rezerwowanie zasobów, niemożność współdzielenia mocy między najemcami albo obejścia utrzymywane latami, bo ich usunięcie wymagało zbyt dużej zmiany. Kupujący, który płaci mnożnik SaaS, płaci za marżę rosnącą wraz ze skalą, więc dowód, że tak się nie dzieje, uderza wprost w tezę.

Bezpieczeństwo, zgodność i sufit segmentu korporacyjnego

Dla każdej spółki SaaS sprzedającej w górę rynku bezpieczeństwo i zgodność nie są higieną, lecz bramą do dostępnego rynku. SOC 2, ISO 27001, gotowość pod RODO, solidne uwierzytelnianie i kontrola dostępu oraz wiarygodny ślad audytowy przesądzają o tym, czy spółka konkuruje o klientów korporacyjnych, czy odpada już na etapie ankiety bezpieczeństwa. Badanie techniczne musi ustalić nie tylko to, czy certyfikaty istnieją, ale czy architektura jest w stanie je udźwignąć, bo doposażenie w izolację najemców albo kontrolę dostępu systemu, który nie był pod nie projektowany, to duży program, a nie odhaczenie pozycji. Tam, gdzie luka jest architektoniczna, jej kosztem jest ten segment rynku, którego spółka obecnie nie może sięgnąć.

Tempo dostarczania i związek z retencją

W SaaS roadmapa jest narzędziem utrzymania klienta. Klienci zostają, bo produkt rozwiązuje coraz większą część ich problemu, a odchodzą, gdy staje w miejscu. Dlatego kondycja maszyny dostarczającej - dojrzałość CI/CD, pokrycie testami w obszarach o wysokim ryzyku, częstotliwość wydań i czas od decyzji do produkcji - jest wczesnym wskaźnikiem retencji przychodu netto. Badanie techniczne powinno czytać niskie tempo dostarczania nie jako kwestię czysto techniczną, lecz jako przyszłą utratę klientów, która jeszcze nie pojawiła się w liczbach, bo produkt, który nie potrafi dostarczać, w końcu straci przychód z ekspansji, na którym opiera się mnożnik SaaS.

Architektura danych i gotowość do AI

Coraz częściej zdolność spółki SaaS do dokładania funkcji opartych na sztucznej inteligencji jest składnikiem jej wartości, a ta zdolność zależy od tego, czy dane są spójne i dostępne, czy rozproszone między najemcami i magazynami bez użytecznego modelu. Badanie techniczne musi dziś oceniać dojrzałość w obszarze AI i danych jako wymiar wartości patrzący w przód: nie to, czy spółka używa AI dzisiaj, ale czy jej architektura mogłaby to udźwignąć bez przebudowy. Dla kupującego, którego teza zakłada rozszerzenie produktu o AI, może to być ustalenie, na którym plan staje albo upada.

Ryzyko kluczowych osób w kodzie budowanym przez założycieli

Wiele spółek SaaS w momencie transakcji jest wciąż blisko swojego założycielskiego zespołu inżynierskiego, a krytyczna wiedza o wielodostępności, logice rozliczeń, integracjach i obsłudze incydentów często siedzi w kilku osobach bez sformalizowanej odpowiedzialności. W biznesie, którego cała wartość polega na ciągłości działającej usługi, to ryzyko istotne, a nie organizacyjny przypis. Badanie techniczne ujawnia je właśnie dlatego, że rzadko figuruje w jakimkolwiek dokumencie; wychodzi dopiero w rozmowie z zespołem inżynierskim.

Sygnały ostrzegawcze charakterystyczne dla modelu SaaS

Niektóre ustalenia są w większości oprogramowania zwyczajne, a w SaaS alarmujące. Dedykowana infrastruktura per klient przebrana za wielodostępność jest najwyraźniejsza, bo zamyka opowieść o marży, od której zależy wycena. Koszty infrastruktury rosnące szybciej niż przychód to kolejne, z tego samego powodu. Architektura bezpieczeństwa niezdolna udźwignąć certyfikacji, które zakłada plan wzrostu, to trzecie, bo po cichu zamyka dostępny rynek. Niezarządzane zależności open source i niejasne licencjonowanie ważą w SaaS więcej niż w oprogramowaniu on-premise, bo usługa jest dostarczana nieprzerwanie, więc problem licencyjny jest żywą ekspozycją, a nie dostarczonym raz artefaktem. A proces dostarczania spowolniony do tego stopnia, że roadmapę kształtuje to, co da się bezpiecznie ruszyć, a nie to, czego potrzebują klienci, jest ryzykiem retencji w przebraniu technicznej niedogodności.

Doświadczenie z ponad stu badań po stronie kupującego potwierdza to w tym sektorze. W jednej z platform SaaS obsługujących operatorów wielooddziałowych produkt miał wyraźne dopasowanie do rynku i stabilny zespół, ale krytyczna wiedza o systemie była skupiona w kilku osobach bez sformalizowanej odpowiedzialności, co zmieniało profil ryzyka po przejęciu. W innej, platformie SaaS z silną bazą kupców w Europie Środkowo-Wschodniej, retencja wyglądała solidnie, podczas gdy zarządzanie zależnościami i dojrzałość CI/CD odstawały od skali platformy. Żadne z tych ustaleń nie było widoczne we wskaźnikach komercyjnych i oba trzeba było wpisać do planu po zamknięciu transakcji.

Jak czytać ustalenie jako sygnał wyceny

Celem badania technicznego SaaS nie jest wystawienie oceny inżynierii. Jest nim przełożenie faktów technicznych na język transakcji. Problem z wielodostępnością to opowieść o marży. Luka w bezpieczeństwie to opowieść o dostępnym rynku. Wolne dostarczanie to opowieść o retencji. Skoncentrowana wiedza to opowieść o ciągłości. Każde z tych ustaleń staje się użyteczne w negocjacji dopiero wtedy, gdy niesie oszacowanie nakładu na jego usunięcie i miejsce w macierzy ryzyka uporządkowanej według istotności, tak aby komitet inwestycyjny widział nie listę zażaleń, lecz zestaw wycenionych, uporządkowanych decyzji.

To przełożenie jest zarazem tym, co zamienia badanie w plan na okres po transakcji. Każde ustalenie przypisane do działania naprawczego i dźwigni wartości staje się pozycją w pierwszych stu dniach, a nie niespodzianką w drugim roku, co przy aktywie SaaS - gdzie marża i retencja się kumulują - stanowi różnicę między kupionym tempem a odziedziczonym problemem.

Jak Altimi podchodzi do badania technicznego SaaS

Altimi realizuje techniczne due diligence po stronie kupującego dla funduszy private equity, venture capital i inwestorów wzrostowych w Europie, z bogatym doświadczeniem w segmencie SaaS wśród ponad stu badań po stronie kupującego i ponad stu pięćdziesięciu projektów inżynierskich. Badanie jest dostarczane w stałej cenie i ustalonym z góry zakresie, w ciągu dwóch tygodni, a jego rezultatem jest komplet materiałów gotowych dla komitetu: raport w skali RAG, macierz ryzyka z rekomendacją go lub no-go, ocena skalowalności i dojrzałości AI, ocena dojrzałości zespołu i procesu dostarczania oraz 90-dniowa roadmapa tworzenia wartości. Dla spółki SaaS badanie waży te obszary, które poruszają wycenę SaaS - wielodostępność i ekonomikę infrastruktury, stan bezpieczeństwa jako bramę do sprzedaży korporacyjnej, tempo dostarczania jako sygnał retencji oraz architekturę danych jako sygnał gotowości do AI - zamiast stosować płaską listę kontrolną.

Niezależność jest tu zasadą operacyjną: Altimi działa wyłącznie na rzecz inwestora, na stałym honorarium bez zachęt do dalszych zleceń, ujawnia wcześniejsze powiązania ze spółką badaną i nie przyjmuje mandatów obarczonych istotnym konfliktem interesów. Ponieważ Altimi jako partner technologiczny również buduje i modernizuje systemy SaaS, naprawę rekomendowaną przez badanie może przeprowadzić ten sam zespół, co obniża realny koszt wdrożenia wniosków. Jako organizacja z siedzibą w Unii Europejskiej, posiadająca certyfikat ISO 27001, Altimi utrzymuje kod źródłowy i dane transakcyjne w europejskim obszarze ochrony danych przez cały poufny proces.

Uwaga dla transakcji w Europie i regionie CEE

Przy przejęciach SaaS w Europie Środkowo-Wschodniej, regionie DACH i na szerszym rynku europejskim wymiar zgodności bywa najostrzejszym czynnikiem wartości, bo tak bezpośrednio przekłada się na dostępny rynek. Gotowość pod RODO, ISO 27001 i SOC 2 oraz oczekiwania klientów korporacyjnych co do bezpieczeństwa decydują o tym, do jakich segmentów spółka SaaS może sprzedawać, więc luka w tym obszarze jest wpisaną w transakcję barierą wzrostu. Gdy spółka badana działa w jednej jurysdykcji, a fundusz raportuje w innej, utrzymanie kodu źródłowego i danych klientów w europejskim obszarze ochrony danych w trakcie badania waży tyle samo co same ustalenia, dlatego dostawca z siedzibą w UE i certyfikatem to przy transgranicznych transakcjach SaaS coś więcej niż wygoda.

Podsumowanie

Techniczne due diligence przy przejęciu SaaS to nie generyczny przegląd techniczny z etykietą SaaS. Model kładzie szczególny ciężar na kilka faktów technicznych - jak naprawdę działa wielodostępność, ile kosztuje utrzymanie platformy, czy bezpieczeństwo udźwignie plan wzrostu, czy dostarczanie utrzyma retencję i czy dane udźwigną opowieść o AI - bo każdy z nich leży wprost pod marżą, retencją i skalowalnością, które wycenia mnożnik SaaS. Czytane w ten sposób, ustalenie techniczne rzadko jest wyłącznie techniczne. Jest wyceną, oglądaną o warstwę niżej.

Jeśli oceniasz spółkę SaaS i chcesz badania, które mówi językiem czynników napędzających mnożnik SaaS, najprościej zacząć od krótkiej rozmowy o spółce i tezie, którą masz przed sobą.