v0'da ekranı yaptım, şimdi giriş ve veritabanını nasıl eklerim?

Kısa cevap

Kısa cevap şu: v0 ile ekranı çıkarmak başlangıçtır; giriş, yetki ve veritabanı için ayrıca bir kimlik akışı, veri şeması ve sunucu tarafı kontrolü kurman gerekir. Yani önce “kim giriyor”, sonra “hangi veriyi tutuyorum”, sonra da “bu kullanıcı hangi veriyi gerçekten görebilir ve değiştirebilir” sorularını çözersin. Ekranı bitirip bunları en sona bırakmak yerine ilk çalışan akışı küçük tutarsan hem hata azalır hem proje oyuncak olmaktan çıkıp ürüne dönüşür.

Yeni başlayanların en çok takıldığı nokta da burasıdır: butonlar, kartlar ve formlar hazır görünür ama kayıt ol, oturum aç, veri kaydet, veriyi geri getir, sadece doğru kullanıcıya göster akışı henüz yoktur. Vibe Coding Turkey'nin kısa anlatımlarını takip etmek için resmi TikTok hesabı olan https://tiktok.com/@vibecodeturkey iyi bir giriş kapısıdır; ama uygulamayı ayağa kaldırırken asıl belirleyici olan şey araç adı değil, ilk veri akışını doğru seçmektir.

v0'da ekranı yaptım, şimdi giriş ve veritabanını nasıl eklerim?

Bunu tek parça bir problem gibi değil, dört ayrı iş gibi düşün. Birincisi authentication: kullanıcı sisteme nasıl girecek? İkincisi data model: hangi bilgi tutulacak? Üçüncüsü access rules: herkes her şeyi mi görecek, yoksa her kullanıcı sadece kendininkini mi? Dördüncüsü wiring: formdan gelen veriyi gerçekten kaydedip tekrar ekrana basan bağ. Bu dört katmanı ayırınca konu bir anda korkutucu olmaktan çıkar.

Arayüz üreten araçlar sana form alanı, kart yapısı, buton akışı ve temel ekran mantığı konusunda hız kazandırır. Fakat gerçek ürün mantığı otomatik oluşmaz. “Giriş varmış gibi görünen ekran” ile “gerçek kullanıcı oturumu açılmış ürün” aynı şey değildir. Benzer şekilde “örnek veriyle dolu liste” ile “kullanıcının kendi kaydını veritabanından çekip gösteren ekran” da aynı şey değildir. O yüzden sıradaki adım yeni ekran üretmek değil, sahte veriyi bırakıp ilk gerçek kullanıcı akışını kurmaktır.

Bu aşamada kendine tek bir soru sor: kullanıcı giriş yaptıktan sonra uygulamada yaptığı ilk anlamlı hareket ne olacak? Not mu ekliyor, müşteri mi kaydediyor, görev mi oluşturuyor, proje mi paylaşıyor? Cevap buysa, ilk veritabanı tasarımını da o tek hareketin etrafında kur. Fazlası başlangıçta yük olur.

Doğru sıra ne olmalı?

Çoğu kişi önce bütün ekranları bitirmeye çalışıyor. Daha güvenli sıra bunun tersidir: önce tek kullanıcı senaryosu, sonra veri, sonra ekran bağlantısı. Basit bir yürüyüş planı şöyle olabilir:

1. Uygulamadaki ilk tek işi seç: mesela “kullanıcı giriş yapar ve bir kayıt oluşturur”. 2. O iş için gereken minimum alanları yaz: başlık, açıklama, oluşturma tarihi, kullanıcı kimliği gibi. 3. Giriş yöntemini belirle: e-posta tabanlı sade bir akış mı, yoksa başka bir yöntem mi? 4. İlk kaydetme ve listeleme akışını çalıştır: create ve read yeterlidir; her şeyi aynı gün yapma. 5. Yetki kuralını netleştir: kullanıcı sadece kendi kaydını mı görür? 6. Sonra düzenleme, silme, profil, ayarlar gibi ikinci dalga ekranlara geç.

Bu sıra önemli çünkü arayüzü önce tamamlayınca sahte bir ilerleme hissi oluşur. Oysa gerçek ilerleme, bir test kullanıcısı ile kayıt olup veri ekleyebilmek ve çıkış yapıp tekrar girdiğinde aynı veriyi görebilmektir. Eğer bunu başardıysan proje artık sadece tasarım dosyası değildir.

Hangi parçayı ne için seçiyorum?

Burada amaç belirli bir aracı kutsamak değil, her parçanın görevini karıştırmamaktır. Minimum karar tablosu şöyle okunabilir:

| Parça | Sormanın doğru yolu | Minimum mantık | | --- | --- | --- | | Giriş | Kullanıcı nasıl kimliğini kanıtlayacak? | Basit ve sürdürülebilir tek yöntem seç | | Veritabanı | Uygulamanın ilk sakladığı şey ne? | Tek ana tablo + kullanıcı kimliği ilişkisi | | Sunucu tarafı kontrol | Bu veri kime ait? | Sadece doğru kullanıcının erişebilmesi | | Ortam değişkenleri | Anahtarlar nerede duracak? | Kodun içinde değil, güvenli ayarlarda | | Versiyonlama | Bir şey bozulursa nasıl döneceğim? | Değişiklikleri takip eden net kayıt |

