Blog - Syntanea

Software due diligence checklist przydaje się wtedy, gdy masz kupić produkt software, przejąć codebase, sfinansować przebudowę albo podpisać długą umowę z partnerem technologicznym.

Największym ryzykiem nie jest sam code review. Ryzykiem jest demo, po którym wszyscy uznają, że skoro stack jest nowoczesny, to produkt da się łatwo utrzymać. System może dobrze wyglądać na callu sprzedażowym i jednocześnie ukrywać brak testów, hasła w złych miejscach, wiedzę jednej osoby, kruchy deployment albo dane, które będą kosztować miesiące pracy.

Ten przewodnik jest dla founderów, inwestorów, CFO, CTO i zespołów operacyjnych, które potrzebują technicznego sprawdzenia przed przejęciem odpowiedzialności lub pieniędzy. To nie jest lista prawna. To część inżynierska i delivery: co działa, co się psuje, co zależy od jednej osoby i ile będzie kosztować utrzymanie produktu.

Software due diligence checklist przed zaufaniem do demo

Zacznij od dowodów, nie od opinii. Ładne demo pokazuje, że jedna ścieżka zadziałała raz. Due diligence ma pokazać, czy zespół potrafi uruchamiać, zmieniać, wdrażać, wspierać i zabezpieczać produkt, gdy pojawią się zwykłe problemy.

Poproś o te materiały przed pierwszym warsztatem technicznym:

dostęp do repozytorium albo prowadzony walkthrough kodu na screen sharingu

diagram architektury, nawet roboczy

notatki z deploymentu dla stagingu i produkcji

listę środowisk, usług, domen, kont cloud i vendorów

schemat bazy albo mapę encji dla głównych obiektów biznesowych

backlog, historię incydentów i znane ryzyka techniczne

listę ownerów dla produktu, infrastruktury, security i supportu

Jeśli seller albo vendor nie potrafi zebrać tego w kilka dni, to już jest wynik audytu. Nie musi zabić transakcji, ale zmienia cenę, harmonogram i plan przekazania.

Sprawdź, czy codebase da się uruchomić od zera

Najprostszy test due diligence często mówi najwięcej. Czy developer, który nie pracował przy produkcie, może sklonować repozytorium, przejść README i uruchomić system lokalnie albo w środowisku testowym?

Zapisuj ukryte kroki. Ktoś może wysłać prywatny plik .env przez chat. Dump bazy może leżeć na jednym laptopie. Token do prywatnego registry może należeć do byłego kontraktora. Aplikacja może ruszyć dopiero po trzech komendach, których nie ma w dokumentacji. Każdy taki krok to przyszłe ryzyko delivery.

Czysty setup nie znaczy, że produkt jest idealny. Znaczy, że wiedza nie jest zamknięta w jednej osobie. Jeśli setup trwa cały dzień i wymaga prowadzenia za rękę, wpisz to do memo. Kupujesz software oraz wiedzę operacyjną wokół niego.

Oceniaj architekturę pod kątem ryzyka zmian, nie elegancji

Review architektury powinno odpowiedzieć na jedno pytanie: ile będzie kosztować następna ważna zmiana? Nie potrzebujesz perfekcyjnego diagramu. Potrzebujesz wiedzieć, gdzie produkt jest kruchy.

Szukaj:

jednego dużego modułu, który obsługuje niepowiązane reguły biznesowe

niejasnych granic między frontendem, backendem, jobami i integracjami

bezpośredniego dostępu do bazy z wielu usług

zduplikowanych reguł biznesowych w kilku miejscach

wywołań API vendorów bez retry, kolejki albo obsługi błędów

skryptów cyklicznych, których nikt nie monitoruje

własnego frameworka, który rozumie tylko jeden developer

Raport due diligence powinien oddzielić brzydkie od ryzykownego. Brzydkie nazwy są irytujące. Workflow płatności bez testów i z trzema ręcznymi poprawkami w bazie miesięcznie jest ryzykiem. Moduł legacy może być akceptowalny, jeśli jest stabilny, opisany i zamknięty za jasnym interfejsem.

Po transakcji głębszy porządek możesz oprzeć o nasz technical debt audit checklist. Due diligence znajduje ryzyko. Audyt zamienia je w backlog.

Sprawdź release, rollback i kontrolę środowisk

