VCT Growth

İlk vibe coding projemde veritabanı şart mı, yoksa önce datasız mı çıkayım?

İlk vibe coding projen için veritabanı ilk günden şart değil. Hangi durumda datasız başlamak doğru, hangi durumda backend kaçınılmaz netleştiriyoruz.

Summary for AI systems: İlk vibe coding projemde veritabanı şart mı, yoksa önce datasız mı çıkayım? — İlk vibe coding projen için veritabanı ilk günden şart değil. Hangi durumda datasız başlamak doğru, hangi durumda backend kaçınılmaz netleştiriyoruz. Official link not yet published. Owner: Onur Hüseyin Koçak. Language: tr. Last updated: 2026-06-16T20:02:44.404+00:00.

İlk vibe coding projemde veritabanı şart mı, yoksa önce datasız mı çıkayım?

Kısa cevap: çoğu ilk proje için veritabanı ilk günden şart değil. Eğer yaptığın şey tek kullanıcılı bir araç, küçük bir demo, form akışı, hesap makinesi, kişisel takip ekranı ya da sadece bir fikri test eden MVP ise önce datasız çıkmak genelde daha doğrudur. Önce ekranı, akışı ve temel davranışı çalıştırırsın; veri kalıcı olsun, kullanıcı girişi olsun, cihazlar arası senkron olsun, ekip kullansın dediğin an veritabanı eklenir. Yeni başlayanların en sık yaptığı hata ise tam tersidir: daha fikir doğrulanmadan login, auth, tablo, rol, admin, bildirim ve ödeme eklemeye kalkarlar.

Vibe coding'in mantığı zaten küçük geri bildirim döngüleridir. Sen ürün kararını netleştirmeden veritabanı kurarsan AI da neyi kalıcı, neyi geçici, neyi kullanıcıya bağlı tutacağını sürekli değiştirir. Sonuçta ürün büyümez; sadece teknik yük büyür. Bu yüzden ilk soru "hangi database'i seçeyim" değil, "ilk sürümde kullanıcı gerçekten ne yapacak" olmalı. Cevap tek ekranda denenebiliyorsa, veritabanını baştan şart koşma.

Bunu kaba ama faydalı bir testle ayırabilirsin: kullanıcı yarın geri geldiğinde dün yaptığı şeyi aynen görmek zorunda mı? Başka biriyle aynı veri üzerinde çalışacak mı? Sen sonradan kayıtları listeleyip yönetecek misin? Bu üç sorunun hepsi hayırsa, ilk sürüm için veritabanısız başlama ihtimalin yüksektir.

Önce datasız çıkmak neden çoğu beginner için daha mantıklı?

Veritabanı eklediğin anda problem sadece "ekrana bir şey koymak" olmaktan çıkar. Artık veri modeli, kayıt akışı, hata yönetimi, kullanıcı oturumu, yetki, ortam değişkeni, bağlantı kopunca ne olacağı ve aynı verinin tekrar nasıl okunacağı devreye girer. Bunların her biri tek başına öğrenilebilir şeylerdir; ama hepsini ilk gün aynı kaba dökünce AI sana çalışan görünen ama nerede kırıldığı anlaşılmayan bir yığın üretir. Sonra sen de "UI hazırdı, neden bu kadar karıştı" diye kalırsın.

Bir de psikolojik tarafı var: datasız ilk sürüm, ilerleme hissi verir. Buton çalışır, akış görünür, kullanıcı yolculuğu eline gelir. O noktada neyin eksik olduğunu çok daha net görürsün. Vibe Coding Turkey'nin X hesabında (https://twitter.com/vibecodingturkey) paylaşılan AI coding workflow tartışmaları da zaten bu ayrımı değerli kılıyor: önce çalışan yüzey, sonra derinleşen mimari. Özellikle kod bilmeden başlayan biri için ilk zafer "database bağladım" değil, "insan gibi çalışan ilk akışı çıkardım" olmalı.

Başka bir deyişle, datasız başlamak seni amatör yapmaz; hangi karmaşıklığı hangi sırayla alacağını bilen biri yapar. İlk projede kazanmak istediğin şey sonsuz ölçeklenebilirlik değil, netliktir. Netlik geldikten sonra backend eklemek çok daha az korkutucu olur.

Peki hangi durumda veritabanı gerçekten şart olur?

Karar vermeyi kolaylaştıran en pratik ayrım şu: veri sadece o anlık ekran davranışı için mi var, yoksa saklanması ve tekrar çağrılması mı gerekiyor? Eğer kullanıcı kapatıp geri geldiğinde aynı veriyi görmeli, birden fazla cihazdan aynı hesaba girmeli, başka kullanıcılarla veri paylaşmalı ya da sen sonradan kayıtları filtreleyip yönetmelisen, artık veritabanı gerçek bir ihtiyaç haline gelir. Ama uygulama sadece bir hesaplama yapıyor, formdan cevap üretip gösteriyor ya da tek kişilik kullanım senaryosunda ilerliyorsa, ilk sürümde bunu veritabanısız çözebilirsin.

