Tech Due Diligence dla fuzji i przejęć: kod, architektura, bezpieczeństwo, zespół

Dlaczego Tech Due Diligence w M&A

W fuzjach i przejęciach technologia bywa albo największym akceleratorem wartości, albo ukrytym ryzykiem, które „wychodzi” dopiero po podpisaniu umowy. Tech Due Diligence (TDD) ma jeden cel: zidentyfikować ryzyka i koszty technologiczne, zanim staną się problemem – oraz ocenić, czy produkt i organizacja inżynierska są w stanie utrzymać tempo rozwoju po transakcji.

Dobrze przeprowadzone TDD nie jest tylko audytem kodu. To ocena:

• jakości i utrzymywalności rozwiązania,
• architektury i skalowalności,
• bezpieczeństwa i zgodności,
• dojrzałości DevOps i operacji,
• kompetencji i stabilności zespołu,
• oraz realnych kosztów: długu technologicznego, migracji, refaktorów i utrzymania.

Poniżej znajdziesz praktyczną listę kontrolną, którą możesz wykorzystać jako bazę do procesu Tech Due Diligence – zarówno przy zakupie spółki produktowej (SaaS), jak i software’owego „build-u” w większym biznesie.

Zakres i kontekst (zanim wejdziesz w kod)

Cel: zrozumieć, co jest kupowane i jak technologia wspiera (lub blokuje) biznes.

• Jakie są kluczowe produkty/systemy (core vs wspierające)?
• Jakie są krytyczne procesy biznesowe obsługiwane przez system?
• Jaki jest model przychodów i które elementy platformy są kluczowe dla revenue?
• Które elementy są „single point of failure”?
• Jak wygląda roadmapa i zobowiązania wobec klientów (SLA, kontrakty)?
• Jakie są zależności od dostawców (cloud, licencje, usługi zewnętrzne)?

Wynik: mapa systemów + priorytety ryzyka, czyli gdzie TDD ma „kopać” najgłębiej.

1) Kod i jakość inżynierska (Codebase & Engineering Quality)

Cel: ocenić utrzymywalność, ryzyko regresji, koszt dalszego rozwoju.

Struktura repozytoriów i higiena kodu

• Czy repozytoria mają jasną strukturę i ownership?
• Czy istnieją standardy kodowania, review i style guide?
• Czy jest konsekwencja w nazewnictwie, modularności i separacji warstw?
• Jak wygląda dług technologiczny (TODO/FIXME, stare moduły, „gorące” fragmenty)?

Testy i QA

• Jakie typy testów istnieją (unit/integration/e2e)?
• Jaki jest realny poziom pokrycia krytycznych ścieżek (nie tylko procent coverage)?
• Czy testy są stabilne (flaky tests) i uruchamiane w CI?
• Jak często dochodzi do regresji po wdrożeniach?

Zależności i podatności

• Czy zależności są aktualizowane regularnie?
• Czy jest proces zarządzania podatnościami (SCA)?
• Czy są komponenty „end-of-life” (frameworki/biblioteki bez wsparcia)?

Dokumentacja techniczna

• Czy istnieje sensowny README, instrukcje uruchomienia, kontrybucji?
• Czy decyzje architektoniczne są udokumentowane (ADR)?
• Czy onboarding nowej osoby jest możliwy w rozsądnym czasie?

Sygnały ostrzegawcze: brak testów, brak CI, duże zależności od wiedzy pojedynczych osób, „manualne” wdrożenia, wysoka liczba krytycznych luk w zależnościach.

2) Architektura i skalowalność (Architecture & Scalability)

Cel: ocenić, czy system „dowiezie” wzrost i jak kosztowna będzie integracja lub modernizacja.

Architektura aplikacji

• Monolit czy mikroserwisy? Czy wybór jest uzasadniony?
• Czy istnieje wyraźna granica domen (bounded contexts)?
• Jak wygląda spójność danych i transakcyjność?
• Czy system ma „wąskie gardła” (np. jedna baza, jeden serwis, kolejka)?

Architektura danych

• Jakie bazy danych i dlaczego? Czy są właściwie użyte?
• Czy istnieją mechanizmy cache, indeksy, optymalizacje zapytań?
• Czy są problemy z jakością danych, duplikacją, brakiem spójności?
• Czy są pipeline’y danych / integracje i jak są utrzymywane?

Wydajność i niezawodność

• Czy są SLO/SLA i realne metryki uptime?
• Jak wygląda obserwowalność: logi, metryki, trasy (tracing)?
• Czy istnieje plan awaryjny (DR), backupy i testy odtwarzania?
• Jak system reaguje na skoki ruchu?

Integracje i zależności

• Jakie są integracje krytyczne (płatności, ERP/CRM, dostawcy)?
• Jak wygląda odporność na awarie dostawców (retry, circuit breaker)?
• Jak zarządzane są wersje API i kompatybilność wsteczna?

Sygnały ostrzegawcze: brak monitoringu, brak testów DR, brak skalowania, architektura „przypadkowa”, zależność od jednego komponentu bez redundancji.

