Teknisk Due Diligence inför Series B/exit: 47-punkts-checklistan

När ett bolag tar in en Series B eller förbereder en exit kommer någon att titta under huven. Det är inte längre grundarens pitch som gäller, utan en strukturerad granskning där en oberoende part bedömer om tekniken är värd det priset säger. Jag sitter ibland på den granskande sidan och ibland på bolagets sida, och det har lärt mig en sak: de bolag som klarar teknisk due diligence väl är inte de med vackrast kod, utan de som kan visa att de förstår sin egen risk.

Den här artikeln är en strukturerad genomgång av vad en teknisk DD inför Series B eller exit faktiskt undersöker. Jag har samlat punkterna i sju områden snarare än att rada upp 47 lösryckta frågor, eftersom det är så en seriös granskare tänker.

Varför Series B-DD skiljer sig från en exit-DD

Det finns en viktig skillnad mot en ren exit-granskning. Vid Series B köper investeraren framtida tillväxt och frågar främst: kan den här arkitekturen bära tio gånger fler kunder utan att rämna? Vid en exit köper förvärvaren ett färdigt värde och frågar i stället: vilka dolda skulder och risker tar vi över? Samma kodbas granskas, men linsen är olika. Förbereder ni er för en runda ska ni visa skalbarhet; förbereder ni en försäljning ska ni minimera överraskningar.

Område 1: Arkitektur och skalbarhet

Granskaren vill förstå om systemet är byggt för att växa eller om det redan börjat krackelera under nuvarande last. Här tittar man på hur tjänsterna är uppdelade, var flaskhalsarna sitter, hur databasen skalar och om det finns enskilda komponenter som skulle stoppa hela plattformen om de föll. Ni behöver inte ha en perfekt mikrotjänstarkitektur. Ni behöver kunna förklara era val och visa att ni vet var gränserna går.

Område 2: Kodkvalitet och teknisk skuld

Ingen förväntar sig en kodbas utan skuld. Det granskaren letar efter är om ni vet var skulden finns och har en plan för den. En medveten, dokumenterad skuld är ett tecken på mognad. En osynlig skuld som ingen pratar om är en röd flagga. Testtäckning, hur lätt en ny utvecklare kommer igång och hur ofta saker går sönder vid deploy säger mer än antalet rader kod.

Område 3: Säkerhet och regelefterlevnad

Här blir det konkret snabbt. Hur hanteras hemligheter och nycklar? Finns det åtkomststyrning med minsta möjliga behörighet? Hur ser ni på säkerhet i leverantörskedjan? För bolag som hanterar persondata granskas GDPR-efterlevnad noggrant, och för bolag inom reglerade branscher kommer även branschspecifika krav upp. Brister här kan sänka värderingen direkt eftersom de översätts till framtida kostnad och risk.

Område 4: Drift, beroenden och nyckelpersonsrisk

En av de vanligaste anmärkningarna jag skriver handlar om personberoende. Om bara en person förstår en kritisk del av systemet är det en konkret risk som köparen prissätter. Samma sak gäller leverantörsberoenden: om ni är helt inlåsta hos en plattform utan rimlig exit-väg är det en risk. Mer om det i artikeln om vendor lock-in.

Det här är precis sådant jag granskar och hjälper bolag att åtgärda inom teknisk rådgivning, gärna i god tid innan en process drar igång.

Område 5: Immateriella rättigheter och licenser

Äger bolaget faktiskt sin kod? Det låter självklart men är det inte alltid. Konsulter som inte överlåtit rättigheter, öppen källkod med licenser som smittar er egen kod, och oklarheter kring vem som byggt vad är vanliga fynd. En förvärvare vill ha ren äganderätt, och en oklarhet här kan stoppa en affär helt.

Område 6: Team och process

Granskaren bedömer inte bara koden utan organisationen som producerar den. Hur fattas tekniska beslut? Hur ser releaseprocessen ut? Kan teamet fortsätta leverera utan grundaren i rummet? Ett välfungerande team med tydliga processer höjer värdet, eftersom köparen då vågar lita på att leveransen fortsätter efter affären.

Område 7: Dokumentation och datarum

Det sista området är hur väl ni kan visa allt ovanstående. Ett välorganiserat datarum med arkitekturöversikter, beslutslogg, säkerhetsdokumentation och ett uppdaterat systemdiagram gör hela skillnaden för intrycket. En granskare som snabbt hittar svaren får förtroende; en som får leta drar slutsatsen att det finns mer som inte visas.

Hur du förbereder dig

Det bästa rådet jag kan ge är att göra en intern DD innan den externa börjar. Gå igenom de sju områdena med kritiska ögon, åtgärda det värsta och dokumentera det ni medvetet lämnar. Då sitter ni i förarsätet när granskaren ringer, i stället för att försvara er.

Relaterat

• Build vs Buy 2026: När bygga AI internt och när köpa SaaS
• Teknisk roadmap för scale-ups: Från MVP till enterprise-arkitektur
• Vendor lock-in: Riskmatris och exit-strategier för molntjänster

Exempel på hur en granskning landat i praktiken finns i kundcase.

Vill du ta det vidare?

Förbereder ni en runda eller en försäljning gör jag gärna en intern teknisk DD innan motparten gör sin. Boka ett samtal så går vi igenom var ni står mot de sju områdena idag.