Due diligence טכני הוא החלק בגיוס שמייסדים הכי פחות מתכוננים אליו — והחלק שיכול בשקט להרוג term sheet. משקיעים לא בודקים רק את השוק והמדדים שלכם. לפני או מיד אחרי term sheet, רוב המשקיעים המוסדיים (ויותר ויותר גם רוכשים בשלב צמיחה) מריצים בדיקה טכנית: ארכיטקטורה, אבטחה, חוסן צוות, וכמה מהעסק היה נשבר אם מהנדס אחד היה עוזב מחר.
החדשות הטובות: DD טכני צפוי. אותן 12 שאלות עולות כמעט בכל תהליך, בין אם זו בדיקה קלה ב-Series A או אודיט מעמיק לפני רכישה. תכירו אותן מראש ותוכלו להתכונן ב-30 יום במקום להיבהל בשלושת הימים שבין בקשת ה-DD למועד הסגירה.
למה DD טכני חשוב יותר ממה שמייסדים מצפים
DD טכני חלש נדיר שהורג עסקה ישירות — אבל הוא בצורה אמינה עושה שלושה דברים: מעכב את הסגירה בשבועות בזמן שהיועץ הטכני של המשקיע חופר עמוק יותר, הופך למנוף מיקוח שגורע נקודות מהשווי, ויכול לגרור תנאים לא נוחים (escrow, סעיפי תיקון) שקשורים לסיכונים שהתגלו. אף אחד מאלה לא הכרחי. כמעט כל פרצה ש-DD טכני מוצא ניתנת לתיקון תוך שבועות אם יודעים שהיא מגיעה.
12 השאלות שכל DD טכני של VC ישאל
| # | שאלה | איך נראה "טוב" |
|---|---|---|
| 1 | תיעוד ארכיטקטורה — יש דיאגרמת מערכת עדכנית והנמקה כתובה להחלטות מרכזיות? | דיאגרמת ארכיטקטורה עדכנית + מסמך קצר שמסביר טרייד-אופים מרכזיים (למה מסד הנתונים הזה, למה הענן הזה, למה ה-framework הזה) |
| 2 | כיסוי בדיקות — איזה חלק מהקוד מכוסה, ו-CI אוכף את זה? | כיסוי משמעותי על נתיבים קריטיים לעסק (לא בהכרח 100% בכל מקום), נאכף ב-CI, לא רק "יש לנו כמה בדיקות" |
| 3 | צינור דיפלוי — אפשר לשחרר תיקון לפרודקשן תוך פחות משעה, בבטחה? | CI/CD אוטומטי עם rollback, לא תהליך ידני של SSH ותפילה |
| 4 | מצב אבטחה — pen testing, סריקת פגיעויות, אודיט תלויות — מתי נעשה לאחרונה? | pen test או סריקת פגיעויות ב-12 החודשים האחרונים, עם ממצאים שמטופלים עד סגירה |
| 5 | חוסן צוות — מה קורה אם המהנדס הבכיר היחיד שלכם עוזב בחודש הבא? | בעלות מתועדת שמפוזרת על פני לפחות 2 אנשים לכל מערכת קריטית — אין single point of failure |
| 6 | בעלות על IP — יש הסכמי המחאת IP חתומים מכל תורם, כולל קבלני משנה מוקדמים? | 100% מתורמי הקוד (עובדים, קבלנים, שותפים מייסדים) חתמו על המחאת IP בתיק |
| 7 | נראות חוב טכני — אתם יודעים איפה החוב הטכני שלכם, והוא מתועדף? | רשימה כתובה ומדורגת של חוב ידוע והסיכון העסקי שלו — לא "נטפל בזה מתישהו" |
| 8 | אודיט תלויות — אתם מריצים חבילות open-source מיושנות או פגיעות? | סריקת תלויות אוטומטית (Dependabot, Snyk או שווה ערך) עם קצב עדכון |
| 9 | מוכנות תאימות רגולטורית — SOC 2, GDPR, HIPAA — היכן שרלוונטי לשוק שלכם, יש תוכנית או הסמכה בתהליך? | הסמכה קיימת, או מפת דרכים מתועדת עם בעלים ותאריך יעד |
| 10 | הוכחת סקייל — המערכת נבדקה בעומס, או "אנחנו חושבים שזה יסקייל" נשען על הנחה? | תוצאות load test או נתוני פרודקשן אמיתיים שמראים מרווח ב-3-5x מהנפח הנוכחי |
| 11 | היסטוריית אירועים — מה נשבר ב-12 החודשים האחרונים, ומה השתנה אחר כך? | לוג אירועים קצר עם root cause ותיקון לכל אחד — מראה שהצוות לומד, לא רק מכבה שריפות |
| 12 | סיכון key-person — מעבר להנדסה, העסק תלוי באדם אחד לתשתית, קשרי ספקים, או ידע מוסדי? | runbooks מתועדים ולפחות בעלים גיבוי אחד לכל מערכת קריטית וקשר ספקים |
הטבלה הזו היא גם הדרך המהירה ביותר לבדוק את עצמכם היום: תנו לעצמכם ציון 1 (אין תשובה) עד 3 (מתועד ועדכני) בכל שורה, ותדעו בדיוק איפה DD אמיתי היה כואב.
איך להתכונן ב-30 יום לפני גיוס
לא צריך לתקן את כל 12 התחומים בצורה מושלמת — צריך תשובות מוצדקות והתקדמות נראית לעין. ספרינט ריאלי של 30 יום נראה כך:
- שבוע 1 — הריצו את הבדיקה העצמית שלמעלה. דרגו את הפערים לפי מה הכי זול לתקן מול מה שיגרום הכי הרבה נזק אם יתגלה בלי הכנה (בדרך כלל: פערי המחאת IP, pen test חסר, ו-single points of failure לא מתועדים).
- שבוע 2 — סגרו את הפערים הזולים והבעלי-השפעה: השלימו המחאות IP תלויות, הפעילו סריקת תלויות, כתבו את מסמך הארכיטקטורה אם הוא לא קיים.
- שבוע 3 — הזמינו pen test או סריקת פגיעויות אם לא היה כזה ב-12 החודשים האחרונים; התחילו load test אם הוכחת הסקייל דלה.
- שבוע 4 — הרכיבו את חבילת ה-DD: מסמך ארכיטקטורה, דוח כיסוי בדיקות, לוג אירועים, מפת דרכים לתאימות, המחאות IP חתומות, תוצאות סריקת תלויות. מסרו אותה ליועץ המשפטי ולמשקיע המוביל באופן יזום — מייסד שמוסר חבילת DD נקייה בלי שביקשו נתפס כהשקעה בסיכון נמוך משמעותית ממי שנבהל כשמבקשים.
מי צריך להוביל את זה — ולמה זה תפקיד ברמת CTO
הכנת DD טכני נוגעת בו-זמנית בארכיטקטורה, אבטחה, היסטוריית גיוס, ומשפט (המחאת IP) — בדיוק החיתוך שאמור להיות בבעלות CTO. אם אתם מייסדים לא-טכניים, או שהשותף הטכני שלכם ראש-בקרקע בבנייה ואין לו קיבולת גם להפיק תיעוד מוכן-לאודיט, זה טריגר נפוץ להביא CTO חלקי. זהו גם אחד משבעת האותות הקונקרטיים שאנחנו מכסים ב-7 סימנים שהסטארטאפ שלך צריך CTO — לחץ due diligence לפני גיוס הוא אות מספר 3 ברשימה הזו.
CTO חלקי יכול להריץ בדיוק את תוכנית ה-30-יום הזו: לבדוק את 12 התחומים שלמעלה, לתעדף תיקונים, ולהפיק את חבילת ה-DD — בלי שתצטרכו לגייס ראש הנדסה במשרה מלאה רק כדי לעבור גיוס אחד. בצד התמחור — ראו כמה עולה CTO חלקי — הכנת DD בדרך כלל מתומחרת כפרויקט פיקס-פרייס ולא כריטיינר פתוח.
אם אתם 3-6 חודשים לפני גיוס ורוצים קריאה חיצונית, בעיני משקיע, על איפה ה-DD הטכני שלכם היה נופל — קבעו שיחת היכרות חינם של 15 דקות — ללא התחייבות, רק בדיקה ישרה של מה בודק טכני של VC היה מוצא.