Lovable לפרודקשן: מפת דרכים הנדסית מקיפה 2026

TL;DR: העברת MVP מ-Lovable לפרודקשן היא תהליך הנדסי בן 6 שלבים: (1) Schema audit + normalization, (2) RLS מקיף, (3) Auth hardening, (4) Observability stack, (5) CI/CD + tests, (6) Load testing. תהליך טיפוסי: 4-8 שבועות. המפה הזו מבוססת על 50+ פרויקטי Lovable שעברנו ב-VibeScale.

למה Lovable לא בנוי לפרודקשן

<a href="/glossary/lovable-ai-stack">Lovable</a> הוא כלי מצוין ל-validation מהיר. אבל כש-MVP מתחיל לקבל משתמשים אמיתיים, ה-defaults של Lovable הופכים לחיזיון:

• Schema לא מנורמל (JSON blobs ענקיים במקום טבלאות)
• RLS מינימלי או חסר
• Secrets ב-frontend (VITE_ prefix)
• Sessions ב-localStorage (XSS חשוף)
• אין dev/staging environment
• אין tests
• אין CI/CD
• אין error monitoring

לתקן את כל אלה בלי מתודולוגיה = כאוס. הנה התוכנית.

שלב 1: Schema Audit + Normalization (שבוע 1-2)

הבעיה

Lovable יוצר schemas שמתאימים ל-100 rows. ברגע שהגעתם ל-100K, queries הופכים לאיטיים מאוד.

מה לעשות

1. הריצו pg_stat_statements ב-Supabase לזיהוי slow queries
2. זיהוי N+1 patterns בקוד (select-then-loop)
3. הוסיפו indexes composite על שדות שמופיעים יחד ב-WHERE/ORDER BY
4. נורמלו JSON blobs לטבלאות נפרדות עם foreign keys
5. הוסיפו constraints (NOT NULL, CHECK) שLovable השמיט

Pro tip

אל תעשו ALTER TABLE על טבלה פעילה ב-prime time. תמיד migration שמוסיף עמודות (לא מוחק) → backfill → deprecate.

שלב 2: RLS מקיף (שבוע 2-3)

למה זה קריטי

ב-90% מפרויקטי Lovable, RLS חסר. תוצאה: כל משתמש מחובר יכול לקרוא נתונים של כולם דרך ה-API.

מה לעשות

-- 1. הפעלת RLS על כל טבלה (גם אם עוד אין policies)
ALTER TABLE users ENABLE ROW LEVEL SECURITY;
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

-- 2. Policies בסיסיות
CREATE POLICY "users_select_own" ON orders
  FOR SELECT USING (auth.uid() = user_id);
CREATE POLICY "users_insert_own" ON orders
  FOR INSERT WITH CHECK (auth.uid() = user_id);
CREATE POLICY "users_update_own" ON orders
  FOR UPDATE USING (auth.uid() = user_id) WITH CHECK (auth.uid() = user_id);

Multi-tenant?

לפרויקטים עם organizations, צריך layer נוסף:

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

ראו את <a href="/glossary/supabase-rls-policies">המדריך המלא ל-Supabase RLS</a>.

שלב 3: Auth Hardening (שבוע 3)

Lovable defaults פגיעים

• Sessions ב-localStorage → פגיע ל-XSS
• אין rate limiting על login
• אין MFA
• Password requirements חלשים

מה לעשות

1. Migration ל-httpOnly cookies - לא ניתן לקריאה מ-JavaScript
2. MFA למשתמשי B2B - הפעלה ב-Supabase Auth dashboard
3. Rate limiting על login/signup/reset (10/min/IP)
4. Password validation מחמיר (12+ chars, mixed case)
5. OAuth flows רק עם PKCE (אסור implicit flow)
6. Audit logs של auth events

שלב 4: Observability Stack (שבוע 3-4)

המינימום ההכרחי

• Sentry - error tracking + performance ($0 free tier, ~$30/mo Pro)
• PostHog - product analytics + session replay (free tier נדיב)
• Better Stack - uptime monitoring + logs (low-cost)
• OpenTelemetry - distributed tracing (free, אם יש מספר services)

Alerts שחובה להגדיר

• Error rate > 1% on critical endpoints
• p95 latency > 2s for 15 min
• DB connection pool > 80%
• Daily Active Users drop > 30%

ראו <a href="/glossary/observability-stack-2026">מערך Observability 2026</a>.

שלב 5: CI/CD + Tests (שבוע 4-5)

Lovable Defaults

• "Save → Live" ישירות (אין staging)
• אין tests
• אין PR review

מה לעשות

1. Branch protection על main (חייב PR + 1 reviewer)
2. Preview environments ב-Vercel/Netlify לכל PR
3. Smoke tests מינימליים: critical user paths
4. TypeScript strict + ESLint ב-CI
5. Database migrations ב-CI (dbmate או drizzle-kit)
6. Rollback procedure ברור ובדוק

Test pyramid מומלץ

• 70% unit tests (Vitest)
• 20% integration tests
• 10% E2E (Playwright)

שלב 6: Load Testing + DR (שבוע 5-6)

למה זה חשוב

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

מה לעשות

1. k6 או Artillery - סימולציה של 100, 1K, 10K משתמשים סימולטניים
2. Database backups אוטומטיים יומיים (Supabase פותח by default - וודאו שזה פעיל)
3. Restore drill פעם בחודש על staging
4. Runbook ל-incidents מתועד
5. Connection pooling עם PgBouncer/Supavisor (תוצא ה-cookie cutter ב-100 משתמשים סימולטניים)

Timeline טיפוסי לפי גודל פרויקט

מה אתם לא צריכים לעשות

• ❌ Rewrite מלא מאפס - מבזבז 4-6 חודשים, ה-AI ימשיך לעשות אותן טעויות
• ❌ Migration ל-Custom Backend (Express/Fastify) - Supabase מספיק לרוב המקרים
• ❌ Microservices מ-day 1 - תחילה monolith יציב, אחר כך מפצלים
• ❌ "Big bang" deploy אחרי 3 חודשי שינויים - תמיד מדורג

כלים שיעזרו

• <a href="/tools/migration-estimator">Migration Estimator</a> - אומדן שבועות + מורכבות לפרויקט שלכם
• <a href="/tools/production-readiness-audit">Production Readiness Audit</a> - 30 בדיקות לפני launch
• <a href="/tools/ai-readiness">AI Readiness Checklist</a> - האם הפרויקט בכלל מוכן ל-Migration
• <a href="/audit-framework">VibeScale Audit Framework</a> - 72 שעות, חינם, דוח PDF מלא

רוצים שנעשה את ה-Migration במקומכם?

<a href="/rescue">Vibe Coding Rescue</a> של VibeScale כולל את כל 6 השלבים. תהליך טיפוסי: 4-8 שבועות. הצוות שלכם ממשיך לפתח פיצ'רים במקביל.

WhatsApp | קבל Audit חינם | קרא Case Studies