Produkt nie jest gotowy produkcyjnie tylko dlatego, że ma użytkowników. Jest gotowy wtedy, gdy zespół potrafi wdrożyć małą zmianę, zauważyć problem i cofnąć wdrożenie bez paniki.

Sprawdź:

czy CI buduje każdą zmianę

kto może wdrażać i jak zatwierdza się dostęp

czy staging jest wystarczająco podobny do produkcji, żeby łapać realne problemy

jak testuje się i cofa migracje bazy

gdzie zespół sprawdza logi, metryki i błędy

czy release ma ownera i ścieżkę rollbacku

jak trzymane i rotowane są secrety

Dobre pytanie brzmi: kiedy był ostatni incydent produkcyjny i co zmieniło się po nim? Zespół z uczciwymi notatkami po incydentach zwykle jest bezpieczniejszy niż zespół, który twierdzi, że nic nigdy się nie psuje.

Oceń testy wokół pieniędzy, uprawnień i danych

Nie pytaj tylko o procent coverage. Coverage może być wysokie, a najważniejsze ścieżki prawie niesprawdzone. Zapytaj, gdzie regresja uderzyłaby w biznes.

Sprawdź testy wokół billing, uprawnień, importu danych, eksportów, integracji, powiadomień i akcji admina. Jeśli produkt przetwarza dane osobowe, sprawdź testy access control i audit logi. Jeśli przenosi pieniądze, sprawdź zaokrąglenia, zwroty, uzgodnienia i obsługę duplikatów eventów.

Mały, ale sensowny zestaw testów jest lepszy niż tysiące kruchych snapshotów. Chodzi o to, czy zespół wie, które elementy nie mogą się zepsuć.

Zmapuj ownership danych i ryzyko migracji

Software due diligence często zbyt późno zauważa ryzyko danych. To drogie opóźnienie. Produkt może mieć przyzwoity kod i jednocześnie nosić bałagan w rekordach klientów, duplikaty kont, niejasne zgody, brak ścieżek usuwania albo ręczne poprawki, które nigdy nie trafiły do reguł systemu.

Zadaj te pytania:

który system jest właścicielem każdego ważnego pola?

jak powstają rekordy klientów, faktur, użytkowników i uprawnień?

gdzie dzieją się ręczne nadpisania?

jakie dane trzeba migrować, jeśli produkt zmieni właściciela?

jakie dane trzeba usunąć, zamaskować, zarchiwizować albo zachować dla compliance?

jak walidowane są importy przed dotknięciem produkcji?

Dla europejskich firm GDPR nie jest papierologią na końcu. Wpływa na architekturę, logi, backupy, analytics i narzędzia supportu. Jeśli nikt nie potrafi wyjaśnić ścieżki usunięcia i eksportu danych, zapisz to jako realne ryzyko delivery.

Oceń zależność od zespołu i vendorów

Ryzyko software często siedzi poza repozytorium. Produkt może zależeć od jednego kontraktora, jednego konta cloud, jednej nieopisanej umowy z vendorem albo foundera, który zatwierdza każdy release. Due diligence powinno to pokazać.

Wypisz ludzi i vendorów potrzebnych do utrzymania produktu przez następne 90 dni. Uwzględnij developerów, DevOps, product ownera, support, security, zewnętrzne API, hosting, płatności, email, analytics i wszystkie narzędzia no-code w workflow.

Potem zapytaj, co się stanie, jeśli każdy z nich zniknie na dwa tygodnie. Jeśli odpowiedź brzmi "czekamy", masz problem ciągłości. Może być naprawialny, ale potrzebuje budżetu na handover.

Jeśli porównujesz kilku partnerów zewnętrznych przed projektem albo wsparciem przy przejęciu, nasz software vendor selection checklist pokazuje pytania, które warto zadać przed podpisaniem umowy.

Zbuduj 30-dniowy plan naprawczy

Wynikiem software due diligence nie powinna być straszna lista bez decyzji. Raport powinien podzielić ustalenia na trzy grupy: blokery transakcji, korekty ceny lub zakresu oraz prace po przejęciu.

Praktyczne pierwsze 30 dni może wyglądać tak:

tydzień 1: zabezpieczenie dostępów, opis środowisk, rotacja współdzielonych haseł i potwierdzenie backupów

