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.
מה לעשות?
- הריצו pg_stat_statements (אם Supabase) - תזהו את ה-queries האיטיים
- זיהוי N+1 - לרוב יש select-then-loop בקוד; שנו ל-joins
- הוספת indexes - composite על שדות שמופיעים יחד ב-WHERE/ORDER BY
- נורמליזציה של JSON blobs - שבירה לטבלאות נפרדות עם foreign keys
- partition של טבלאות גדולות (>5M rows) לפי תאריך או tenant_id
שימו לב: כל migration של schema חייב להיות non-destructive בפרודקשן. הוסיפו את הטור החדש, backfill בהדרגה, אחר כך deprecate את הישן. אף פעם לא ALTER TABLE על טבלה פעילה ב-prime time.
מדריך עומק: Database Schema Redesign
שלב 2: Row Level Security (RLS) - לא אופציונלי
מה הבעיה?
ב-90% מפרויקטי Lovable שאנחנו רואים - RLS לא מוטמע באופן מקיף. זה אומר: כל משתמש מחובר יכול לקרוא נתונים של אחרים דרך ה-API. זו לא תיאוריה - אנחנו ראינו את זה גורם להדלפת payment data בפרויקט אמיתי ב-2025.
מה לעשות?
- enable RLS על כל טבלה ב-Supabase:
ALTER TABLE users ENABLE ROW LEVEL SECURITY; - policy לכל פעולה (SELECT, INSERT, UPDATE, DELETE) - ראו Supabase RLS Policies למדריך מעמיק
- בדיקת auth.uid() בכל policy
- service_role משמש רק בצד שרת (Edge Functions / API routes), אף פעם לא ב-frontend
- בדיקת foreign keys - מנעו דליפה דרך JOIN
דוגמה ל-policy בסיסי:
CREATE POLICY "users see only their own orders"
ON orders FOR SELECT
USING (auth.uid() = user_id);
הצ'קליסט המלא: 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 גרועים מאבדים ranking ב-Google תוך 4-6 שבועות.
מה לעשות?
- Sentry (או Datadog/PostHog) ל-error tracking + performance
- structured logging - JSON logs עם requestId, userId, latency
- alerts על: error rate > 1%, p95 latency > 2s, daily active users drop > 20%
- dashboards ב-Grafana/Datadog/PostHog
- health check endpoint (
/api/health) ש-uptime monitor (UptimeRobot) בודק כל דקה - Feature flags - kill switch לפיצ'ר שבור בלי redeploy
שלב 5: CI/CD + Preview Environments
מה הבעיה?
Lovable deployment הוא "save → live". ברגע שמשהו ישבר, כל המשתמשים ירגישו.
מה לעשות?
- branch protection על main - כל merge דורש PR
- preview environments ב-Vercel - כל PR מקבל URL ייחודי לבדיקה
- automated tests ב-CI - לפחות smoke tests
- staging environment מלא - עותק של פרודקשן עם נתונים סינתטיים
- rollback strategy - git revert + Vercel rollback button זמינים
שלב 6: Load Testing + Disaster Recovery
מה הבעיה?
"זה אמור לעבוד ב-10K משתמשים." האם בדקתם? לרוב - לא.
מה לעשות?
- load testing ב-k6 או Artillery - סימולציה של 100, 1K, 10K משתמשים סימולטניים
- database backups אוטומטיים יומיים (Supabase פותח בברירת מחדל; וודאו שזה פעיל)
- restore drill - תרגול שחזור פעם בחודש על staging
- runbook ל-incidents - מסמך מה לעשות כשהמערכת נופלת (חיוני בסטארטאפ עם founder יחיד)
- on-call schedule אם יש לכם צוות
Edge Functions Scaling - מדריך עומק
כמה זמן זה לוקח?
| גודל פרויקט | זמן Migration |
|---|---|
| MVP פשוט (1-5 טבלאות, 1-3 פיצ'רים) | 2-4 שבועות |
| MVP בינוני (5-15 טבלאות, 5-10 פיצ'רים) | 4-6 שבועות |
| MVP מורכב (15+ טבלאות, integrations, payments) | 6-12 שבועות |
| Enterprise-grade (compliance, audit logs, multi-tenant) | 12-20 שבועות |
הזמינו אבחון תוך 72 שעות ונקבל הצעת מחיר מותאמת לעומק הפרויקט שלכם.
איך מתחילים?
הצעד הראשון תמיד: VibeScale Audit Framework - 72 שעות, חינם. בלי זה, אי אפשר לדעת מה לתקן ובאיזה סדר.
