Tech due diligence – guide för förvärv och investeringar

I varje förvärvsprocess jag deltagit i som rådgivare finns samma mönster: säljarens tekniska team är optimistiska, demot är polerad, och koden ser bra ut på ytan. Teknisk due diligence handlar om att gå bortom ytan – att förstå den tekniska skulden, nyckelpersonberoenden, skalbarhetsbegränsningar och de arkitekturella vägval som kan bli dyra att riva upp efter ett förvärv. Det är en av de bästa investeringar en köpare eller investerare kan göra, och en av de mest underskattade.

Den här guiden går igenom vad en teknisk due diligence faktiskt täcker, hur processen ser ut i praktiken, vad den kostar, och de fynd vi återkommande stöter på – både de som sänker priset och de som bekräftar att affären är trygg.

Varför tekniska granskningar ofta hoppas över – och varför det är ett misstag

”Vi kan alltid fixa tekniken efteråt” är en kliché som kostat miljontals kronor i oväntade ombyggnationer. Köpare underskattar systematiskt värdet av en teknisk granskning, delvis för att den kräver en kompetens som varken affärsutvecklare eller finansiella rådgivare besitter, och delvis för att en polerad demo lätt förväxlas med en solid arkitektur. En teknisk due diligence kostar i vår erfarenhet vanligtvis mellan 40 000 och 80 000 kronor beroende på kodbasens storlek och komplexitet – en försumbar summa jämfört med ett förvärv på tiotals eller hundratals miljoner, men den summa som oftast avgör om affären går igenom oförändrad, omförhandlas, eller stoppas helt.

De fyra dimensionerna en teknisk granskning täcker

En strukturerad teknisk due diligence rör sig alltid genom fyra områden. Vi går igenom var och en separat nedan, men det är kombinationen av dem som ger den fulla riskbilden.

• Kodbas och arkitektur – är den välstrukturerad, testad och dokumenterad, eller bräcklig och beroende av tyst kunskap?
• Team och kompetens – sitter kritisk kunskap hos en enda person, och vad händer om den personen slutar dagen efter förvärvet?
• Drift och infrastruktur – hur ser driftsättning, övervakning, säkerhet och incidenthantering ut i praktiken, inte bara på papper?
• Framtida investeringsbehov – vad måste byggas om eller moderniseras inom tolv månader för att produkten ska hålla?

Kodbas och arkitektur – vad vi faktiskt letar efter

Vi tittar på testtäckning, kodkomplexitet, beroendehantering och hur konsekvent arkitekturen är applicerad över tid. En kodbas som växt organiskt under fem år utan refaktorering ser ofta bra ut i en demo men blir successivt dyrare att bygga vidare på – varje ny feature tar längre tid än föregående, ett tydligt tecken på ackumulerad teknisk skuld. Vi granskar också beroenden till föråldrade bibliotek eller plattformar som snart tappar support, eftersom det ofta innebär ett dolt moderniseringsprojekt som köparen annars ärver utan att veta om det.

Det handlar inte om att döma varje genväg som togs under produktens tidiga år – de flesta snabbväxande bolag har genvägar, och det är rimligt. Frågan vi faktiskt svarar på är om skulden är hanterbar och synlig, eller dold och accelererande.

Team och nyckelpersonberoende

Det vanligaste enskilda fyndet i våra granskningar är nyckelpersonberoende: en eller två utvecklare som sitter på kritisk, odokumenterad kunskap om hur systemet faktiskt hänger ihop. Om den personen inte stannar kvar efter förvärvet – vilket ofta är precis vad som händer när en grundare säljer och lämnar – kan värdet på det förvärvade bolaget sjunka dramatiskt inom sex månader. Vi kartlägger detta genom strukturerade samtal med teamet, en genomgång av commit-historik och genom att fråga rakt ut vem som skulle behöva kontaktas om något gick sönder klockan tre på natten.

Drift, infrastruktur och säkerhet

Här granskar vi hur driftsättning faktiskt går till, vilken övervakning som finns på plats, hur incidenter historiskt hanterats, och om grundläggande säkerhetspraxis följs – autentisering, åtkomstkontroll, kryptering och loggning. Det är i den här dimensionen vi oftast hittar avvikelser mellan vad som sägs i ett säljmemorandum och vad som faktiskt finns implementerat. En arkitektur som ”följer branschstandard för säkerhet” enligt säljaren visar sig ibland sakna grundläggande skydd som skulle upptäckas i en riktig säkerhetsgranskning.

Framtida investeringsbehov och hur det påverkar värderingen

Det sista steget är att omsätta de tre föregående dimensionerna i en konkret prognos: vad måste byggas om, moderniseras eller åtgärdas inom det första året efter förvärvet, och vad kostar det? Det här är ofta det mest värdefulla för köparen, eftersom det direkt påverkar förhandlingen. Ett förvärv med tydlig teknisk skuld är inte automatiskt en dålig affär – men priset ska spegla den investering som krävs för att komma ikapp, inte ignorera den.

Processen: från första kontakt till rapport

En avgränsad teknisk due diligence tar normalt en till två veckor från NDA till slutlig rapport, beroende på kodbasens storlek och hur tillgängligt säljarens team är under processen. Processen börjar med ett strukturerat samtal om vad som står på spel i affären, följs av en genomgång av kod, arkitektur, dokumentation och intervjuer med nyckelpersoner, och avslutas med en skriftlig riskrapport som presenteras för ledning eller investerare. Rapporten ska vara direkt användbar i förhandlingen – inte en teknisk essä som bara en utvecklare kan tolka.

Slutsats

En teknisk due diligence är en billig försäkring mot en dyr överraskning. Den vanligaste orsaken till att förvärv blir dyrare än planerat är inte att säljaren ljugit – det är att ingen med rätt kompetens tittade tillräckligt nära innan affären stängdes. Oavsett om ni är på köpar- eller säljarsidan, och oavsett om det gäller ett fullt förvärv eller en investeringsrunda, är en strukturerad teknisk granskning skillnaden mellan ett informerat beslut och en gissning. Om ni har en affär på gång och behöver en oberoende teknisk granskning: läs mer om våra tjänster eller boka ett samtal.