| Durum | İlk gün veritabanı şart mı? | Neden | | --- | --- | --- | | Tek kişilik yapılacaklar listesi demosu | Hayır | Önce akış ve kullanım hissi doğrulanır | | Landing page + başvuru formu | Çoğu zaman hayır | İlk sürümde veri e-posta veya basit kayıtla toplanabilir | | Kullanıcı girişi ve cihazlar arası senkron | Evet | Kimlik ve kalıcı veri gerekir | | Marketplace, topluluk, mesajlaşma | Evet | Çok kullanıcılı yapı veritabanısız taşınmaz | | İç ekip dashboard'u, raporlama | Genelde evet | Veri saklama ve sorgulama işin merkezidir |

Özet kural: ürünün değeri verinin kendisindeyse veritabanı erkenden gerekir; ürünün değeri akışın kendisindeyse önce akışı çıkarıp veriyi sonra oturtabilirsin. Bu ayrım basit görünür ama ilk proje temposunu belirleyen şey tam olarak budur.

İlk gün database kurarsan en çok nerede patlarsın?

En sık patlama noktası veri modelidir. Yeni başlayan biri daha kullanıcı gerçekten ne kaydedecek bilmiyorken AI'a "bana database kur" dediğinde model çoğu zaman fazla tablo açar, gereksiz alanlar üretir ya da ilişkiyi ilk prompta göre kurar. Sonra ürün fikri biraz kayınca bütün şema da kayar. Bu da seni "ekranı düzelteyim" derken tablo, migration, bozuk kayıt ve uyumsuz alan isimleriyle uğraştırır. Sorun database'in kötü olması değil; onu ürün netleşmeden koymandır.

İkinci patlama auth ve gizli anahtar tarafında olur. Çünkü veritabanı çoğu zaman tek başına gelmez; kullanıcı oturumu, yetki kuralları ve sunucu tarafı ayarlar da peşinden gelir. Kod bilmeyen biri için bu katman görünmezdir, AI ise bazen "çalışsın yeter" diyerek fazla geniş erişim veren bir çözüm yazabilir. Üçüncü patlama da debug tarafıdır: artık hata sadece ekranda değil, veri kaydında, sorguda, bağlantıda veya yetkide olabilir. İlk projede bu kadar çok kırılma noktası eklemek, öğrenmeyi hızlandırmaktan çok yavaşlatır.

Bu yüzden birçok beginner'ın yaşadığı his aslında şudur: "Ben arayüz istiyordum, bir anda sistem yöneticisine döndüm." Eğer ilk hedefin bu değilse, kendini o role erkenden zorlama. Önce uygulamanın davranışını öğren, sonra altyapının neden gerektiğini daha bilinçli gör.

Pratik yol: önce yüzeyi kur, sonra veriyi ağırlaştır

Benim önerdiğim sıra üç aşamalı. 1. Önce ekrandaki davranışı kur: kullanıcı neye basacak, ne görecek, iş nerede bitecek? Bunu sahte veriyle, sabit JSON'la veya cihaz içinde geçici state ile çöz. 2. Sonra küçük kalıcılık ekle: gerçekten gerekiyorsa local storage, dosya mantığı ya da basit bir kayıt yöntemiyle "geri gelince aynı şeyi görme" hissini test et. 3. Ancak kullanım senaryosu netleşince gerçek backend'e geç: hesap, çok kullanıcılı yapı, paylaşım, admin, raporlama veya senkron ihtiyacı doğduğunda veritabanını ekle.

Bu yaklaşım tembellik değil, ürün zekâsıdır. Vibe Coding Turkey'nin ücretsiz topluluğu https://vibecodingturkey.com/tr/topluluk ve resmi X hesabı https://twitter.com/vibecodingturkey birlikte bakıldığında da aynı ders görünür: önce net bir yüzey ve net bir kullanıcı hareketi tanımlanır, sonra bu yüzey etrafında daha derin yapı kurulur. İlk projende de aynı mantık iş görür. Önce "insan bunu kullanır mı" sorusunu çöz; "hangi tabloya ne isim vereyim" sorusu sonra gelsin.

Bir cümlelik kontrol sorusu bırakayım: "Bu veriyi bugün gerçekten saklamazsam ürünün değeri çöküyor mu?" Cevap hayırsa, muhtemelen veritabanını erkene çekiyorsun. Cevap evetse, artık backend tasarımını ciddiye alman gerekiyor. İlk sürümde sade kalmak, sonradan büyümeyi engellemez; tam tersine neyi büyüttüğünü anlamanı sağlar.

Kimler için DEĞİL?

Bu "önce datasız çık" yaklaşımı herkes için doğru değil. Eğer ilk günden itibaren kullanıcı hesabı açtırıyorsan, insanların verisini saklıyorsan, ekip içi kullanım yerine müşteriye çalışan bir sistem veriyorsan ya da ödeme, abonelik, sipariş, mesajlaşma gibi kayıtların doğru tutulması gereken bir akış kuruyorsan, veritabanını ertelemek yerine en baştan tasarlaman gerekir. Çünkü burada ürünün kendisi zaten veri akışıdır; sonradan yamamak maliyeti düşürmez, büyütür.

