Dürüst olmak gerekirse, Geçen ay Kadıköy’de bir kahve dükkânında otururken, yan masadaki kurucu arkadaşım telefonunu masaya bıraktı ve şunu söyledi: “Uygulama çalışıyor ama içim rahat değil.” Tek cümle. Ama o cümle aslında AI builder dünyasının tam özetiydi bence — Lovable, Bolt ya da benzeri araçlarla ekranlar hızlıca kuruluyor, kullanıcı geliyor, para akmaya başlıyor… sonra bir bakıyorsun iş prod’a taşınacak ve ortada gerçek anlamda güvenilecek bir altyapı yok. İşin can sıkıcı tarafı da tam bu.
Bak şimdi, mesele sadece “kod yazıldı mı yazılmadı mı” değil (bu beni çok şaşırttı). Asıl soru şu: o kodu kim taşıyor, veri nerede duruyor, geri dönüş planın var mı? Editör masasında bu konuyu ilk gördüğümde hemen test etmek istedim — çünkü 2023’te küçük bir SaaS projesinde benzer bir duvara çarpmıştım. Tarayıcıda şahane görünen şey, üretimde bir anda çok nazlı bir yapıya dönüşmüştü. Hani her şey güzel giderken arka planda sessizce büyüyen teknik borç var ya… işte tam o.
AI builder’lar hız için harika; ama üretim tarafında hız tek başına yetmiyor. Kodun taşınabilir olması, verinin sana ait olması ve geri alma planının bulunması çok daha kritik.
Nerede kopuyor? Tarayıcıdaki başarı neden prod’da tökezliyor
Açıkçası, AI ile kurulan uygulamalar ilk bakışta çok güzel görünüyor. Gerçekten. Arayüz hızlı çıkıyor, formlar çalışıyor, basit API çağrıları bağlanıyor — ama işin aslına bakarsak tarayıcıda çalışan demo ile gerçek kullanıcı trafiği bambaşka iki dünya, yani aralarında dağlar var. Birinde birkaç deneme yaparsın; diğerinde ödeme gelir, müşteri destek bileti açılır, ekip “neden bu kayıt düşmedi?” diye sorar.
İnanın, Burada en büyük sorunlardan biri bağımlılık zinciri. Uygulamanın frontend’i belirli endpoint’lere göre şekilleniyor, veritabanı ise çoğu zaman builder’ın kendi mantığına sıkışıp kalıyor. Yani sen “uygulama benim” sanıyorsun ama aslında bazı kilit parçalar başkasının bahçesinde duruyor. Geçen sene Şişli’de çalışan bir ürün ekibiyle konuşmuştum; iki kişilik çekirdek ekip, Emergent benzeri bir yapıdan Vercel’e geçerken sorguların cached response varsayımıyla optimize edildiğini fark etmişlerdi. Sonra ne oldu? Veri katmanını neredeyse baştan kurdular. Haftalar gitti. Can sıkıcıydı.
Evet, doğru duydunuz.
Üretimde aranan şeyler başka
Aslında, Üretim ortamında ihtiyacınız olan şey sadece çalışan kod değil. Sürüm geçmişi, rollback mekanizması, izlenebilirlik. Temiz deployment süreci — bunlar yoksa uygulama biraz oyuncak gibi kalıyor. Çalışır. Ama kırılınca toparlaması çok zahmetli olur.
Bir de şu var, hmm nasıl desem… AI builder araçları genelde tekrar için optimize ediliyor. Bu kötü değil, hatta baya iyi. Fakat iterasyonla production arasında ince. Keskin bir çizgi var — mutfakta tadım yapmakla restoran açmak arasındaki fark gibi düşünebilirsin.
| Alan | Builder Aşaması | Prod Aşaması |
|---|---|---|
| Kod sahipliği | Kısmi / araç merkezli | Tam Git kontrolü gerekir |
| Veri yönetimi | Çoğu zaman gömülü veya dolaylı | Sana ait veritabanı şart |
| Rollback | Zayıf ya da yok | Anlık geri dönüş lazım |
| Deployment geçmişi | Sınırlı görünürlük | Tam kayıt ve izleme gerekli |
Asıl maliyet gecikince çıkıyor
Uzatmayalım demeyeceğim — çünkü mesele gerçekten uzuyor. Bir uygulamayı builder üzerinde ne kadar uzun tutarsanız, etrafında o kadar çok görünmez borç örülüyor. İlk günlerde fark etmiyorsunuz. Trafik düşük, hata sayısı az, ekip morali yüksek (ben de ilk duyduğumda şaşırmıştım). her şey güllük gülistanlık.
Kullanıcı sayısı artınca tablo değişiyor. Ödeme entegrasyonu patlıyor mu? Kim düzeltecek? Schema değişecek mi? Mevcut yapı buna dayanabilecek mi? Kodu Git’e tam taşımadıysanız veya deployment hattınız net değilse her değişiklik kumara dönüyor — ciddi söylüyorum.
Ben bunu küçük ajans projelerinde de gördüm, startup’larda da. Hatta geçen martta Maslak’taki bir toplantıda biri bana açıkça şunu söyledi: “İlk üç hafta çok rahattık, dördüncü haftadan sonra her değişiklikten önce dua eder olduk.” Abartı değil yani (bu konuda ikircikliyim). Geciken migrasyon genelde daha pahalıya patlıyor; çünkü sistem artık sadece teknik değil, operasyonel olarak da bir dolaşıklık kazanmış oluyor. Onu çözmek başlı başına bir iş haline geliyor.
Peki ne işe yarıyor? Sağlam yol aslında düşündüğünüz kadar karmaşık değil
İşin güzel tarafı şu: doğru kurgu ile bu geçiş devasa bir proje olmak zorunda değil. Solo founder’ların bile sprint içinde AI builder’dan üretim altyapısına geçtiğini bizzat gördüm. Ana fikir şu — builder’ı bırakmak zorunda değilsiniz. Onu tasarım ve hız katmanı olarak kullanabilirsiniz, gayet mantıklı bir tercih (yanlış duymadınız)
Küçük bir startup için en mantıklı model şöyle kuruluyor: builder’da prototip çıkarırsın, sonra deploy hedefini netleştirirsin (mesela Vercel ya da AWS), ardından veri katmanını bağımsız hale getirirsin. Kurumsal tarafta iş biraz daha ağır ilerliyor; uyumluluk gereksinimleri, loglama politikaları, erişim kontrolleri devreye giriyor. Enterprise seviyede “güzel görünüyor” demek yetmiyor — güvenlik ekibi de ikna olmalı, hani o da ayrı bir macera.
Küçük ekip ile büyük ekip aynı yolu yürümüyor
Küçük ekiplerde öncelik hızdır. Ama kör hız değil tabii. Bence burada en doğru yaklaşım minimum operasyon yüküyle maksimum sahiplik almak. Büyük yapılarda ise olay farklı; rollback süresi beş dakika mı on beş saniye mi sorusu doğrudan iş etkisine dönüşür. Küçümsenecek bir fark değil.
Bir dakika — bununla bitmedi. Kodunu Gerçekten Tanıyan Yerel Yapay Zekâ: LeanAI Ne Vaat Ediyor? yazımızda bu konuya da değinmiştik.
- Küçük startup: Hızlı export + temiz Git + basit deployment hattı yeterli olabilir.
- Büyüyen ürün ekibi: Database migration planı ve staging ortamı şart olur.
- Kurumsal yapı: SOC2 benzeri uyumluluk beklentileri ve detaylı audit izi gerekir.
- E-ticaret / SaaS: Geri alma mekanizması olmadan canlıya çıkmak risklidir.
Açık konuşayım — burada hayal kırıklığı yaşatan nokta bazen aracın kendisi değil, insanların onu final çözüm sanması oluyor. Oysa builder dediğin şey çoğu zaman iyi bir atölye tezgâhıdır. Fabrika değildir. İkisini karıştırınca işler sarpa sarıyor.
Nometria tarzı çözümler neden dikkat çekiyor?
Editör olarak incelediğimde beni en çok cezbeden şu oldu: bazı çözümler AI builder’dan çıkan uygulamayı alıp kendi kontrol ettiğin altyapıya taşıma iddiasıyla geliyor. CLI üzerinden işlem yapmak isteyen de var, VS Code eklentisiyle gitmek isteyen de… hatta Chrome extension kullanan ekipler bile gördüm. Evet, gerçek.
Böyle araçların güçlü tarafı yalnızca deployment kolaylığı değil — aynı zamanda preview server sunmaları ve rollback’i birkaç saniyeye indirmeleri. Bu kulağa pazarlama cümlesi gibi gelebilir ama pratikte ciddi fark yaratıyor. Çünkü canlıya çıkmadan önce testi görmek istiyorsun; hele ödeme alan bir uygulamada kör atış yapmak pek akıllıca olmaz, değil mi?
// Mantık basit:
1) Builder'da geliştir
2) Kodu Git'e bağla
3) Deployment'ı kendi altyapına taşı
4) Veritabanını ayrı yönet
5) Preview ortamında test et
6) Canlıya al
7) Gerekirse saniyeler içinde geri dön
Sorun nerede bitiyor?
Aslında, Sorun aracın kendisinde bitmiyor aslında. Sınırları yanlış okumakta bitiyor diyebilirim. Bu araçlar sana hız veriyor, tamam — ama mimari kararları senin yerine sonsuza dek alamazlar. Az önce “araç seçimi meselesi” dedim ama şunu da ekleyeyim: asıl mesele kritik kontrol noktalarının sende olması. “Kendi sunucun olsun” romantizmi değil bu; veri, deploy geçmişi ve kaynak kodu kimin elinde, ona bakıyoruz.
Ve işler burada ilginçleşiyor. Bu konuyla ilgili ABD’de LLC Kurmak: Yabancılar İçin 2026 Rehberi yazımıza da göz atmanızı tavsiye ederim.
Bakın, Bence sağlıklı model şöyle kurulur: deneysel işleri builder’da tutmak serbesttir, ama müşteri verisi, deploy geçmişi ve kaynak kodu senin alanına geçmeli. Ha, bu arada güvenlik konusu da küçümsenecek gibi değil. Dışarıdan bakınca ufak ayrıntılar gibi duran izinler ve erişimler büyüdükçe ciddi baş ağrısına dönüşüyor — bunu deneyimleyerek öğrenenler iyi bilir. Apple’ın Mac Çıkışı: Q1 2026’da Yüzde 9 Sıçrama yazımızda bu konuya da değinmiştik.
Mimaride gözden kaçan pratik detaylar
Bence, Bazen insanlar altyapıyı konuşurken sadece bulut sağlayıcısını tartışıyorlar. Oysa asıl önemli parçalar orada gizleniyor — mesela secrets yönetimi nasıl yapılıyor, environment değişkenleri nasıl ayrılıyor, loglar hangi sisteme akıyor? Bunların her biri ufak görünür. Ama toplamda kader belirler.
Kod versiyonlanmamışsa geri dönüş zordur. Veri taşınabilir değilse bağımlılık artar. Deploy süreci otomatikleştirilmemişse insan hatası büyür. Kısacası mesele tek tek parçalardan çok zincirin tamamıdır — zincir bir noktadan kopunca da herkes birbirine bakar kalır. O anı yaşayanlar ne demek istediğimi gayet iyi anlıyor.
İyi bir AI builder stratejisi “araç seçmek” değildir; neyi araçta bırakacağınızı ve neyi sahiplenmeniz gerektiğini bilmekten geçer.
Benden kısa notlar: Ne yapmalı?
Lafı gevelemeden söyleyeyim: bugün AI builder üzerinde çalışan gerçek bir ürününüz varsa panik yapmayın, ama ertelemeyin de. Yol haritasını çıkarın. Gerekiyorsa önce staging’e taşıyın, sonra production’a geçin. Bazen iki aşamalı hareket etmek en temiz yol oluyor — denedim, işe yarıyor.
Şunu fark ettim: Aşağıdaki sıra çoğu ekip için iş görüyor:
- Kod çıktısını GitHub’a bağlayın.
- Mantıklı bir hosting hedefi seçin (Vercel/AWS vb.).
- Veritabanını bağımsız yönetin veya migrate edin.
- Preview ortamını aktif edin.
- Deployment geçmişini kaydedin.
- Rollback’i test edin — evet, test edin, atlamamayın.
- Gözlemleme/loglama kurun.
Tabi her proje aynı ritimde ilerlemez (ki bu çoğu kişinin gözünden kaçıyor). Sadece landing page yapan mini projeyle müşteri verisi tutan SaaS’yi aynı kefeye koyamazsınız — koyarsanız ya biri fazla yavaşlar ya diğeri gereksiz yere karmaşıklaşır. Burada esas soru şu: bugün sizi yavaşlatan şey gerçekten teknoloji mi, yoksa belirsizlik mi?
Sıkça Sorulan Sorular
AI builder ile yapılan uygulama prod’a uygun mu?
Bazen evet ama çoğu zaman tek başına yeterli olmuyor.Browser’da iyi çalışan şey prod’da veri yönetimi, rollback ve ölçeklenme yüzünden zorlanabiliyor.O yüzden son kararı vermeden önce altyapıyı ayrı değerlendirmek gerekiyor.
Neden veritabanını ayrı taşımak önemli?
Açık konuşayım, Çünkü veri sizin işinizin omurgasıdır.Builder’ın içine gömülü kalırsa taşınabilirlik azalır.Veri size ait olmadığında ürünün geleceği de biraz bulanıklaşır.
Küçük ekipler böyle bir migrasyona nasıl başlamalı?
Önce kodu Git’e alın sonra deployment hedefini belirleyin.Arkasından staging ortamında deneyip canlıya öyle geçin.Karmaşık görünse de adımları bölünce gayet yapılabilir hale geliyor.
Rollback neden bu kadar kritik?
Şöyle söyleyeyim, Çünkü canlıda hata çıktığında dakikalar bile önemli.Rollback yoksa düzeltme baskısı artar ve hata maliyeti yükselir.Hızlı geri dönüş bazen yeni özellikten daha değerlidir.
Daha fazla okumak isterseniz…
Şöyle söyleyeyim, AI ile Kurulan Uygulamalar Neden İşletmeleri Zorluyor? (şaşırtıcı ama gerçek)
JavaScript’te Kod Nasıl Çalışır: Context ve Scope
CI On Bir Dili Görmezse İşiniz Yarıda Kalır!
Kaynaklar ve İleri Okuma
Orijinal Yazı — Nometria / Dev.to
Vercel Docs — Deployment Rehberi
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
