Lovable ile yapılan bir projeyi production-ready hale getirmek

Lovable'ın en güçlü taraflarından biri fikir ile görülebilir ürün arasındaki mesafeyi küçültmesi. Bir landing page, dashboard veya SaaS kabuğu çok kısa sürede tartışılabilir hale geliyor. Bu büyük bir avantaj. Fakat çalışan preview ile production-ready ürün aynı şey değil.

Preview, ürünün ne olabileceğini kanıtlar. Production ise ürünün kötü bir günde dağılmayacağını kanıtlamaya çalışır.

1. Önce kaynak doğrusunu belirliyorum

Lovable, GitHub ve bazen başka coding agent'ları aynı projeye dokunuyorsa ilk risk kod değil, gerçeklik çatışması. Hangi sürüm canonical? Ben production projelerinde GitHub'ı kaynak doğrusu olarak tutmayı tercih ediyorum.

1const projectTruth = {2  source: 'GitHub',3  productionBranch: 'main',4  preview: 'implementation surface',5  deploy: 'explicit pipeline',6};

2. Environment ve secret sınırını temizliyorum

Preview ortamında çalışan bir anahtarın client bundle'a girmemesi gerektiğini production'da fark etmek istemezsiniz. Public environment variable ile server secret aynı şey değildir. Özellikle service-role anahtarları, ödeme webhook secret'ları ve özel API token'ları client tarafına hiçbir koşulda sızmamalı.

• Client'ta gerçekten public olması gereken değişkenleri ayır.
• Server-only secret'ları deployment secret store'da tut.
• .env dosyalarının repository'ye girmediğini doğrula.
• Preview ve production environment'larını birbirinden ayır.

3. Auth çalışıyor mu değil, auth sınırı doğru mu diye bakıyorum

Login ekranının açılması auth'un güvenli olduğu anlamına gelmez. Session persistence, token refresh, logout semantiği, protected route davranışı, offline/expired session ve redirect'ler ayrı ayrı test edilmelidir.

4. Supabase kullanıyorsam RLS'yi UI'a bırakmıyorum

Bir butonu gizlemek yetkilendirme değildir. Kullanıcı DevTools'tan API çağrısı yapabildiğinde veriyi yine okuyabiliyorsa UI yalnızca dekoratif bir kilittir. RLS ve server-side authorization production sınırının parçasıdır.

1-- İlke: kullanıcı yalnızca kendi satırlarını okuyabilsin2create policy "own_rows"3on public.items for select4using (user_id = auth.uid());

5. Veri modelini ekranlardan bağımsız inceliyorum

Hızlı prototiplemede tablo yapısı çoğu zaman ilk ekranların ihtiyacına göre büyür. Production öncesi ise uniqueness, foreign key, nullable alanlar, cascade davranışı, timestamp semantiği ve idempotency gibi konuları tekrar gözden geçirmek gerekir.

1const dataReview = [2  'ownership',3  'constraints',4  'idempotency',5  'deletion semantics',6  'migration safety',7];

6. Loading, empty ve error state'leri gerçek ürün davranışıdır

Happy path üzerinde çalışan bir prototip etkileyici görünebilir. Gerçek kullanıcı ise yavaş ağ, boş hesap, timeout, expired token, 500 cevabı ve kısmi data ile karşılaşır. Production readiness bu durumların tasarlanmış olmasıdır.

• İlk yükleme ile background refresh aynı loading state'i kullanmamalı.
• Boş veri hata gibi görünmemeli.
• Retry sonsuz döngüye girmemeli.
• Kullanıcı aksiyonları başarısız olduğunda geri bildirim vermeli.

7. Network davranışını ölçüyorum

Bir ekranın hızlı görünmesi yetmez. Aynı veriyi kaç component çekiyor? Route değişiminde ne invalidated oluyor? Arka plandaki sekme polling yapıyor mu? Cache policy var mı? Bunlar hem performansı hem faturayı belirliyor.

1type NetworkPolicy = {2  staleAfter: number;3  refreshOnFocus: boolean;4  realtime: boolean;5  invalidateOn: string[];6};

8. Route, metadata ve paylaşım yüzeyini tamamlıyorum

Ürün yalnızca authenticated app değildir. 404, canonical URL, sitemap, robots, Open Graph, favicon, manifest ve deep link davranışı da production yüzeyidir. Özellikle pazarlanacak ürünlerde bu katmanı sona bırakmak görünürlük kaybettirir.

9. Mobilde browser küçültmesi yapmıyorum

Responsive görünmek ile mobilde kullanılabilir olmak farklı. Klavye açıldığında modal, safe area, touch target, scroll lock, sticky header ve viewport yüksekliği gerçek cihazda test edilmelidir. Desktop'ta güzel görünen çözümü yalnızca tek sütuna indirmek yeterli değildir.

10. Release'i geri alınabilir hale getiriyorum

Production deploy son adım değil, kontrollü bir değişikliktir. Hangi commit yayınlandı? Rollback nasıl yapılacak? Migration geriye dönülebilir mi? Cache veya service worker eski asset tutuyor mu? Bunların cevabı release sırasında değil, öncesinde hazır olmalı.

1const release = {2  sourceCommit: 'known',3  build: 'verified',4  migration: 'reviewed',5  rollback: 'possible',6  productionSmokeTest: 'required',7};

Lovable'ı bırakmak gerekmiyor

Benim vardığım sonuç Lovable'ın yalnızca prototip için kullanılması gerektiği değil. Tersine, doğru kontrol katmanlarıyla production sürecinin güçlü bir parçası olabilir. Kritik nokta hızlı üretim aracını kaynak doğrusu, güvenlik ve acceptance sürecinin yerine koymamak.

Production-ready olmak, daha ciddi görünen UI yapmak değil; kötü koşullarda da davranışı açıklanabilir bir sistem kurmaktır.