בשבועיים האחרונים שאלו אותי את אותה שאלה ארבע פעמים, בניסוחים שונים: "בניתי אפליקציה עם Claude Code, אני רוצה להתחיל לגבות כסף עליה, מה עושים עכשיו?"

השאלה מגיעה בדרך כלל עם תחושה של "עוד מעט אני שם", אבל בפועל, בין ה-MVP לבין העסקה הראשונה יש שלוש שכבות שאנשים נוטים לערבב ביניהן. זה לא מכוון אפילו, פשוט אף אחד לא מלמד את זה.

לומדים לכתוב קוד עם AI, לומדים להרכיב מוצר, ואז פתאום מתנגשים בקיר של "רגע, איך אני בכלל גובה על זה כסף בצורה חוקית?" שלוש השכבות האלה הן:

• שכבה משפטית – מי אתה בעיני המדינה כשאתה גובה כסף.
• שכבה פיננסית – באיזה צינור אתה גובה את הכסף, ומי מטפל במיסים מסביב.
• שכבה טכנית – איך אתה מוודא שהמוצר שלך באמת מוכן לייצור ולא יתפוצץ ברגע שלקוח משלם יקיש על כפתור. רוב האנשים מנסים לפתור את שלוש השכבות עם פתרון אחד ("פייפאל + סטריפ + יאללה"), וזה בדיוק המקום שבו נכנסים לבעיות. בואו נפרק את זה לפי שכבות, לפי הסדר שבו צריך לפתור אותן.

אבל, לפני שנתחיל, נקודה חשובה: אני לא רו"ח ואני לא עורך דין! הכתוב פה הוא מניסיון אישי ומניתוח טכני, בשום צורה ואופן לא ייעוץ משפטי או פיננסי. לפני החלטות כסף אמיתי – דברו עם בעל מקצוע מוסמך וחיסכו לעצמכם בעיות גדולות בהמשך.

ועכשיו לענייננו:

שכבה 1: משפטית

פייפאל זה לא פתרון.

השאלה הראשונה שהופיעה הייתה: "האם אני חייב להיות עוסק מורשה, או שעוסק פטור מספיק? או שמספיק מספר פייפאל?" התשובה הקצרה: פייפאל זה צינור, לא ישות. זה כמו לשאול "אני חייב דרכון או שמספיק ששכרתי מונית לשדה התעופה?" אלה שאלות שונות.

כדי לקבל כסף על שירות באופן חוקי בישראל, אתה צריך תיק פתוח ברשויות המס.

זה לא קשור לשאלה איפה הלקוח שלך יושב, או באיזה מטבע הוא משלם. ברגע שאתה מספק שירות ומקבל תמורה, המדינה רוצה לדעת על זה, ויותר מזה, החוק מחייב אותך לידע אותה.

יש לך שתי אפשרויות מעשיות:

(בתכלס יש עוד אפשרויות, אבל לצורך הדיון נתחיל עם השתיים שהן הכי רלוונטיות לדיון הזה.)

1. עוסק פטור – לשנת 2026, תקרת ההכנסות השנתית היא 122,833 ש"ח, מתחת לתקרה הזאת, אתה פטור מגבייה ודיווח של מע"מ. הוא הדין בתקרה בלבד: מס הכנסה וביטוח לאומי עדיין חלים עליך מהשקל הראשון. למי שזורק MVP ורוצה לבדוק אם יש שוק, זה המסלול ההגיוני להתחיל בו. פחות בירוקרטיה, פחות הנהלת חשבונות, אפשר לפתוח אונליין ללא עלות.

