Tech due diligence inför Series A - vad investerare faktiskt granskar

Pre-A går igenom på affärsmodell och team. Series A börjar tekniken granskas på riktigt - investerarna förbinder sig till en multipel som kräver att tekniken faktiskt kan skala. Bristande tech DD är en av de tre vanligaste anledningarna till att en term sheet aldrig blir signerad eller priset sänks i slutskedet.

En grundlig tech DD täcker sex områden:

• • Arkitektur & teknisk skuld - håller det för 10× tillväxt? Vad är skulden?
• • Kod- och produktkvalitet - täckning, releaser, buggrate
• • Team & nyckelpersoner - bus factor, kompetens, retention
• • Säkerhet & compliance - GDPR, NIS2, SOC2, hostingsplats
• • Infrastruktur & drift - kostnad, skalbarhet, observability
• • Processer & governance - CI/CD, release management, change control

Granskningen handlar inte om att hitta perfekta system - den handlar om att förstå om arkitekturen är medveten eller emergent, och om teknisk skuld är dokumenterad och prioriterad.

Förvänta er frågor som:

• • Hur ser systemarkitekturen ut? (skissa på whiteboard)
• • Vilka är de tre största tekniska skulderna och vad kostar de att åtgärda?
• • Hur skalar systemet vid 10× nuvarande trafik?
• • Vad händer om er primära databas går ner?

Här letar investerare efter "bus factor" - hur mycket av tekniken sitter i huvudet på en eller två personer? Och: är CTO/lead-dev rätt för nästa fas?

• • Organisations-skiss med roller och senioritet
• • Retention över senaste 24 månaderna
• • Vilka medarbetare är "single points of failure"?
• • Hiring plan för nästa 12 månader med budget

Förväntad för B2B SaaS, EnterpriseTech, FinTech, HealthTech. Mindre kritisk för rent B2C.

• • GDPR-efterlevnad: DPA, data residency, RoPA
• • NIS2 om ni omfattas (allt fler gör)
• • SOC2 / ISO 27001 - har ni eller är på väg?
• • Tidigare incidenter - vad hände, hur löstes det?
• • MFA, IAM, audit-loggning

• • Molnleverantör och region (EU-residency?)
• • Månatlig infrastrukturkostnad och utvecklingen senaste 12 mån
• • Hur övervakas systemet? Vilken är ert nuvarande SLA?
• • Backup-strategi, RTO, RPO
• • Vad händer vid en allvarlig incident? Vem är jour?

• • Hur går en feature från idé till produktion?
• • Releasecadence och rollback-process
• • Code review-praxis
• • Hur dokumenteras tekniska beslut (ADRs)?
• • Hur hanteras tech debt strukturellt?

Förbered detta i en data room INNAN DD startar - det ger 2-3 veckors försprång:

• • Arkitekturdiagram (current + target)
• • Stack-översikt med licenskostnader
• • Organisationsskiss med roller, senioritet och attrition
• • Incident-log senaste 12 månaderna
• • Hiring plan med budget
• • Säkerhetspolicys och DPA-avtal
• • Top-3 tekniska skulder med åtgärdsplan
• • Disaster recovery- och business continuity-plan
• • Senaste pen-testresultatet (om sådant finns)
• • Roadmap (12 mån) kopplad till hiring och kostnad

• Single tech founder utan team

  Investerare räds bus factor. Permanent CTO eller stark lead bör finnas.

• Ingen dokumentation alls

  Inga ADRs, inga runbooks. Tyder på fragmenterad kunskap och risk.

• Kostnader som skenar med användning

  Ineffektiv arkitektur som inte håller vid 10×.

• Tekniska skulder utan plan

  Skuld finns alltid - men utan plan signalerar bristande styrning.

• Säkerhetshändelser som inte rapporterats

  Förtroendekris. Bättre att vara öppen med vad som hänt och vad som åtgärdats.

• CTO som inte kan svara på kommersiella frågor

  Föreslår att teknisk ledning är frikopplad från affären.

En full tech DD tar typiskt 2-4 veckor. Den startar parallellt med kommersiell DD och avslutas med en rapport till investeringskommittén. Förberedda bolag klarar igenom på kort tid med få ändringar i term sheet. Oförberedda bolag tappar veckor eller får sänkt värdering.