Lovable לפרודקשן - המדריך ההנדסי המלא לשדרוג MVP שנבנה ב-AI

TL;DR - תמצית המאמר

פרויקטי Lovable מצוינים ל-validation מהיר, אבל לא נועדו לפרודקשן. ההעברה כוללת 6 שלבים: (1) schema audit ונורמליזציה, (2) RLS מקיף, (3) auth hardening (sessions, secrets), (4) observability (Sentry + structured logging), (5) CI/CD עם preview environments, (6) load testing ו-backup strategy. תהליך טיפוסי: 4-8 שבועות. המאמר הוא צ'קליסט מעשי לכל שלב.

למה Lovable שובר בסקייל?

Lovable הוא כלי מדהים. בתוך 30 דקות בנייתם MVP שעובד, נראה טוב, ומקבל משתמשים ראשונים. השאלה היא לא האם הוא ישבר - אלא מתי.

הסיבה: Lovable אופטם ל-speed of validation, לא ל-resilience at scale. ה-defaults של הכלי טובים ל-POC ורעים לפרודקשן:

• Schema לא נורמלי (Lovable נוטה ליצור JSON blobs במקום טבלאות נפרדות)
• RLS מינימלי או חסר
• Secrets ב-frontend
• אין sessions מאובטחים (Auth ב-localStorage לעיתים)
• אין dev/staging environments
• אין tests, אין CI/CD, אין observability

הדבר הטוב: כל אחת מהבעיות האלה היא תיקנת. אתם לא צריכים rewrite - אתם צריכים migration נכון.

מה זה בעצם Lovable to Production?

שלב 1: Database Schema Audit + Normalization

מה הבעיה?

Lovable יוצר schemas שמתאימים ל-100 rows. ברגע שהגעתם ל-100K, queries הופכים לאיטיים, full table scans יומיים, ועדכון אחד נועל את ה-DB.

מה לעשות?

1. הריצו pg_stat_statements (אם Supabase) - תזהו את ה-queries האיטיים
2. זיהוי N+1 - לרוב יש select-then-loop בקוד; שנו ל-joins. איך מזהים N+1 בוודאות ומה מחליף אותו
3. הוספת indexes - composite על שדות שמופיעים יחד ב-WHERE/ORDER BY
4. נורמליזציה של JSON blobs - שבירה לטבלאות נפרדות עם foreign keys
5. partition של טבלאות גדולות (>5M rows) לפי תאריך או tenant_id

שימו לב: כל migration של schema חייב להיות non-destructive בפרודקשן. הוסיפו את הטור החדש, backfill בהדרגה, אחר כך deprecate את הישן. אף פעם לא ALTER TABLE על טבלה פעילה ב-prime time.

מדריך עומק: Database Schema Redesign

שלב 2: Row Level Security (RLS) - לא אופציונלי

מה הבעיה?

ברוב פרויקטי Lovable שאנחנו רואים - RLS לא מוטמע באופן מקיף. זה אומר: כל משתמש מחובר יכול לקרוא נתונים של אחרים דרך ה-API. זו לא תיאוריה - אנחנו ראינו את זה גורם להדלפת payment data בפרויקט אמיתי ב-2025, וסריקה חיצונית של 170 פרויקטי Lovable מצאה 303 נקודות קצה חשופות מאותה סיבה.

מה לעשות?

1. enable RLS על כל טבלה ב-Supabase: ALTER TABLE users ENABLE ROW LEVEL SECURITY;
2. policy לכל פעולה (SELECT, INSERT, UPDATE, DELETE) - ראו Supabase RLS Policies למדריך מעמיק
3. בדיקת auth.uid() בכל policy
4. service_role משמש רק בצד שרת (Edge Functions / API routes), אף פעם לא ב-frontend
5. בדיקת foreign keys - מנעו דליפה דרך JOIN

דוגמה ל-policy בסיסי:

CREATE POLICY "users see only their own orders"
ON orders FOR SELECT
USING (auth.uid() = user_id);

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

CREATE POLICY "org members see their org projects"
ON projects FOR SELECT
USING (
  org_id IN (SELECT org_id FROM org_members WHERE user_id = auth.uid())
);

הצ'קליסט המלא: Base44 RLS Audit (תקף גם ל-Supabase)

שלב 3: Auth Hardening

מה הבעיה?

ה-defaults של Lovable Auth בסיסיים מדי. סיסמאות עוברות כראוי, אבל הטיפול ב-sessions פגיע.

מה לעשות?

