כלים למפתחים בעברית: לבנות מוצר SaaS עם AI

כדי לבנות מוצר SaaS בעברית לא צריך מחשב מיוחד או ציוד ייעודי לשפה. צריך סביבת פיתוח שנוח לעבוד בה עם עברית, ממשק שתומך ב-RTL, וכלים שמאפשרים לבדוק מה המשתמש באמת רואה. אני בונה עם Next.js ו-Supabase, ונעזר ב-Claude Code לכתיבת הקוד. כשיש במוצר יכולות AI, אני משתמש גם ב-Claude. אבל בחירת הכלים היא רק ההתחלה. צריך להגדיר איך העברית אמורה לעבוד בכל שלב במוצר, ואיך בודקים שהתוצאה טובה.

במוצר שמיועד קודם כול לדוברי עברית, השפה משפיעה על כל המסלול: המסך הראשון, שמות השדות, הודעות השגיאה, התוכן שנוצר והדרך לחזור לפעולה כשמשהו נכשל. ב-Tadam, סטודיו ה-AI שלי ליצירת מודעות בעברית, הטקסט הוא חלק מהמוצר שהלקוח בא לקבל. תשובה תקינה מבחינה טכנית עדיין יכולה להיות מודעה שאי אפשר להשתמש בה. ב-Brainers Club, פלטפורמת קהילה עם יותר מ-10,000 חברים, אותו עיקרון מופיע בטקסטים היומיומיים של הממשק. המשתמש צריך להבין מה לעשות בלי לפענח ניסוח מתורגם.

הכלים שאני מכין לפני תחילת הפיתוח

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

• עורך קוד וקלט: מגדירים מקלדת בעברית ובודקים שנוח לערוך טקסט עברי לצד שמות משתנים ומונחים באנגלית. שמות בקוד צריכים להישאר ברורים למי שמתחזק אותו.
• שפה וכיוון: מגדירים lang="he" ו-dir="rtl" על שורש המסמך בעברית. אלה שתי הגדרות נפרדות, ושתיהן צריכות להיות נכונות.
• עיצוב: מעדיפים מאפייני CSS לוגיים כמו margin-inline-start ו-padding-inline-end, או את הכלים המקבילים במערכת העיצוב הקיימת.
• בדיקה בדפדפן: עוברים על מסכים צרים ורחבים, ניווט עם מקלדת, מצבי פוקוס והודעות שגיאה אמיתיות. צילום של המסך הראשון לא מוכיח שהתהליך עובד.
• הנחיות שפה: מגדירים ל-AI את הקהל, הטון, המונחים, הדוגמאות והמגבלות לפני שמבקשים ממנו לכתוב.
• תוכן לבדיקה: מכינים שמות בעברית, שמות מוצרים באנגלית, כתובות מייל, מספרי טלפון, סכומים בשקלים וטקסט ארוך שיורד שורה.

RTL הוא יותר מטקסט שמיושר לימין

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

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

איך אני מבקש מה-AI לכתוב עברית

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

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

לפני שמרחיבים, בודקים מסלול שלם בעברית

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

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