No-Code mu Özel Kod mu? Hangi Durumda Hangisi Gerçekten Daha Ucuza Geliyor

"No-code mu özel kod mu?" sorusu, bir SaaS fikri olan hemen her kurucunun karşısına ilk haftalarda çıkıyor: Bubble, Webflow ya da Airtable gibi bir no-code araçla mı başlanmalı, yoksa doğrudan özel yazılım mı yazdırılmalı? Cevap genelde tek cümleyle geçiştiriliyor — "no-code daha ucuz" — ama bu yalnızca ilk birkaç ay için doğru olan bir genelleme. Altı ay sonra platformun izin vermediği bir özellik istendiğinde ya da kullanıcı sayısı büyüdükçe aylık faturanın bir yazılımcı maaşına yaklaştığı görüldüğünde, gerçek maliyet çizgisinin nerede olduğu ortaya çıkıyor. Bu yazıda o çizgiyi somut sayılarla gösteriyorum.

##No-code, low-code ve özel kod arasındaki fark tam olarak ne?

Üç kategoriyi birbirine karıştırmak çok yaygın, ama aralarındaki fark kararın kendisini belirliyor. No-code araçlar (Bubble, Webflow, Glide, Softr) tamamen görsel bir arayüzle çalışır: veritabanı şemasını sürükle-bırak ile kurar, iş mantığını "eğer şu olursa şunu yap" tipi görsel workflow'larla tanımlarsınız — hiç kod yazmadan. Low-code araçlar (Retool, Airtable, OutSystems) aynı görsel yaklaşımı korur ama gerektiğinde JavaScript ya da SQL sorgusu yazmanıza izin verir; genelde dış müşteriye değil, şirket içi araçlara (admin panel, operasyon ekranı) yönelik kullanılır. Otomasyon/glue araçları (Zapier, Make, n8n) ise bunların hiçbiri değil — var olan sistemleri birbirine bağlar, kendi başına bir ürün değildir. Özel kod ise (Next.js, özel backend + veritabanı) tam kontrol demektir: her satırı siz belirlersiniz, hiçbir platform kısıtına bağlı kalmazsınız — ama her satırın maliyetini de siz karşılarsınız. Doğru soru "hangisi daha iyi" değil, "projemin hangi aşamasında hangisi daha az maliyetli" sorusu.

##No-code gerçekten ne zaman daha ucuza geliyor?

No-code'un maliyet avantajı gerçek — ama belirli koşullarda. Bir fikri henüz doğrulamadıysanız, yani elinizde ödeyen müşteri yoksa, no-code ile 2-4 haftada çalışan bir MVP çıkarıp gerçek kullanıcı tepkisi almak, 8-12 haftalık ve 60.000-150.000 TL'lik bir özel geliştirmeye göre çok daha ucuz bir risk. Aynı şekilde, sadece birkaç kişinin kullanacağı bir dahili araç — stok takibi, personel izin onayı, basit bir CRM — için özel kod yazdırmak nadiren mantıklıdır; Retool ya da Airtable ile bir hafta içinde kurulur ve aylık 50-150 dolar civarı bir maliyetle çalışır. İş mantığınız standart CRUD'un (oluştur-oku-güncelle-sil) ötesine geçmiyorsa — form doldurma, liste görüntüleme, onay akışı, e-posta bildirimi — no-code bu işi gerçekten daha ucuza yapar.

• ▸Fikir henüz doğrulanmadı, önce gerçek talep test edilmek isteniyor
• ▸Kullanım sadece dahili (birkaç çalışan), dış müşteriye açılmıyor
• ▸İş mantığı standart CRUD: form, liste, onay, bildirim
• ▸Entegrasyon ihtiyacı standart (Stripe, Google Sheets, e-posta, takvim)
• ▸Teknik ekip yok ve ilk bütçe sınırlı (aylık 50-300 dolar aralığı)

##Nerede no-code sizi yavaşça köşeye sıkıştırıyor?