• sessions ב-httpOnly cookies, לא ב-localStorage (פגיע ל-XSS)
• MFA למשתמשי B2B
• password hashing (bcrypt 12+ rounds) - נורמלי בברירת המחדל של Supabase
• OAuth flows רק עם PKCE (לא implicit flow)
• rate limiting על endpoints של login/signup/reset (10/min/IP)
• API keys rotation schedule

טיפ: Lovable שומר לעיתים secrets ב-.env שעובר ל-client. עברו על כל ה-env vars וודאו ש-secrets (לא public) לא מתחילים ב-VITE_ או NEXT_PUBLIC_.

שלב 4: Observability

מה הבעיה?

ב-MVP אתם רואים בעיות כי משתמש 1-3 מתלוננים ב-WhatsApp. ב-1K משתמשים, אתם לא רואים את הבעיות עד שמשתמש 500 מתלונן. וגם אז - לרוב מאוחר מדי. אותו עיוורון עולה גם בחיפוש: Core Web Vitals הם אות דירוג מוכרז של גוגל, ובלי מדידה בשדה אין לכם דרך לדעת שהם הידרדרו.

מה לעשות?

1. Sentry (או Datadog/PostHog) ל-error tracking + performance. המערך המלא, עם מה שכל כלי עולה בפועל, נמצא במערך Observability לסטארטאפ
2. structured logging - JSON logs עם requestId, userId, latency
3. alerts על: error rate > 1%, p95 latency > 2s, daily active users drop > 20%
4. dashboards ב-Grafana/Datadog/PostHog
5. health check endpoint (/api/health) ש-uptime monitor (UptimeRobot) בודק כל דקה
6. Feature flags - kill switch לפיצ'ר שבור בלי redeploy

שלב 5: CI/CD + Preview Environments

מה הבעיה?

Lovable deployment הוא "save → live". ברגע שמשהו ישבר, כל המשתמשים ירגישו.

מה לעשות?

1. branch protection על main - כל merge דורש PR
2. preview environments ב-Vercel - כל PR מקבל URL ייחודי לבדיקה
3. automated tests ב-CI - לפחות smoke tests
4. staging environment מלא - עותק של פרודקשן עם נתונים סינתטיים
5. rollback strategy - git revert + Vercel rollback button זמינים. וכשה-deploy עצמו נכשל: הסיבות הנפוצות ל-deploy שנופל ב-Vercel

שלב 6: Load Testing + Disaster Recovery

מה הבעיה?

"זה אמור לעבוד ב-10K משתמשים." האם בדקתם? לרוב - לא.

מה לעשות?

1. load testing ב-k6 או Artillery - סימולציה של 100, 1K, 10K משתמשים סימולטניים
2. database backups אוטומטיים יומיים (Supabase פותח בברירת מחדל; וודאו שזה פעיל)
3. restore drill - תרגול שחזור פעם בחודש על staging
4. runbook ל-incidents - מסמך מה לעשות כשהמערכת נופלת (חיוני בסטארטאפ עם founder יחיד)
5. on-call schedule אם יש לכם צוות

Edge Functions Scaling - מדריך עומק

כמה זמן זה לוקח?

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

מה לא צריך לעשות

ארבע החלטות שנראות אחראיות ומייקרות את התהליך בלי להוסיף יציבות:

• Rewrite מלא מאפס. מבזבז חודשים, ובסופו יש קוד חדש עם אותן בעיות ארכיטקטורה - כי הן נבעו מהפרומפט, לא מהכלי.
• מעבר ל-backend מותאם (Express, Fastify) רק כדי "לצאת מ-Supabase". לרוב המקרים Supabase מספיק, וההחלפה מוסיפה שכבה שצריך לתחזק.
• Microservices מהיום הראשון. קודם monolith יציב עם גבולות ברורים; פיצול בא כשיש בעיה מדידה שהוא פותר.
• Deploy אחד גדול אחרי חודשי שינויים. כל שלב כאן נועד לצאת לאוויר בנפרד, כדי שתדעו מה שבר מה.

איך מתחילים?

הצעד הראשון תמיד: שיחת אבחון חינם של 20 דקות, ואחריה VibeScale Audit Framework. בלי זה, אי אפשר לדעת מה לתקן ובאיזה סדר.

• קראו על מסגרת ה-Audit
• Migration Estimator - אומדן שבועות ומורכבות לפרויקט שלכם
• Production Readiness Audit - הבדיקות שלפני ה-launch
• מחשבון חוב טכנולוגי - כמה זה עולה לי כל חודש?
• AI Readiness Checklist - האם הפרויקט מוכן לפרודקשן?
• שלחו לנו את הפרויקט ב-WhatsApp

המדריך המלא ל-Vibe Coding Rescue | Vibe Coding Manifesto