איך לבנות מוצר SaaS עברי-ראשון עם AI
איך לבנות מוצרי SaaS מונעי AI שמדברים עברית בצורה טבעית, מהגדרת RTL ועד copy מקורי, על בסיס מוצרים אמיתיים ששיגרתי.
לבנות מוצר SaaS עברי-ראשון זה לא להוסיף RTL בסוף. זה אומר שהעברית היא חוויית המשתמש הראשית מהיום הראשון: ה-copy, פרומפטי ה-AI, הודעות הוולידציה, ה-onboarding. שיגרתי מוצרים כאלה, כולל Tadam, סטודיו AI ליצירת מודעות עברי-ראשון, ו-Brainers Club, פלטפורמת קהילה שצמחה מעל 10,000 חברים. הדפוס עקבי: להתחיל עברי-ראשון תמיד זול יותר מ-retrofit מאוחר יותר.
RTL זה החלק הקל
ה-attribute של dir=rtl לוקח כמה דקות להוסיף. מה שלוקח עבודה אמיתית הוא כל השאר: microcopy שלא נשמע כמו תרגום מכונה, פרומפטים שמייצרים עברית ישראלית טבעית ולא עברית פורמלית, ואלמנטי אמינות שעובדים עם קהל מקומי. משתמשים ישראלים זזים מהר ועוזבים מהר. אם המוצר מרגיש כמו כלי אמריקאי שהפכו אותו אופקית, הם שמים לב.
הסטאק ועבודת הפרומפטים
אני בונה על Next.js עם Supabase ל-data ו-Claude כשכבת ה-AI. במוצרים בעברית, עיקר העבודה האמיתית היא ב-prompt engineering. כשבניתי את Tadam, השקעתי יותר שעות בכיוון פרומפטי ה-copy לעברית מאשר ב-UI. Claude מטפל בעברית טוב, אבל הוא צריך כיוון: לציין את הרגיסטר (ישראלי קז'ואל, מוכוון-שיווק, או פורמלי), אם להשתמש במילים לועזיות, ומי הקורא. כותבים פרומפטים בעברית כשה-output הוא עברית. המודל מגיב לשפה שהוא מקבל.
- מגדירים dir=rtl על אלמנט ה-html ומשתמשים ב-RTL-aware CSS utilities מה-commit הראשון, לא כתוספת מאוחרת
- כותבים פרומפטים ל-AI בעברית כשה-output הוא עברית, לא באנגלית עם הוראת תרגום בסוף
- בודקים copy שנוצר על ידי AI עם קורא ישראלי ילידי או עם סבב review של Claude לפני פרסום
- מתכננים לפי קונבנציות UX ישראליות: תאריכים בפורמט dd/mm/yyyy, מטבע שקלי, אמצעי תשלום מקומיים
- משאירים שמות מוצר לועזיים כמו SaaS, AI ו-Next.js כפי שהם, ומתרגמים את כל שאר טקסט הממשק
הטעות שאני רואה הכי הרבה
רוב בעלי העסקים שעברו דרך ה-Claude Code Workshop שלי מתייחסים ל-localization ולעברי-ראשון כאותו הדבר. הם לא. Localization אומר לתרגם מוצר קיים. עברי-ראשון אומר שהמוצר מעולם לא נבנה לשפה אחרת מלכתחילה. ההבדל מתגלה ב-output של ה-AI: אם המודל מקבל פרומפט באנגלית וה-output מתורגם, ה-copy ייקרא כמו תרגום. קוראים ילידים תמיד מרגישים את זה. בונים את שכבת ה-AI לעברית מהתחלה, והמוצר ירגיש שייך.
אני מנהל את כל המוצרים האלה לבד או עם צוות קטן מאוד. מה שמאפשר את זה הוא workflow מונע-AI שבו Claude Code מטפל ברוב ה-implementation ואני נשאר ברמת המוצר והארכיטקטורה. לעבודה עברי-ראשון ספציפית, אני משתמש ב-Claude כדי לנסח ולבדוק את כל ה-copy בעברית לפני שהוא עולה לאוויר, מה שמייתר את הצורך בקופירייטר ייעודי מהיום הראשון. כשאני מלמד את זה ב-nCode ל-600-פלוס סטודנטים, אני מסגר את זה כך: AI לא מחליף את המפתח, הוא מסיר את התקורה שהשווקים הקטנים נהגו להטיל על בוני-יחיד.
FAQ
האם Claude באמת טוב ב-copy עברי, או שהוא מייצר משהו שצריך עריכה כבדה?
Claude מטפל בעברית טוב לפי הניסיון שלי, אבל הוא צריך כיוון ברור בפרומפט. המפתח הוא לציין את הרגיסטר והקהל היעד באופן מפורש. ל-copy שיווקי ישראלי קז'ואל, אני מקבל טיוטות ראשונות שימושיות בערך 70 אחוז מהמקרים. לטקסט פורמלי או משפטי, אני תמיד עושה סבב בדיקה אנושי. המודל עובד טוב יותר באופן ניכר כשמכתבים לו פרומפט בעברית ולא כשמבקשים ממנו לתרגם מאנגלית.
איך מגדירים RTL נכון בפרויקט Next.js מהיום הראשון?
מגדירים lang=he ו-dir=rtl על אלמנט ה-html בקובץ ה-layout. משתמשים ב-RTL utilities של Tailwind, ה-prefix של rtl:, במקום לקודד ערכי CSS כיווניים כמו margin-left או padding-right. עדיף להשתמש בתכונות CSS לוגיות כמו margin-inline-start ו-padding-inline-end. מתחילים נכון מהיום הראשון ולא יהיה refactor של שלושה ימים אחר כך.
האם מפתח אחד יכול בצורה ריאליסטית לבנות ולתחזק מוצר SaaS עברי-ראשון בלי צוות ייעודי?
כן, אני עושה את זה במספר מוצרים במקביל. המגבלה הריאליסטית היא לא כושר ייצור אלא פוקוס: צריך להיות דובר שפת האם בעברית או גישה קרובה לאחד. AI יכול לכתוב copy בעברית אבל הוא לא יכול לומר לך אם הטון מתאים לשוק הספציפי שלך. היזמים הסולו שמשגרים מוצרים טובים הם אלה שמשתמשים ב-AI לאקזקיושן ונשארים אחראים אישית לשפה ולהתאמה התרבותית.