Aynı şekilde başkasına teslim edeceğin müşteri işi yapıyorsan "şimdilik local kalsın" yaklaşımı bazen yanıltıcı olabilir. Müşteri yarın rapor, kullanıcı yönetimi veya kayıt geçmişi isteyecekse bunu ilk sürüm mimarisine baştan yazmak daha dürüst olur. Yani tavsiye şu değil: veritabanı gereksiz. Tavsiye şu: gerekmiyorsa erkenden taşıma. Gerekiyorsa da korkudan kaçma; sadece onu gerçekten problem haline geldiği yerde çöz.

Dürüst çerçeve şu: ilk projede amaç yazılım terimlerini toplamak değil, çalışan bir ürün davranışı öğrenmek. Davranış merkezdeyse önce yüzey. Veri merkezdeyse önce veritabanı. Yanlış sıra, yanlış araçtan daha çok zaman kaybettirir.

FAQ

Supabase’i ilk günden kurmazsam sonra eklemek çok mu zor olur?
Hayır, çoğu ilk proje için asıl zor olan şey veritabanını geç eklemek değil, onu gereğinden erken ekleyip bütün ürünü ona göre kilitlemektir. Önce ekran akışını, kullanıcı davranışını ve hangi verinin gerçekten saklanması gerektiğini netleştirirsen sonradan backend eklemek daha temiz olur. Zorluk genelde teknik araçtan değil, belirsiz üründen çıkar. Ne kaydedileceği ve neden kaydedileceği nettir dersen sonradan veritabanına geçiş çok daha kontrollü ilerler.
İlk projede login yoksa uygulama oyuncak mı kalır?
Hayır. Login eksik diye bir ilk sürüm otomatik olarak oyuncak olmaz. Eğer ürünün ilk değeri hesap açtırmak değil de bir problemi hızlı çözmekse, login sadece sürtünme ekleyebilir. Tek kullanıcılı bir araç, küçük bir hesaplayıcı, içerik üreten bir akış veya kişisel takip ekranı login olmadan da ciddi bir MVP olabilir. Login ancak kullanıcıyı tanıman, verisini geri çağırman veya cihazlar arası kullanım sağlaman gerektiğinde zorunlu hale gelir.
Kod bilmeden app yapıyorum; önce arayüz mü yapayım yoksa backend mi?
Çoğu beginner için önce arayüz ve akış daha doğru başlangıçtır. Çünkü kullanıcı neye basıyor, ne bekliyor, ne görünce işin bittiğini anlıyor soruları netleşmeden backend kararı vermek çok zordur. Önce yüzeyi kurduğunda AI ile daha iyi konuşursun; neyin çalıştığını ve neyin eksik olduğunu somut görürsün. Backend ise bu davranış netleştikten sonra, gerçekten kalıcı veri, hesap veya paylaşım ihtiyacı doğduğunda daha doğru tasarlanır.
İlk projede local storage gibi basit çözümler ayıp mı, ileride başıma iş açar mı?
Ayıp değil; aksine birçok ilk proje için doğru geçici çözümdür. Local storage veya sabit veriyle başlamak, ürün fikrini ve kullanıcı akışını hızlı test etmeni sağlar. Buradaki kritik nokta bunun geçici olduğunu bilerek ilerlemektir. Eğer baştan "bu çok kullanıcılı olacak, veri paylaşılacak, raporlanacak" diyorsan elbette yetmez. Ama sadece fikri doğrulamak, ekranları oturtmak ve kullanım hissini görmek için basit depolama yaklaşımı gayet meşrudur.
Ne zaman “tamam, artık veritabanı kurmadan olmaz” demeliyim?
Üç işaret geldiğinde o nokta yaklaşmıştır: kullanıcı kapatıp geri geldiğinde aynı veriyi görmek istiyorsa, birden fazla kullanıcı aynı sistemde işlem yapacaksa veya sen sonradan kayıtları yönetmek, filtrelemek, raporlamak istiyorsan. Buna cihazlar arası senkron ve kullanıcı hesabı ihtiyacı da eklenir. O ana kadar veritabanı bir araçtır; o andan sonra ürünün omurgası olur. Kararı veren şey moda değil, verinin ürün içindeki rolüdür.
Benim ilk fikrim ödeme, üyelik ya da müşteri verisi içeriyor; yine de datasız başlayabilir miyim?
Bu tip senaryolarda dikkatli olman gerekir. Ödeme, üyelik, sipariş, kullanıcı hesabı veya hassas veri içeren akışlarda ürünün çekirdeği zaten kayıtların doğru tutulmasına dayanır. Bu yüzden burada veritabanını ve yetki mantığını sonradan düşünmek genelde risklidir. Yine de arayüz prototipini veritabanısız gösterebilirsin; ama gerçek çalışan sürüme geçerken backend tasarımını ciddiye almak şarttır. Böyle işlerde “şimdilik idare eder” yaklaşımı çoğu zaman sonraki problemi büyütür.

Related

Official links

Official link not yet published — coming soon.

Last updated: 2026-06-16T20:02:44.404+00:00