סיכום

SLAtech LTD היא חברת פיתוח תוכנה ישראלית הפועלת מאז 2004. אנחנו עוזרים לבעלים של אפליקציות שנבנו ב-Lovable: בודקים את חוקי הגישה למסד הנתונים ב-Supabase, את שמירת המפתחות ואת מבנה הקוד, מביאים את הפרויקט ל-production וממשיכים לפתח אותו. הקוד נשאר במאגר שלכם ב-GitHub. אנשים קובעים את הארכיטקטורה ומקבלים את ההחלטות, וה-AI רק מציע.

פרויקטים ב-Lovable

פרויקט ב-Lovable נתקע? נבדוק, נתקן ונביא אותו ל-production

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

ספרו לנו על הפרויקט ישר לאבחון

מה Lovable עושה טוב

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

נותן סטאק מודרני וקריא: React, TypeScript, Tailwind. כל מפתח מנוסה יכול לקרוא את הקוד הזה ולהמשיך לפתח אותו.

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

דואג לאבטחה בסיסית. הגנה ברמת השורה במסד הנתונים (RLS) מופעלת כברירת מחדל, ולפני פרסום Lovable מריץ בדיקות משלו.

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

איפה פרויקטים ב-Lovable בדרך כלל נתקעים

חוקי הגישה לנתונים

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

מפתחות בקוד של הדפדפן

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

לוגיקה בדפדפן

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

תיקונים במעגלים

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

בלתי נראה לחיפוש

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

מעבר לתשתית שלכם

אם מסד הנתונים נמצא ב-Lovable Cloud, המעבר ל-Supabase משלכם, העברת המשתמשים והגדרת ההעלאה לאוויר הופכים למשימה נפרדת.

מה אנחנו בודקים בפרויקט ב-Lovable

1

חוקי הגישה לכל טבלה: מי יכול לקרוא, ליצור, לשנות ולמחוק רשומות, והאם זה מתאים למה שתוכנן.

2

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

3

פונקציות השרת של Supabase: האם הן בודקות מי פונה אליהן ומה בדיוק נשלח.

4

תשלומים ומגבלות: איפה מתקבלת ההחלטה, בדפדפן או בשרת, והאם האישורים מגיעים ישירות מספק התשלומים.

5

אחסון קבצים: אילו תיקיות פתוחות לכולם ומה יש בהן.

6

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

7

ספריות חיצוניות: גרסאות ישנות ופגיעות.

8

שאילתות למסד הנתונים: מה יאט ראשון כשיהיו יותר משתמשים.

9

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

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

שלוש דרכים להמשיך

אבחון

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

עוד על האבחון

המשך פיתוח

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

לדבר על המשך פיתוח

כתיבה מחדש של חלק

לרוב צריך לכתוב מחדש לא את הממשק, אלא את מה שמתחתיו: חוקי גישה, תשלומים, לוגיקת שרת. את הממשק ב-React בדרך כלל אפשר לשמור.

לדבר על כתיבה מחדש

איך אנחנו בוחרים בין הדרכים האלה, מוסבר בפירוט בעמוד על עזרה לפרויקטים ב-vibe coding.

איך אנחנו עצמנו עובדים עם AI

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

שאלות נפוצות

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

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

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

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

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

כלי AI נוספים

עם פרויקטים בכלים אחרים אנחנו עובדים באותה דרך. העמוד הכללי: עזרה לפרויקטים ב-vibe coding.

ספרו לנו מה בניתם ב-Lovable

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

ספרו לנו על הפרויקט ישר לאבחון