2. עוסק מורשה – אין תקרה. אתה גובה מע"מ (18% כיום, שימו לב לעדכון משנת 2025), מדווח פעם בחודש או חודשיים, ויכול לקזז מע"מ תשומות (כלומר, להחזיר את המע"מ ששילמת על הוצאות עסקיות כמו Claude API, אחסון, דומיינים וכו'). לטווח ארוך זה עדיף אם אתה צופה הכנסות מעל התקרה או הוצאות עסקיות משמעותיות. לטווח קצר זה יותר חיכוך.

הערה חשובה לבוני SaaS שמוכרים בחו"ל: אם רוב ההכנסה שלכם מגיעה מלקוחות מעבר לים דרך פלטפורמה שמשלמת לכם בדולרים, המצב שלכם שונה מבעל דוכן פלאפל בתחנה המרכזית. התייעצו עם רו"ח לפני שאתם קובעים מבנה. לא כי זה מסובך, אלא כי הבדל של עשרות אלפי שקלים בשנה בעלויות מס מצדיק שיחה של חצי שעה.

השורה התחתונה של השכבה המשפטית: פתחו תיק לפני שאתם פותחים חשבון בשום פלטפורמת סליקה. פייפאל, סטריפ, Lemon Squeezy – כולם ידרשו מכם זיהוי עסקי כדי להפעיל את החשבון בצורה נקייה.

שכבה 2: פיננסית

למה Lemon Squeezy ולא סטריפ (וגם למה התשובה משתנה ב-2026)? - כאן הדברים מעניינים, ומעניינים יותר ממה שחשבתי כשהתחלתי לכתוב את המאמר הזה.

בסיס החישוב: כשאתה מוכר SaaS בינלאומי, אתה נכנס למאבק עם מושג שנקרא מע"מ בינלאומי (VAT). אם מכרת ללקוח בגרמניה, אתה אמור לגבות ממנו 19% VAT גרמני. בבריטניה – 20%. באוסטרליה יש GST, בארה"ב יש sales tax ברמת המדינה (אפילו לא ברמת הפדרלית). כל מדינה זה חוקים, דיווחים, רישומים.

עכשיו – מי עושה את הבלגאן הזה בשבילך?

סטריפ קלאסי (2.9% + 0.30$): אתה! אתה המוכר הרשום (Seller of Record). אתה אחראי על חישוב, גביה ודיווח של כל מס בכל תחום שיפוט שבו יש לך לקוחות. אפשר לקנות את Stripe Tax כשכבת עזר, אבל הדיווח והרישום עדיין עליך. ומה שנקרא, בהצלחה לכל העוסקים בדבר.

Lemon Squeezy (5% + 0.50$, ועוד 1.5% על עסקאות בינלאומיות): הם! הם ה-Merchant of Record (MoR). זה אומר שמבחינה משפטית הם מוכרים ללקוח, ואתה מוכר ל-Lemon Squeezy. הם גובים את המס המקומי של כל מדינה, מדווחים עליו, ומעבירים לך סכום נטו. על הקבלה של הלקוח כתוב "Lemon Squeezy" ולא השם שלך.

זה ההבדל שמצדיק את פער העמלות. 2% פער במחיר קופון (במקרה של עמלת סטריפ קלאסי מול Lemon Squeezy) שווה לכם את עצמו ברגע שלא צריך לעסוק עם רישום VAT באיחוד האירופי, הגשת רבעון ל-HMRC הבריטי, או המאבק בסיוט הרגולטורי של 50 מדינות אמריקאיות שכל אחת רוצה את שלה.

עכשיו הטוויסט: ביולי 2024 סטריפ רכשה את Lemon Squeezy. ב-2026 סטריפ השיקה גרסת beta משלה ל-Merchant of Record (תוספת של כ-3.5% מעל עמלות הסטנדרט), ו-Lemon Squeezy ממשיך לפעול עצמאית אבל עם מפת דרכים קצת לא ברורה.

בשוק צצו מתחרים חדשים שווים לבדיקה: Paddle (ותיק, 5% + 0.50$), Polar (4% + 0.40$), Creem (3.9% + 0.40$).

אז האם Lemon Squeezy עדיין הבחירה הנכונה? בעיניי, כן, אבל לא באופן אוטומטי: אם אתה יוצא עכשיו עם מוצר ורוצה פשטות מקסימלית – Lemon Squeezy עדיין עומד חזק. UX נקי, תיעוד מצוין, קינפוג והגדרות של 15-30 דקות. ובום, יש לך חנות אונליין.

אם אתה רגיש לעמלות – תסתכל על Polar או Creem. הם MoR אמיתיים, עמלות נמוכות יותר, וב-2026 הם בוגרים מספיק לשרת חברות אינדי.

אם אתה כבר משקיע בתשתית סטריפ – חכה שהגרסה הרשמית של Stripe MoR יוצאת מ-beta, או לך על Lemon Squeezy שיש לו אינטגרציה עמוקה עם הקבוצה.

השירות לא חינמי, כדי לענות על השאלה הישירה. אף אחד ממה שהזכרתי לא חינמי. אין פלטפורמת סליקה חינמית לעסקים. אבל ההשוואה הנכונה היא לא "עמלה מול חינם", אלא "עמלה מול רו"ח בינלאומי + סיכון רגולטורי + זמן שלך". בחישוב הזה, MoR מנצח עבור מפתח בודד כמעט תמיד.

שכבה 3: טכנית

השאלה השלישית של הקורא הייתה על סקילים של GitHub שמריצים בדיקות סופיות. התשובה היא כן, וזה החלק שרוב האנשים מזלזלים בו.

הבעיה בעידן של Claude Code: קל מדי לייצר קוד ש"עובד", ויש הרבה מאוד מקרים שאינם "עובדים". מכירים משפט מיתולוגי מעולם הפיתוח? "אצלי זה עובד"

.. אז זהו, שלא בדיוק. אז לפני שאתם פותחים את הברז לתשלומים, אלה שלוש הרובריקות שאני מריץ:

• אבטחה בסיסית (CI, אוטומטי): סריקת סודות – gitleaks או trufflehog ב-GitHub Actions. וידוא ש-API keys לא דולפים לרפוזיטורי. זה קורה יותר ממה שאנשים מודים. ניתוח סטטי – semgrep או CodeQL עבור החולשות הנפוצות (injection, XSS, יוציא דברים כמו eval על user input). סריקת תלויות – npm audit או Dependabot. זיהוי חולשות בספריות שאתם משתמשים בהן. זה לא תחליף לבדיקת חדירה אמיתית, אבל זה מסנן את 80% מהטעויות הטיפשיות לפני שהן מגיעות ל-production.
• בדיקות פונקציונליות אג'נטיות: כאן Claude Code הופך ליתרון אמיתי. במקום לכתוב בדיקות E2E ידנית, אני נותן לסוכן לעבור על הזרימות הקריטיות (signup, checkout, עליית נתונים, API endpoints רגישים) ומייצר בדיקות שמתעדכנות אוטומטית באמצעות Playwright. זה לא מחליף חשיבה על edge cases, אבל זה חוסך ימים של כתיבה ידנית.
• בדיקת "מה קורה ב-3 בלילה": מה קורה אם המודל לא מחזיר תשובה? מה קורה אם Claude API מחזיר 429 (rate limit)? מה קורה אם Lemon Squeezy שולח webhook בזמן שהשרת שלך קורס? אל תחכו שזה יקרה מול לקוחות אמיתיים. זה מביך, וזה הורג את הביזנס שאתם מנסים להריץ. הריצו תרחישי כשל עכשיו.

המלצה קונקרטית:

צרו קובץ SECURITY.md ו-.github/workflows/pre-launch.yml בפרויקט לפני ה-launch, עם לפחות: gitleaks, sempgrep, ו-bundle audit רץ על כל PR.

ההחלטה המעשית, לפי סוג המפתח, לחסוך לכם זמן, ככה אני הייתי מחליט:

אתה Vibe Coder, שרק רוצה לראות אם יש שוק למוצר שלך: עוסק פטור + Lemon Squeezy + GitHub Actions בסיסי. Launch תוך שבועיים.

אתה מפתח מנוסה, בונה SaaS שמתכנן לצמוח: התייעצות קצרה עם רו"ח, עוסק מורשה אם אתם צופים הוצאות משמעותיות, MoR לבחירתכם, CI מלא.

אתה גרפיקאי/PM שבנה משהו נחמד עם קלוד קוד או קודס: אל תדלג על שכבה 3. עודף תעוזה פה זה מה שעושה את ההבדל בין "הרווחתי 5,000 דולר" ל"איבדתי גישה לחשבון של 50 משתמשים כי ה-DB נמחק".

בסוף, הדרך מ-MVP לעסק עובר דרך שלוש הדלתות האלה, ולא דרך דלת אחת קסומה. הדלת המשפטית, הפיננסית והטכנית. כשמטפלים בכל אחת מהן בנפרד, זה מרגיש פשוט. כשמנסים לטפל בשלושתן, כשאתם בהייפ אחרי שהMVP עבד, זה בדרך כלל נופל.

ולסיכום, חוזר על הנקודה החשובה מלמעלה: אני לא רו"ח ואני לא עורך דין! הכתוב פה הוא מניסיון אישי ומניתוח טכני, בשום צורה ואופן לא ייעוץ משפטי או פיננסי. לפני החלטות כסף אמיתי – דברו עם בעל מקצוע מוסמך וחיסכו לעצמכם בעיות גדולות בהמשך.

בהצלחה לכולם!