No-code'un asıl maliyeti ilk faturada değil, platformun büyüme eğrisinde saklı. Çoğu no-code araç fiyatlandırmasını kullanıcı sayısına, veritabanı satır sayısına ya da "workflow" çalıştırma sayısına göre kademelendirir — ve bu kademeler çoğu zaman doğrusal değil, sıçramalı artar. Bubble'da "Team" planından "Business" planına geçmek aylık faturayı 3-4 kat artırabilir; sebep ek özellik değil, sadece kapasite limitine çarpmış olmanızdır. İkinci sorun vendor lock-in: verinizi dışa aktarabilseniz de, iş mantığınız (workflow'lar, otomasyonlar) platforma özgü bir formatta yazılıdır — başka bir yere taşımak "kopyala-yapıştır" değil, sıfırdan yeniden modelleme demektir. Üçüncü sorun performans tavanı: gerçek zamanlı özellikler (canlı sohbet, anlık bildirim, yoğun veri işleme), karmaşık hesaplama motorları (dinamik fiyatlandırma, eşleştirme algoritması) ya da yüksek trafik, no-code platformların tasarlandığı senaryonun dışına çıkar. Dördüncü sorun uyumluluk: KVKK kapsamında veri saklama yeri, şifreleme detayı ya da erişim logu gibi konularda özelleştirme istediğinizde, platformun sunduğuyla sınırlı kalırsınız.

• ▸Özel bir hesaplama/algoritma gerekiyor (dinamik fiyatlandırma, eşleştirme, skorlama)
• ▸Gerçek zamanlı, yüksek performans gerektiren bir özellik var (canlı bildirim, yoğun veri işleme)
• ▸Alışılmadık bir API ya da eski (legacy) bir sistemle entegrasyon şart
• ▸6-12 ay içinde birkaç bin kullanıcıyı geçme beklentisi var
• ▸KVKK/uyumluluk gereği veri saklama veya erişim üzerinde ince kontrol lazım
• ▸Yatırım almayı planlıyorsunuz ve teknik durum tespiti bekleniyor

Beşinci ve az konuşulan bir maliyet kalemi: ekip. Bubble ya da Webflow uzmanı bulmak, deneyimli bir React/Node geliştiricisi bulmaktan daha zor ve daha az standarttır. İlk kurucu ayrıldığında ya da tatile çıktığında sistemi devralacak birini bulmak, özel bir kod tabanına göre çok daha dar bir havuzdan seçim yapmak anlamına gelir. Ayrıca no-code platformların çoğu, tek bir kişinin "her şeyi bilme" modeliyle büyümesine izin verir — bu da bus factor riski yaratır: o kişi ayrılırsa, kimse workflow'ların mantığını tam çözemeyebilir.

##Gerçek bir senaryo: Bubble'da başlayan bir randevu SaaS'ı

Bunu somutlaştırmak için gerçekçi bir örnek üzerinden gidelim. "Randevu" adlı kurgusal bir SaaS fikri, küçük güzellik salonlarına randevu ve hatırlatma sistemi satmayı hedefliyor. Kurucu, fikri doğrulamadan önce para harcamak istemediği için Bubble'da 3 haftada çalışan bir MVP kurdu: salon sahibi hizmetlerini ekliyor, müşteri online randevu alıyor, sistem e-posta ile hatırlatma gönderiyor. İlk ayda 12, üçüncü ayda 40 ücretli müşteri kazandı — aylık 290 TL'den. Bubble'ın Team planı aylık yaklaşık 115 dolara mal oluyordu; bu ölçekte gayet makuldü. Sekizinci ayda müşteri sayısı 300'e çıktı ve iki şey aynı anda oldu: birincisi, veritabanı ve workflow yoğunluğu Bubble'ın Team plan limitini aştı ve Business plana geçmek gerekti — aylık fatura 475 dolara sıçradı. İkincisi, en büyük müşteriler "Google Takvim ile iki yönlü senkronizasyon" ve "SMS hatırlatma" istedi; bu Bubble'ın plugin ekosisteminde kısmen mümkündü ama her randevu değişikliğinde sayfa yüklenmesi gözle görülür şekilde yavaşladı. Kurucu bu noktada tam bir sıfırdan yeniden yazım yerine hibrit bir yol seçti: ön yüzü Bubble'da bıraktı, randevu mantığını ve entegrasyonları özel bir Next.js + Postgres API'sine taşıdı. Bu geçiş 6 haftalık bir geliştirme işiydi ve yaklaşık 110.000 TL'ye mal oldu. Sonuç: aylık altyapı maliyeti 475 dolardan yaklaşık 65 dolara düştü, performans sorunları ortadan kalktı, ama bu rahatlık 6 haftalık ek bir proje ve bütçe gerektirdi.

##Hibrit yaklaşım gerçekten işe yarıyor mu?

Yukarıdaki senaryoda görülen hibrit model — ön yüzü no-code'da bırakıp arka planı özel kodla değiştirmek — aslında pek çok büyüyen SaaS için en gerçekçi orta yol. Sıfırdan yeniden yazım hem daha pahalı hem de daha riskli: mevcut müşterileriniz çalışan bir üründen ayrılıp yeni bir sisteme geçiş yapmak zorunda kalır, bu da kesinti ve destek yükü demektir. Hibrit yaklaşımda ise kullanıcı arayüzü ve günlük iş akışı aynı kalır, sadece performans ya da ölçek sorunu yaşayan parça (genelde veritabanı ve karmaşık iş mantığı) özel bir API'ye taşınır. Bunun bir sınırı da var: no-code aracınız API entegrasyonuna ne kadar kapalıysa — bazı platformlar üçüncü taraf API çağrılarını kısıtlar ya da pahalı bir eklenti gerektirir — hibrit geçiş o kadar zorlaşır. Bu yüzden bir no-code aracı seçerken en baştan "bu platform dışarıya API çağrısı yapmama izin veriyor mu" sorusunu sormak, altı ay sonra sizi kurtarabilir. Pratikte gördüğüm en sağlıklı yol, no-code'u hiçbir zaman "geçici bir çözüm" gibi değil, ürünün belirli bir aşaması için doğru araç gibi görmek: MVP'de no-code, doğrulanmış büyümede hibrit, gerçek ölçekte ihtiyaç duyulan parçaları özel koda taşımak. Bu üç aşamayı baştan planlayan bir kurucu, geçiş anında panik yapmak yerine zaten hazırlıklı oluyor.

##Karar çerçevesi: Hangi durumda hangisini seçmeli

• ▸Fikir henüz doğrulanmadıysa (ödeyen müşteri yoksa), hız için no-code ile başlayın.
• ▸İş mantığınız standart CRUD'un ötesindeyse (özel hesaplama, gerçek zamanlı özellik), en baştan özel kod düşünün.
• ▸Büyüme planınız 6-12 ay içinde birkaç bin kullanıcıyı geçiyorsa, no-code'un fiyat kademelerini bugünden hesaplayın.
• ▸Yatırım almayı planlıyorsanız, teknik durum tespitinin no-code stack'i sorgulayabileceğini unutmayın.
• ▸Bütçeniz sınırlı ama iş mantığınız karmaşıksa, hibrit bir yol düşünün: no-code ön yüz + özel backend API.

##Sık Sorulan Sorular

>No-code ile başlayıp sonra özel koda geçmek mümkün mü?

Evet, yukarıdaki örnekte olduğu gibi yaygın bir yol. Ama bu düz bir "port" değil — genelde iş mantığını sıfırdan yeniden modellemek gerekir. Veri modelinizi baştan platformdan bağımsız, basit bir ilişkisel şema olarak düşünürseniz (tablolar, ilişkiler, temel alanlar), geçiş sırasında veri taşımak kolaylaşır; asıl emek workflow'ları ve entegrasyonları yeniden yazmaya gider.

>Hangi no-code araçları gerçekten üretim kalitesinde kabul edilir?

Bubble, Webflow, Retool ve Airtable binlerce şirkette gerçek üretimde çalışıyor — bu açıdan "oyuncak" değiller. Ama "üretim kalitesi" ölçeğe ve senaryoya bağlı: bir randevu SaaS'ı ya da dahili operasyon paneli için gayet yeterliler; saniyede binlerce işlem işleyen bir finansal sistem ya da düşük gecikme gerektiren gerçek zamanlı bir uygulama için değiller.

>Low-code ile no-code arasındaki fark tam olarak ne?

No-code sıfır kod yazma varsayar — tamamen görsel arayüzle çalışırsınız. Low-code aynı görsel yaklaşımı korur ama gerektiğinde JavaScript, SQL sorgusu ya da özel script yazmanıza izin verir (Retool'daki özel query'ler gibi). Bu, low-code'u daha esnek yapar ama az da olsa teknik bilgi gerektirir — genelde bir geliştiricinin ya da teknik meraklı bir çalışanın kurup bakımını yapması beklenir.

>Küçük bir işletme için hangisi mantıklı başlangıç noktası?

Tek yapmak istediğiniz "veriyi topla, listele, onayla" ise — envanter takibi, personel izin formu, basit bir müşteri kaydı — no-code ya da low-code yeterli ve çok daha ucuz bir başlangıç. Ama işinizin merkezinde özel bir hesaplama, müşteriye özel bir entegrasyon ya da rakiplerinizden ayrışmanızı sağlayacak bir özellik varsa, baştan özel kod yazdırmak uzun vadede daha az sürpriz getirir — çünkü o özelliği bir platformun izin verdiği kadarla sınırlı tutmak zorunda kalmazsınız.

>No-code'un aylık maliyeti neden bu kadar hızlı artabiliyor?

Çünkü fiyatlandırma çoğu zaman kullanıcı sayısına değil, arka planda çalışan işlem/workflow sayısına ya da veritabanı satır sayısına bağlıdır. Bir kampanya sonrası trafik patlaması ya da yoğun bir entegrasyon, kullanıcı sayınız aynı kalsa bile sizi bir üst plana iter. Bu yüzden büyüme öncesi platformun fiyatlandırma tablosunu satır satır okumak, sözleşme imzalamaktan daha değerli bir yarım saat.

>No-code seçerken ilk günden sorulması gereken en önemli soru ne?

"Bu platformdan çıkmam gerekirse ne kadar zor olur?" sorusu. Somut olarak: verinizi standart bir formatta (CSV, JSON, SQL dump) dışa aktarabiliyor musunuz, platform dışarıya API çağrısı yapmanıza izin veriyor mu, ve fiyatlandırma tablosunda hangi metrik büyüdükçe faturanız sıçrıyor? Bu üç soruya net cevap alamıyorsanız, büyüme sonrası sürpriz yaşama ihtimaliniz yüksek.

Bu kararı bütçe tarafından da düşünmek istersen, sabit fiyat mı saatlik mi yazısı projeni fiyatlandırma açısından nereye oturtacağını netleştirebilir; özel bir değerlendirme istersen iletişim sayfası her zaman açık.