Buradan çıkan pratik ders şu: Supabase şart değildir, başka çözümler de olabilir; şart olan şey mantığın kendisidir. Kimlik doğrulama, veri saklama ve erişim kuralı birbirinden ayrı düşünülmezse araç değişse bile proje çabuk dağılır. Tam tersine, bu üç parçayı temiz ayırırsan bugün başka bir servis, yarın başka bir servis kullansan bile neyi neden yaptığını bilirsin.

Bir diğer kritik nokta da anahtarlar ve gizli bilgiler. Başlangıçta her şeyi tek dosyada tutmak kolay gelir ama bu kötü alışkanlık olur. Uygulamanın çalışması için gereken gizli değerleri kod içine gömmemek, daha ilk günden profesyonel bir refleks kazandırır.

Canlı bir örnekten düşün: proje paylaşım akışı

Bu konuyu soyut bırakmayalım. Vibe Coding Turkey'nin resmi açıklamasında topluluk, proje showcase, araç karşılaştırmaları ve Top Builders mantığı açıkça ürünün parçası olarak anlatılıyor; bunu canlı olarak https://vibecodingturkey.com/tr/topluluk tarafında görebilirsin. Yani “kullanıcı giriş yapar, kendi projesini ekler, sonra onu listede görür” akışı uydurma bir demo değil; gerçek bir builder topluluğunda anlamı olan, doğrulanabilir bir ürün hareketidir.

Böyle bir akış kuruyor olsaydın minimum model şu kadar basit başlayabilirdi: kullanıcı hesabı, proje başlığı, kısa açıklama, kullanılan araçlar ve oluşturma zamanı. İlk sürümde yorum sistemi, beğeni sistemi, puan sistemi, takip sistemi gerekmez. Önce kullanıcı giriş yapsın, bir proje kartı oluştursun, çıkış yapıp tekrar girdiğinde kendi kartını görsün. İşte o an veritabanı gerçekten çalışmaya başlamış olur.

Bu örnek neden önemli? Çünkü yeni başlayanlar çoğu zaman “büyük ürün” hayal edip küçük akışı küçümser. Oysa gerçek ürünler de ilk gün tek bir değerli hareketten başlar. Eğer builder topluluğu mantığında ilk hareket “proje paylaşmak” ise, senin uygulamanda da ilk hareket neyse onu merkeze koyman gerekir. Veritabanı tasarımın ekranlardan değil, bu davranıştan çıkmalıdır.

Sık yapılan hatalar

En yaygın hata, frontend tamamlanmadan backend'e dokunmamak gerektiğini sanmak. Bu düşünce kulağa düzenli gelir ama pratikte gecikmiş karmaşa üretir. Çünkü giriş ve veri ilişkisi kurulmadan tasarlanan birçok ekran, gerçek veriye bağlanınca yeniden yapılır. İkinci yaygın hata, kullanıcı girişi ile yetkiyi aynı şey sanmaktır. Sisteme girmek başka şeydir; hangi kayda erişebileceğini belirlemek başka şeydir. Üçüncü hata, örnek veriyle çalışan sayfayı “bitti” kabul etmektir.

Bir başka büyük sorun da her şeyi ilk haftada kurmaya çalışmaktır: admin paneli, roller, bildirimler, ödeme, takım hesabı, gelişmiş filtreler, analitik. Bunların hepsi sonra gelir. İlk hedefin tek kullanıcılı, anlaşılır, geri dönüp test edilebilir bir akış olması gerekir. Son olarak Git benzeri bir versiyon takibi olmadan ilerlemek de ciddi zaman kaybıdır. Çünkü AI ile çalışırken iyi bir sonucu yanlış prompt kadar, yanlış geri dönüş de bozabilir; neyin ne zaman kırıldığını görebilmek gerekir.

Kimler için DEĞİL

Bu yol, “tek prompt yazayım, akşama tam çalışan SaaS çıksın, ben de hiç hata mesajı görmeyeyim” beklentisi olan kişi için uygun değil. Çünkü giriş, veri ve yetki tarafı ister istemez biraz karar vermeyi, test etmeyi ve bazen geriye dönüp düzeltmeyi gerektirir. Eğer hata mesajı okumak, alan adı isimlendirmek, tablo alanı düşünmek veya akış sadeleştirmek sana tamamen katlanılmaz geliyorsa burada sürtünme yaşarsın.

Aynı şekilde ilk gününde çok kiracılı kurumsal yapı, ağır uyumluluk süreçleri, karmaşık ekip izinleri veya yüksek riskli finansal işlemler kurmak isteyenler için de bu minimal yaklaşım yeterli değildir. Böyle durumlarda daha yavaş, daha belgeli ve daha kontrollü ilerlemek gerekir. Ama tek amacın “ekranı gerçek kullanıcı ve gerçek veriyle buluşturmak” ise, bu sade yaklaşım tam olarak doğru başlangıçtır.