Lovable הוא אחד הכלים שגרמו לזה שבעלי עסקים בישראל מגיעים לפגישה עם אפליקציה עובדת ביד במקום עם מצגת. זה שינוי אמיתי, וכדאי להתייחס אליו ברצינות.
הפוסט הזה עונה על שלוש שאלות שחוזרות שוב ושוב: מה הכלי באמת עושה, איך הוא מתמודד עם עברית ו-RTL, ואיפה בדיוק נמצאת התקרה שלו. אם אתם כבר בפנים ומחפשים הדרכה מעשית על פרומפטים והגדרות, המדריך למייסד הישראלי מכסה בדיוק את זה.
מה Lovable עושה בפועל
אתם מתארים אפליקציה בשפה חופשית. הפלטפורמה מייצרת אפליקציית ווב מלאה - מסכים, לוגיקה, מסד נתונים, התחברות משתמשים - ומפרסמת אותה לכתובת חיה. הכל בדפדפן, בלי התקנות.
מה שחשוב להבין: זו לא "בנייה בגרירה" של רכיבים, אלא ייצור קוד אמיתי. סטאק ה-AI של Lovable הוא סטאק ווב מודרני ומקובל, ולא פורמט פנימי סגור. לכך יש השלכה מעשית משמעותית: מה שנוצר הוא קוד שמפתח יכול לפתוח, לקרוא ולהמשיך ממנו. בפלטפורמות שבהן התוצר הוא פורמט קנייני, המצב שונה לגמרי.
זו הסיבה שאנחנו נוטים להתייחס ל-Lovable כנקודת פתיחה סבירה גם כשהיעד ארוך טווח - בניגוד לכלים שהיציאה מהם היא כתיבה מחדש.
עברית ו-RTL: מה עובד ומה דורש תשומת לב
זו השאלה הישראלית הראשונה, והתשובה היא: זה עובד, אבל לא לבד.
מה עובד טוב:
- טקסט בעברית מיוצר בלי בעיה, כולל שמות שדות, כפתורים והודעות שגיאה
- כשמבקשים במפורש ממשק בעברית עם כיווניות ימין-לשמאל, זה מגיע נכון במסכים הראשונים
- הגופנים המודרניים תומכים בעברית היטב, והתוצאה נראית סבירה מהרגע הראשון
מה נוטה להישבר:
- עקביות לאורך זמן. מסך שמתווסף בשבוע השלישי עלול לחזור לכיווניות שמאל-לימין, כי כל בקשה חדשה מתחילה מדף חלק. הפתרון: לבקש שהכיווניות תיקבע ברמת האפליקציה כולה, ולא מסך אחר מסך.
- רכיבים מספריות חיצוניות. בוחרי תאריכים, תפריטים נפתחים, תיבות חיפוש, טבלאות עם מיון - כל אלה מגיעים מספריות שנבנו לשמאל-לימין. חיצי הפתיחה מצביעים לכיוון הלא נכון, מרווחים נצמדים לצד ההפוך, ותפריטים נפתחים החוצה מהמסך.
- טקסט מעורב. שם באנגלית בתוך משפט בעברית, מספר טלפון, כתובת דוא"ל, מספר חשבונית. הסדר הוויזואלי מתבלבל, וזה נראה בסדר בעין עד שמישהו מעתיק את המספר ומגלה שהוא הפוך.
- סמלים כיווניים. חץ "חזור" שמצביע ימינה במקום שמאלה, פס התקדמות שמתמלא מהכיוון הלא נכון. פרטים קטנים שגורמים לממשק להרגיש מתורגם.
- תאריכים ומספרים. פורמט תאריך אמריקאי במקום ישראלי הוא באג שקט ומסוכן - הוא לא זורק שגיאה, הוא רק גורם למישהו לקרוא את ה-3 באפריל בתור ה-4 במרץ.
מה שכדאי לעשות מהיום הראשון: לבקש במפורש שהכיווניות והשפה ייקבעו ברמת האפליקציה, ולציין שכל רכיב מספרייה חיצונית צריך לכבד את הכיוון. זה חוסך עשרות תיקונים נקודתיים בהמשך. ואחרי כל תכונה חדשה - להסתכל על המסך בעין, לא רק לקרוא את סיכום השינויים.
מה כדאי לבקש כבר בפרומפט הראשון
בפרויקט ישראלי, כמה משפטים בהתחלה חוסכים עשרות תיקונים בהמשך:
- שכיווניות ימין-לשמאל ושפת הממשק ייקבעו ברמת האפליקציה כולה, לא לכל מסך בנפרד
- שכל רכיב שמגיע מספרייה חיצונית יכבד את הכיווניות הזו
- שתאריכים יוצגו בפורמט ישראלי ושהשעה תהיה בפורמט 24 שעות
- שמספרי טלפון, כתובות דוא"ל ומספרי מזהים יוצגו תמיד משמאל לימין גם בתוך משפט בעברית
- שהודעות שגיאה ואישור יהיו גם הן בעברית - זה המקום שהכי נוטה להישאר באנגלית
זה גם בדיוק סוג המידע ששווה לרשום לעצמכם בצד ולחזור עליו כשמוסיפים מסך חדש, כי כל בקשה חדשה מתחילה מדף חלק ולא זוכרת מה סיכמתם בשבוע שעבר.
מודל התמחור: איך זה מתנהג בפועל
המחירים משתנים, והמבנה המדויק של התוכניות משתנה גם הוא - כדאי תמיד לבדוק את המחירון העדכני באתר במקום להסתמך על מספר שכתוב בפוסט כלשהו. מה שכן שווה להבין הוא הלוגיקה, כי היא זו שמפתיעה אנשים.
התמחור בנוי סביב מכסת פעולות או קרדיטים חודשיים, לא סביב מספר הפרויקטים. כלומר:
- כל הודעה שאתם שולחים צורכת מהמכסה
- הודעה שמתקנת משהו שהמודל שבר צורכת בדיוק כמו הודעה שבונה משהו חדש
- בקשה גדולה ומעורפלת שמייצרת תוצאה לא נכונה עולה פעמיים - פעם על הבקשה ופעם על התיקון
התוצאה המעשית: השימוש בקרדיטים לא מתפלג באופן אחיד. הוא נמוך בהתחלה, כשכל הודעה מוסיפה מסך שלם, ומזנק בדיוק ברגע שהפרויקט מסתבך - כשנכנסים למעגל של תיקון-שובר-משהו-אחר. זה הרגע שבו הצריכה הגבוהה ביותר פוגשת את הערך הנמוך ביותר.
מה שכדאי לעשות:
- לפרק בקשות גדולות לצעדים קטנים שאפשר לבדוק. שלוש בקשות ממוקדות עדיפות על אחת מעורפלת שתייצר חמישה תיקונים.
- כשתיקון לא עבד פעמיים - לעצור ולנסח את הבעיה מחדש, לא לנסות שלישית באותה צורה.
- להשתמש במנגנון החזרה לגרסה קודמת במקום "לתקן קדימה" ממצב שבור.
ולא לשכוח את מה שמחוץ למנוי: מסד הנתונים, האחסון, הדומיין וכל שירות חיצוני שהאפליקציה מדברת איתו הם עלויות נפרדות. בשלב הראשוני הן זניחות. הן מפסיקות להיות זניחות בדיוק כשהמוצר מתחיל להצליח.
איפה Lovable באמת חזק
- מהירות מרעיון למסך. לראות את הרעיון עובד באותו ערב זה יתרון אמיתי, במיוחד מול משקיע, שותף או לקוח פוטנציאלי.
- הבנה מהירה שהרעיון לא נכון. זה ערך שקשה לתמחר. לגלות בשלושה ימים שהתהליך שחשבתם עליו לא הגיוני זה חיסכון עצום.
- המראה. המסכים שנוצרים נראים מודרניים כברירת מחדל. לא מעוצבים בהתאמה אישית - אבל בהחלט מכובדים.
- הצוואר הצר של האנשים הלא-טכניים נעלם. מייסד לא-טכני מגיע לשלב שלפניו נדרש שותף טכני. זה שינוי אמיתי בשוק.
- הקוד לא כלוא. אפשר לסנכרן עם GitHub ולהמשיך משם. זה בדיוק ההבדל שהופך את השלב הבא לאפשרי במקום לכתיבה מחדש.
התקרה - ואיך יודעים שהגעתם אליה
התקרה של Lovable אינה מספר משתמשים. היא סוג בעיה.
כל עוד אתם מוסיפים - מסך חדש, שדה חדש, תכונה חדשה - הכלי מתקדם יפה. הרגע שהכל משתנה הוא הרגע שבו הבעיה עוברת מ"להוסיף" ל"להבין למה זה מתנהג ככה".
הסימנים, בסדר החומרה:
- אותו באג חוזר בגרסאות מעט שונות אחרי כמה סבבי תיקון
- שינוי במקום אחד שובר משהו שנראה לא קשור
- אתם כבר לא יודעים להסביר מה קורה כשמשתמש לוחץ על כפתור
- יש בפרויקט מידע אישי או כספי, ואף אחד לא בדק מי יכול לגשת אליו
הסימן הרביעי הוא הרציני מכולם, והוא גם השקט מכולם - כי מבחוץ הכל נראה תקין. הרשאות גישה למסד נתונים הן בדיוק הדבר שנראה בסדר עד היום שבו הוא ממש לא. הרחבנו על המנגנון הזה בלמה הפרויקט שלך ב-Lovable או Base44 נשבר כשמגיעים משתמשים אמיתיים.
הסיבה השורשית זהה בכל המקרים: כל שיחה עם המודל מתחילה מדף חלק, וכל שינוי בפני עצמו סביר לחלוטין. אחרי חודשיים יש בפרויקט כמה דרכים שונות לעשות אותו דבר, ואף אחת מהן אינה שגויה בפני עצמה. זה בדיוק המצב שבו מודל מתקשה, ובו גם מפתח אנושי יתקשה.
מה לעשות כשמגיעים לתקרה
מה שלא עושים: למחוק ולהתחיל מחדש. זו הטעות היקרה ביותר, והיא נובעת מתחושה ולא מניתוח. הקוד שנוצר הוא קוד ווב סטנדרטי, ורוב העבודה שהושקעה עדיין שווה משהו.
מה שכן עושים, לפי סדר:
- להוציא את הקוד ל-GitHub. לפני כל דבר אחר. מהרגע הזה יש היסטוריה, יש גיבוי, ויש נקודה לחזור אליה. כדאי לקרוא את התיעוד העדכני של הפלטפורמה לפני החיבור - לחיבור כזה יש בדרך כלל השלכות על מנגנון הגרסאות הפנימי שעדיף להכיר מראש.
- לבדוק הרשאות. מי יכול לקרוא ולכתוב מה במסד הנתונים. זו הבדיקה הכי חשובה ולרוב הכי מוזנחת.
- לחפש מפתחות סודיים בצד הלקוח. מפתח שירות חיצוני שנשלח לדפדפן הוא מפתח פומבי לכל דבר.
- להחליט מה נשאר ומה נבנה מחדש. בדרך כלל הממשק נשאר כמעט כולו, והשכבה שמתחת - הנתונים וההרשאות - מסודרת מחדש. זה בדיוק התהליך שמתואר במ-Lovable לפרודקשן: המדריך ההנדסי המלא, ובגרסה המסודרת שלו במפת הדרכים לפרודקשן.
אם השלב הזה מגיע ואתם מעדיפים שמישהו ייקח אותו, שירות המעבר מ-Lovable לפרודקשן עוסק בדיוק בו.
אז למי זה מתאים
מתאים מאוד למי שרוצה לבדוק רעיון מהר, למייסד לא-טכני שצריך משהו מוחשי, לכלי פנימי שמשרת קבוצה קטנה, ולמי שמעדיף להתחיל ולראות במקום לתכנן חצי שנה.
פחות מתאים כמערכת שמנהלת כסף או מידע רגיש בלי מישהו שבדק אותה, כמוצר שאתם מתכננים לתחזק שנים בלי לגעת בקוד, וכפתרון למי שאין לו סבלנות ללמוד את התנהגות הכלי.
הדבר הכי חשוב: לדעת מראש שהתקרה קיימת. לא כי הכלי גרוע - אלא כי כל כלי בנוי לשלב מסוים. הבעיה אינה להשתמש ב-Lovable. הבעיה היא לגלות שיש תקרה רק אחרי שכבר יש משתמשים משלמים בצד השני.