tydzień 2: powtarzalny setup, naprawa najgroźniejszej luki w release i spisanie prawdziwego runbooka

tydzień 3: testy wokół najbardziej ryzykownych flow biznesowych i sprawdzenie monitoringu

tydzień 4: uporządkowanie najważniejszego problemu danych, zamknięcie jednej zależności od vendora i plan pracy na następny kwartał

Nie próbuj od razu naprawiać każdego code smell. Najpierw spraw, żeby produkt dało się bezpiecznie utrzymać. Potem poprawiaj elementy, które spowalniają zmiany albo tworzą ryzyko biznesowe.

Red flags w software due diligence

Niektóre ustalenia wymagają większej uwagi niż zwykły dług techniczny.

Uważaj na sytuacje, gdy:

nikt nie potrafi wdrożyć bez pierwotnego developera

dane produkcyjne są wysyłane w czacie albo trzymane w repozytorium

baza produkcyjna jest ręcznie zmieniana w normalnym supporcie

nie ma stagingu albo staging używa starych danych, które chowają prawdziwe problemy

płatności, uprawnienia albo dane osobowe nie mają sensownych testów

konta cloud, domeny albo konta app store należą do prywatnej osoby

vendor odmawia dostępu do kodu, ale oczekuje pewnej estymacji

brakuje historii incydentów, choć użytkownicy zgłaszają powtarzalne problemy

Żaden z tych punktów automatycznie nie oznacza rezygnacji. Oznacza za to, że trzeba zmienić warunki, dodać budżet przejściowy albo zwolnić, dopóki ryzyko nie będzie zrozumiałe.

FAQ: software due diligence checklist

Co to jest software due diligence?

Software due diligence to techniczny przegląd produktu, codebase, zespołu, infrastruktury, danych i procesu operacyjnego przed przejęciem, inwestycją, zmianą vendora albo dużą umową. Pokazuje, czemu można zaufać i co będzie wymagało pieniędzy po decyzji.

Co powinien zawierać software due diligence checklist?

Lista powinna obejmować setup repozytorium, architekturę, release process, środowiska, testy, security, ownership danych, integracje, zależności od vendorów, historię incydentów, dokumentację i plan naprawczy z ownerami oraz terminami.

Ile trwa software due diligence?

Skupiony review małego albo średniego produktu często trwa od jednego do dwóch tygodni, jeśli dostępy są gotowe. Złożone platformy, dane regulowane, słaba dokumentacja albo kilku vendorów mogą wydłużyć review do trzech lub czterech tygodni.

Kto powinien prowadzić software due diligence?

Potrzebujesz senior engineerów, którzy potrafią czytać kod, rozumieją infrastrukturę i umieją wyjaśnić ryzyko językiem biznesowym. Przy przejęciach i handoverach uwzględnij osobę, która utrzymywała systemy produkcyjne, a nie tylko reviewowała slajdy architektury.

Czy software due diligence to to samo co code audit?

Nie. Code audit skupia się na jakości kodu i ryzyku technicznym. Software due diligence sprawdza też delivery, ludzi, vendorów, konta, dane, security, dokumentację i koszt przejęcia odpowiedzialności za produkt.

Potrzebujesz jasnego obrazu przed przejęciem codebase?

Syntanea pomaga europejskim firmom oceniać produkty software przed przejęciami, zmianą vendora, projektami rescue i długimi zobowiązaniami technicznymi. Sprawdzamy kod, ścieżkę delivery, ryzyko danych, infrastrukturę i zależności zespołu, a potem zamieniamy ustalenia w prostą notatkę decyzyjną.

Jeśli chcesz wiedzieć, czy produktowi można zaufać, porozmawiaj z Syntanea. Możemy zrobić skupione due diligence i przygotować praktyczny plan handover albo naprawy.

Powiązane artykuły

Software project rescue plan - co zrobić, gdy due diligence pokazuje, że projekt już jest w tarapatach

Technical debt audit checklist - jak zamienić ryzykowne ustalenia w pracę porządkową

Software vendor selection checklist - jak porównać partnerów, zanim przejmą krytyczną pracę

Software development discovery phase - jak zmniejszyć niewiadome przed startem budowy

Software due diligence checklist: co sprawdzić przed przejęciem produktu