תשובה קצרה: קונה של אפליקציה שנבנתה ב-AI שואל שלוש שאלות: האם היא מאובטחת, של מי היא, והאם מישהו חוץ ממי שבנה אותה יכול להמשיך לפתח אותה. בפועל זה שמונה בדיקות, מהמפתחות החשופים ועד החשבונות שצריך להעביר לשמו. על כל אחת הוא מצפה לראיה. את רוב הראיות אפשר להכין לבד, לפני שמפרסמים את האפליקציה למכירה.
למה הבדיקה הזו שונה באפליקציה שנבנתה ב-AI
קונה של אפליקציה שמפתח כתב מניח שמישהו הבין את הקוד. באפליקציה שנבנתה ב-Lovable, Base44 או Cursor הוא לא מניח. שתי רשימות שפורסמו השנה מכסות את אותה שאלה מזוויות קרובות: Wavect (יוני 2026, עודכן בספטמבר) כותבת על מי ש"מגייס, מוכר או מהמר" על אפליקציה כזו, ו-SCAND (ספטמבר 2026) כותבת למשקיעים. שתיהן חברות שמוכרות את השירות הזה, ולכן הן מקור לרשימה, לא לנתונים. הרשימה למטה בנויה משתיהן ומהבדיקות שהצוות שלנו מריץ באפליקציות כאלה.
שמונה הדברים שקונה בודק
1. מפתחות סודיים חשופים
הדבר הראשון, והמהיר ביותר לבדוק: מפתח API או מפתח שירות של מסד הנתונים בקוד שהדפדפן מקבל, בקובץ .env שנכנס ל-git, או בהיסטוריה של ה-repo. זה הסימן שאף אחד לא עבר על הקוד. בדיקת האבטחה לאתר קוראת את הקוד שהאתר החי מגיש ומדווחת על מפתחות שדלפו. מפתח שנמצא מחליפים אצל הספק, כי מחיקה מהקוד לא מבטלת אותו.
מה מראים: רשימת מפתחות, איפה כל אחד שמור, ומתי הוחלף לאחרונה.
2. כללי הרשאות במסד הנתונים
האם משתמש אחד יכול לקרוא או לשנות נתונים של משתמש אחר. ב-Supabase, ובכל מסד נתונים שהאפליקציה פונה אליו ישירות מהדפדפן, זה תלוי בכללי ה-RLS של כל טבלה. Wavect מונה כדגל אדום סריקה שעברה בלי שאדם בדק את הכללים.
מה מראים: טבלה של כל טבלה ומה מותר בה, ותוצאה של ניסיון אמיתי עם שני חשבונות. איך מריצים אותו: המדריך ל-RLS.
3. תלות בספק אחד
אם האפליקציה היא בעיקר עטיפה סביב מודל AI אחד או API אחד, כל שינוי מחיר או תנאים אצל הספק עובר ישר לקונה. SCAND שואלת על כל שירות חיצוני כמה קשה יהיה להחליף אותו.
מה מראים: רשימת השירותים החיצוניים, מה כל אחד עולה בחודש, ומה קורה למרווח אם הספק המרכזי מעלה מחיר.
4. של מי הקוד, והאם הוא רץ מחוץ לפלטפורמה
שתי שאלות נפרדות. הראשונה משפטית: מה כתוב בתנאי השימוש של הפלטפורמה ביום שבניתם, והאם יש הסכם עם כל מי שכתב חלק מהקוד. השנייה טכנית: האם אפשר לייצא את הקוד, לבנות אותו ולהריץ אותו בלי הפלטפורמה. ב-Base44, למשל, קוד שיוצא ממשיך לעבוד מול ה-backend של הפלטפורמה. הפרטים במדריך הייצוא מ-Base44 ל-GitHub.
מה מראים: עותק מתוארך של התנאים, repo שבנוי ורץ, ומסמך קצר שמסביר איך מרימים את המערכת.
5. מי יכול לתחזק את זה
Wavect שואלת אם מישהו חוץ ממי שבנה יכול לשנות את המערכת, ו-SCAND מסמנת ידע שנמצא רק בראש של אדם אחד. באפליקציה שנבנתה בפרומפטים זה קורה הרבה: הכול עובד, אבל אף אחד לא יודע למה.
מה מראים: מסמך ארכיטקטורה של עמוד או שניים, איך מוסיפים פיצ'ר, ואיך בודקים שלא נשבר משהו אחר.
6. החשבונות שצריך להעביר
קונה קונה גם את מה שמסביב לקוד: הדומיין, האחסון, הפרויקט בפלטפורמה, מסד הנתונים, ספק המיילים, ספק התשלומים, וחשבונות המפתח ב-Apple וב-Google אם יש אפליקציה בחנויות. חשבון שעל שם פרטי של מפתח לשעבר יכול לעכב עסקה.
מה מראים: רשימה של כל חשבון, על שם מי הוא, ואיך מעבירים אותו. אם חלק מהחשבונות אצל מפתח שהפסיק לענות: מה עושים כשהמפתח עזב באמצע.
7. התשלומים
מי מקבל את הכסף היום, ובאיזה ספק. חשבון סליקה לא תמיד עובר כמו שהוא לבעלים חדש, ובאפליקציה שנבנתה ב-AI יש לרוב גם קוד תשלומים שהסוכן כתב לספק שלא מתאים לעסק ישראלי. על זה יש מדריך נפרד לסליקה באפליקציה שנבנתה ב-AI.
מה מראים: מאיזה ספק נגבה הכסף, איך הוא מחובר לאפליקציה, ומה צריך לקרות כדי שהתשלום יגיע לבעלים החדש.
8. נתוני המשתמשים
הקונה מקבל גם את המשתמשים. מה מותר לעשות עם המידע שלהם תלוי במה שמדיניות הפרטיות שלכם הבטיחה להם ובחוק שחל עליכם. SCAND מונה הגנת מידע כאחד הסעיפים. זו שאלה לעורך דין, לא לבודק קוד.
מה מראים: מפת נתונים בעמוד אחד: אילו פרטים נשמרים, באיזה שירות, ומי ניגש אליהם.
לפני שמפרסמים למכירה
| הבדיקה | מה מתקנים לבד | מתי צריך מישהו מבחוץ |
|---|---|---|
| מפתחות | מחליפים כל מפתח שנמצא ומעבירים אותו לצד השרת | כשלא ברור מה עוד דלף |
| הרשאות | בודקים עם שני חשבונות | כשיש כמה סוגי משתמשים או כמה לקוחות עסקיים |
| תלות בספק | רשימת שירותים ועלות | |
| קוד ופלטפורמה | ייצוא, בנייה והרצה | כשהקוד לא רץ מחוץ לפלטפורמה |
| תחזוקה | מסמך ארכיטקטורה קצר | כשאף אחד לא יודע להסביר חלק מהמערכת |
| חשבונות | רשימה והעברה לשם החברה | |
| תשלומים | לברר מול ספק הסליקה מה עובר | |
| נתוני משתמשים | מפת נתונים | עורך דין, תמיד |
SCAND ממליצה להפריד בתוכנית התיקון בין מה שחייב לתקן לפני עסקה לבין חוב טכני שאפשר לחיות איתו. קונה לא מצפה לאפס ממצאים. הוא מצפה לדעת מה מצאתם ומה עשיתם.
מה הבדיקה לפני השקה של VibeScale נותנת כאן, ומה לא
מה כן: מפתח בכיר עובר ביד על הקוד, מסד הנתונים, ההרשאות, המפתחות, התשלומים ועלות האירוח. תוך 72 שעות מקבלת הגישה אתם מקבלים דוח בעברית: כל ממצא עם חומרה, הסבר, דרך תיקון והערכת עלות. זה מכסה את סעיפים 1, 2, 3 ו-7, ואת החלק הטכני של סעיף 4. את הדוח אפשר להראות לקונה.
מה לא: זו לא חוות דעת משפטית על בעלות בקוד או על העברת נתונים, לא הערכת שווי של האפליקציה, ולא בדיקת חדירות פורמלית. כך נראה דוח לדוגמה. אם מי שמבקש את הבדיקה הוא משקיע ולא קונה, הרשימה דומה: מה מכינים למשקיע שביקש לראות שהאפליקציה מאובטחת.
מקורות
- Wavect - Lovable, Bolt, and Replit App Due Diligence: שלוש השאלות והדגלים האדומים (נקרא ב-29.10.2026)
- SCAND - Technical Due Diligence for Vibe-Coded Startups: מה בודקים, כולל תלות בשירותים חיצוניים ותוכנית תיקון (נקרא ב-29.10.2026)
המדריך הזה אינו ייעוץ משפטי. שאלות על בעלות בקוד, חוזים והעברת נתוני משתמשים כדאי לבדוק עם עורך דין.
מתכוננים למכור או להעביר את האפליקציה? בעמוד הבדיקה לפני השקה אפשר לקבוע שיחה ראשונית של רבע שעה בוואטסאפ. ספרו במה בניתם ומי הקונה, ונגיד לכם מה מהרשימה הזו אפשר להכין לבד ומה דורש בדיקה.