3) Bezpieczeństwo i zgodność (Security & Compliance)

Cel: ocenić ryzyko incydentów, gotowość do audytów oraz wpływ na transakcję.

IAM i dostęp

• Czy istnieje SSO/MFA? Jak zarządzane są uprawnienia?
• Czy są konta współdzielone / brak audytowalności?
• Czy dostęp do produkcji jest kontrolowany i logowany?

Sekrety i klucze

• Czy sekrety są w vault/secret managerze, czy w kodzie?
• Jak wygląda rotacja kluczy i dostęp do nich?

Bezpieczeństwo aplikacji

• Czy są procesy SAST/DAST/SCA w CI/CD?
• Czy regularnie wykonywane są testy penetracyjne?
• Jak zarządzane są podatności i patchowanie?

Dane i prywatność

• Jak chronione są dane wrażliwe (PII)?
• Czy jest szyfrowanie w spoczynku i w tranzycie?
• Czy istnieją polityki retencji danych i logów?

Incydenty i gotowość operacyjna

• Czy firma miała incydenty bezpieczeństwa? Jak zareagowała?
• Czy jest plan reakcji na incydent (IRP) i ćwiczenia?
• Czy istnieje monitoring anomalii?

Sygnały ostrzegawcze: sekrety w repozytoriach, brak MFA, brak patchowania, brak procesu zarządzania podatnościami, brak logów audytowych.

4) DevOps, chmura i operacje (Delivery & Operations)

Cel: ocenić, czy firma potrafi bezpiecznie wdrażać i utrzymywać system.

• Czy jest CI/CD? Jak wygląda proces release?
• Czy infrastruktura jest opisana jako kod (IaC)?
• Czy środowiska są powtarzalne (dev/stage/prod)?
• Jak wygląda monitoring i alerting?
• Czy są runbooki i procedury incident response?
• Jak wygląda koszt utrzymania i czy jest kontrola kosztów chmury (FinOps)?

Sygnały ostrzegawcze: wdrożenia ręczne, „klikana” infrastruktura, brak rollbacków, brak środowisk, duże zależności od pojedynczych osób.

5) Zespół i organizacja inżynierska (Team & Engineering Org)

Cel: ocenić zdolność do utrzymania i rozwoju technologii po przejęciu.

Struktura i kompetencje

• Jakie role są w zespole (backend/frontend/QA/DevOps/data/security)?
• Czy są liderzy techniczni i proces podejmowania decyzji?
• Jak wygląda product management i praca z backlogiem?

Stabilność i ryzyko personalne

• Które osoby są „single point of knowledge”?
• Jaka jest rotacja i zależność od kontraktorów?
• Czy są procesy onboardingu i dokumentacja?

Kultura inżynierska

• Czy są code review, standardy jakości, testy?
• Jak firma zarządza długiem technologicznym?
• Czy są retrospektywy i ciągłe doskonalenie?

Sygnały ostrzegawcze: brak QA/DevOps, brak liderów, wiedza w głowach, wysoka rotacja, chaos w backlogu.

6) Licencje, IP i ryzyka prawne (często pomijane)

Cel: ocenić ryzyka własności intelektualnej i kosztów licencyjnych.

• Czy firma ma prawa do kodu (umowy z pracownikami i kontraktorami)?
• Jakie są licencje open source i czy są zgodne z polityką (np. copyleft)?
• Czy są komercyjne komponenty/licencje z ryzykiem wzrostu kosztów?
• Czy są patenty / third-party IP w produkcie?
  
  

Jak wygląda dobry wynik Tech Due Diligence (format, który pomaga w M&A)

Dobre TDD powinno kończyć się nie tylko listą problemów, ale i mapą decyzji:

1. Ryzyka krytyczne (deal breakers) – np. poważne luki bezpieczeństwa, brak praw do IP, brak możliwości skalowania.
2. Ryzyka istotne (do wyceny) – dług technologiczny, konieczne migracje, braki w DevOps.
3. Ryzyka operacyjne (do planu integracji) – procesy, team, monitoring, onboarding.
4. Plan działań 30/60/90 dni po przejęciu – co robimy najpierw, by ustabilizować sytuację.
5. Szacunek kosztów i wysiłku – ile będzie kosztować doprowadzenie technologii do „standardu”.
   
   

Gdzie Altimi może pomóc: Tech Due Diligence jako element partnerstwa

W podejściu partnerskim Tech Due Diligence nie kończy się na raporcie. Największa wartość pojawia się wtedy, gdy po audycie można przejść do działań: stabilizacji, modernizacji, poprawy bezpieczeństwa i uspójnienia delivery.

Altimi w praktyce wspiera organizacje:

• w analizie architektury i jakości kodu,
• w ocenie i wdrożeniu DevOps/CI/CD, IaC, observability,
• w podniesieniu poziomu cyberbezpieczeństwa (IAM, sekrety, skanowanie, procesy),
• w ocenie dojrzałości zespołów i rekomendacjach organizacyjnych,‍
• oraz w realizacji planu naprawczego w modelu consulting / managed services / BOT.