No-Code Uygulama (FlutterFlow, Bubble): Nereye Kadar?

No-code uygulama platformları 2026'da gerçekten yayına çıkabilen ürünler üretiyor; asıl sınır yetenekte değil sahiplikte. FlutterFlow size Flutter kaynak kodunu indirtiyor, Bubble ise uygulamanızı kod olarak dışa aktarma imkânı vermiyor. Kararı çıkış maliyetine bakarak verin.

Bu ayrım kulağa teknik bir detay gibi görünüyor ama üç yıl sonra şirketinizin elinde ne kalacağını belirleyen tek şey. Aşağıda FlutterFlow, Bubble ve Adalo'nun resmî fiyat ve doküman sayfalarından doğrulanmış verilerle altı somut sınırı, abonelik maliyetinin üç yıllık tablosunu ve platformdan çıkmanız gerektiğinde izleyeceğiniz yol haritasını bulacaksınız.

İçindekiler

• No-Code Uygulama Nedir, Nereye Kadar Gider?
• FlutterFlow, Bubble ve Adalo: Üç Farklı Model
• Abonelik Maliyeti: Aylık Ucuz, Üçüncü Yılda Pahalı
• Sınır 1: Özel Entegrasyon ve Karmaşık Mantık
• Sınır 2: Performans ve Ölçeklenme
• Sınır 3: Mağaza Politikaları
• Sınır 4: Veri Yerleşimi ve KVKK
• Sınır 5: Güvenlik ve Yönetişim
• Sınır 6: Platform Riski
• Platformdan Çıkış: Özel Koda Geçiş Yol Haritası
• No-Code mu, Özel Yazılım mı?
• Sıkça Sorulan Sorular

No-Code Uygulama Nedir, Nereye Kadar Gider?

No-code uygulama geliştirme, ekranları ve iş akışlarını kod yazmak yerine görsel bir editörde kurduğunuz yaklaşımdır. Sürükle-bırak bir tuval, hazır bileşenler, bir veritabanı ve "kullanıcı butona basınca şunu yap" biçiminde tanımladığınız iş akışları: platform bu tanımı çalışan bir web ya da mobil uygulamaya dönüştürür.

Pazarın büyüklüğü bu yaklaşımın artık niş olmadığını gösteriyor. Gartner'ın tahminine göre düşük kodlu geliştirme teknolojileri pazarı 2026'da 44,5 milyar dolara ulaşıyor ve yeni uygulama geliştirme çalışmalarının yüzde 75'inde bu araçlar bir rol oynuyor; 2021'de bu oran yüzde 40 seviyesindeydi (Le Monde Informatique'in aktardığı Gartner verisi).

Buradaki soru "no-code uygulama çalışır mı" değil. Çalışıyor. Doğru soru şu: sizin işinizin gerektirdiği yere kadar gidiyor mu? Bir iç raporlama aracı, bir saha ekibi için veri toplama uygulaması, bir pazar testi ya da yatırımcıya gösterilecek bir MVP için fazlasıyla yeterli. Günde on binlerce işlem gören, özel ödeme akışları ve mevzuat yükümlülükleri olan bir ürün için başka bir hikâye.

Bir ayrım daha yapalım: no-code uygulama platformları ile yazıya dökülmüş bir istemden kod üreten yapay zekâ araçları aynı şey değil. İlkinde mantığı siz görsel olarak kuruyorsunuz, ikincisinde modelin ürettiği kodu devralıyorsunuz. İkisinin karşılaştırmasını yapay zekâya uygulama yaptırmak yazısında ayrıca ele aldık; bu yazı tamamen platformlara odaklanıyor.

FlutterFlow, Bubble ve Adalo: Üç Farklı Model

Üç popüler platform aynı işi yapıyor gibi görünse de teknik olarak birbirinden çok farklı üç şey üretiyor.

FlutterFlow, Google'ın Flutter çerçevesi için gerçek Dart kodu üretir. Flutter'ın resmî dokümantasyonuna göre Dart kodu iOS ve Android'de ahead-of-time (AOT) derlenerek yerel makine koduna dönüşür; arayüzü de tarayıcı görünümü yerine Flutter'ın kendi Impeller motoru çizer (Flutter FAQ). Yani FlutterFlow çıktısı teknik olarak bir native uygulamadır. FlutterFlow'un sahiplik sayfasındaki ifade de net: "As you develop using FlutterFlow, you own the output of your work" (FlutterFlow dokümantasyonu).

Bubble, web uygulaması üretmekle başladı, bugün aynı editörden iOS ve Android uygulaması da yayınlatıyor. Platformun kendi dokümanı mobil uygulamaların bir "wrapper" olmadığını, cihaz üzerinde çalıştığını söylüyor; ancak hazır web sayfalarınızı mobil ekrana gömmek için kullandığınız WebView elementinin içinde konum, kamera ve push bildirim gibi yerel özelliklerin çalışmadığını da açıkça yazıyor. Kritik fark şurada: Bubble, destek makalesinde "Bubble apps don't exist as code in the traditional sense, and can only run on the Bubble platform. There's currently no way of exporting your application as code" diyor (Bubble destek).

Adalo, üçünün en basit olanı ve küçük ekipler için en hızlı başlangıcı sunuyor. Fiyat sayfasına göre ücretsiz plan hiçbir uygulamayı mağazaya çıkarmıyor; mağazalara çıkmak için Starter planına geçmeniz gerekiyor ve planlar yayınlanan uygulama sayısını 1, 2 ve 5 ile sınırlıyor (Adalo fiyatlandırma).

Tablodaki "kaynak kod" kolonu, bu yazının tamamını özetliyor. Kod sahipliğinin neden sözleşmeye yazılması gereken bir madde olduğunu kaynak kod teslimi yazısında ayrıntılı anlattık.

Abonelik Maliyeti: Aylık Ucuz, Üçüncü Yılda Pahalı

No-code uygulama platformlarının en güçlü satış argümanı ilk ay faturası. Ancak abonelik bitmeyen bir kalem; üç yıllık toplamı hesaplayınca tablo değişiyor. Aşağıdaki rakamları platformların kendi fiyat sayfalarından derledik; tablo yalnızca yazılım aboneliğini kapsıyor.

Mağaza ücretleri sabit: Apple Developer Program yıllık 99 dolar (Apple), Google Play Console kaydı tek seferlik 25 dolar (Google). Bubble'ın fiyat sayfası Starter planı 59, Growth planı 209, Team planı 549 dolar olarak listeliyor ve bunlar yıllık faturalandırma rakamları; ücretsiz planda aylık 50 bin, Starter'da 175 bin, Growth'ta 250 bin, Team'de 500 bin workload unit var (Bubble fiyatlandırma). FlutterFlow'da kod indirme ve APK çıktısı 39 dolarlık Basic planda açılıyor, GitHub entegrasyonu Growth planında (ilk koltuk 80 dolar), tek tıkla mağaza dağıtımı ve CLI erişimi Business planında (FlutterFlow fiyatlandırma).

Bu toplamların hiçbiri tasarım, içerik, entegrasyon kurulumu, test ve bakım emeğini içermiyor. Platform aboneliği, projenin faturasındaki en küçük kalemdir; büyük kalem her zaman insan emeğidir. Özel geliştirmeyle karşılaştırmak için mobil uygulama maliyet hesaplayıcısı ile kendi kapsamınıza göre bir aralık çıkarın; kalem kalem kırılımı mobil uygulama fiyatları yazısında topladık.

Sınır 1: Özel Entegrasyon ve Karmaşık Mantık

Platformların hazır konnektörleri, popüler servisler için harika çalışıyor. Sorun, listenin dışına çıktığınız anda başlıyor. Bubble'ın kendi blogunda no-code'un dezavantajlarını sıralarken kabul ettiği başlıklar arasında "eksik konnektörler" ve hazır entegrasyonlarda "yetersiz hata yönetimi" de var (Bubble blog).

Türkiye'de çalışan bir ürün için bu başlık fazlasıyla somut: e-fatura/e-arşiv akışı, yerli sanal POS sağlayıcıları, kargo firmalarının takip servisleri ve kurumsal muhasebe yazılımlarının API'leri hiçbir no-code platformun hazır entegrasyon listesinde yer almıyor. Bunları platformun genel API bağlayıcısıyla elle kurmanız gerekir: kimlik doğrulama başlıklarını, imzalı istekleri, hata kodlarını ve yeniden deneme mantığını kendiniz tanımlarsınız. Bu noktada aslında kod yazmıyorsunuz ama bir entegrasyon geliştiricisinin yaptığı işi, görsel bir arayüzün kısıtları içinde yapıyorsunuz. Entegrasyon mimarisinin neye benzediğini API entegrasyonu yazısında anlattık.

Somut bir örnek: Bubble'da bir e-arşiv faturası kesmek için API bağlayıcısında en az dört şeyi kendiniz kurarsınız — token alma çağrısı ve süresi dolan token'ın yenilenmesi, fatura gövdesinin servisin beklediği şemaya göre hazırlanması, servis 500 döndüğünde isteği kuyruğa alıp tekrar deneme ve faturanın karşı tarafta gerçekten oluştuğunu doğrulayan mutabakat kontrolü. Dördünü de görsel iş akışıyla kurmak mümkün; fakat hata ayıklama ekranınız bir geliştiricinin log kaydı kadar ayrıntı vermez. Pazaryerinden hazır bir eklenti kullandığınızda ise bakımı başkasının elindedir: servis sürüm değiştirdiğinde eklentinin ne zaman güncelleneceğine siz karar vermezsiniz.

İkinci darboğaz iş mantığı. Platformların iş akışı editörü, "koşul-aksiyon" zincirleri için tasarlandı. Dinamik fiyatlandırma, çok adımlı onay hiyerarşisi, stok rezervasyonunda eşzamanlılık kontrolü ya da özel bir eşleştirme algoritması gibi işler bu yapıya zorlanarak sığar. FlutterFlow'da custom action ve custom widget ile Dart kodu yazarak bu duvarı aşarsınız; ancak o andan itibaren hem platform aboneliğini hem geliştirici ücretini ödemeye başlarsınız. No-code uygulama ekonomisinin matematiği tam olarak burada çatlar.

Sınır 2: Performans ve Ölçeklenme

Bubble'da performansın para birimi workload unit. Platformun dokümantasyonu bunu şöyle tanımlıyor: "Workload represents the server resources needed to host, run, and scale apps built on Bubble." Sayfa yüklemeleri, iş akışları, aramalar ve toplu işlemler bu havuzdan harcar. Yani Bubble'da kötü kurulmuş bir arama, kullanıcı sayınız artmadan faturanızı büyütür; trafiğiniz arttığında ise plan limitine dayanırsınız.

Tüketimi düşürmek için üç pratik önlem işe yarar: listelerde her zaman sayfalama kullanın ve ekranda görünmeyen veriyi çekmeyin; tekrarlayan aramalar yerine ilişkisel alanlar üzerinden veriye gidin; periyodik arka plan iş akışlarını yalnız gerçekten gereken işlerle sınırlayın. Bu üç ayar aynı uygulamanın aylık tüketimini ciddi biçimde değiştirir ama no-code'un gizli maliyetini de gösterir: platformu ucuz kullanmak için platformun iç mekaniğini öğrenmeniz gerekir.

Bubble, kendi dezavantaj listesinde ölçeklenme ve performansı da açıkça sayıyor: trafik sıçramaları ve "veri ve iş akışı hacmi" gerçekçi yük altında yavaşlamaya yol açabiliyor. Aynı yazıda platformun doğru seçim olmadığı durumlar da listelenmiş: milisaniye hassasiyetli gerçek zamanlı işleme, özel donanım veya niş cihaz API'leri gerektiren ürünler ve kendi sunucunuzda (on-premises) çalışması gereken sistemler.

FlutterFlow tarafında arayüz performansı farklı bir noktada duruyor, çünkü çıktı derlenmiş Flutter kodudur. Fakat ölçeklenme sorunu bu kez arka uçta ortaya çıkar: Firebase ya da Supabase üzerinde kurduğunuz veri modeli, sorgu desenleri ve güvenlik kuralları performansın asıl kaynağıdır. Bir no-code uygulama hızlı başlar; yavaşladığında ise profil çıkarıp optimize edeceğiniz katman çoğu zaman platformun kapalı tarafında durur. Firebase'in ne zaman yeterli, ne zaman kendi sunucunuzun gerekli olduğunu ayrı bir yazıda değerlendirdik.

Mobil tarafta bir ayrıntıya daha dikkat edin: Bubble dokümanı, web içeriğini mobil ekrana gömmek için kullandığınız WebView elementi içinde konum, kamera ve push bildirim gibi yerel yeteneklerin çalışmayacağını söylüyor. Yani "web uygulamamı mobilde yeniden kullanırım" kısayolu, tam olarak cihaz özelliklerine ihtiyaç duyduğunuz yerde tükenir.

Sınır 3: Mağaza Politikaları

No-code uygulama projelerinin en sık takıldığı duvar teknik değil, editöryal. Apple'ın App Store İnceleme Kılavuzu'nun 4.2 maddesi uygulamanın "paketlenmiş bir web sitesinin ötesine geçen özellikler, içerik ve arayüz" içermesini şart koşuyor; 4.2.2 maddesi uygulamaların esas olarak pazarlama materyali, web kırpıntısı veya bağlantı koleksiyonu olmamasını istiyor. En kritik madde ise 4.2.6: "Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content" (App Store İnceleme Kılavuzu).

Bu madde, no-code platform kullanmanızı yasaklamıyor. Yasakladığı şey, bir ajansın ya da servisin aynı şablonu çoğaltıp müşterileri adına uygulama göndermesi. Kendi içeriğinizi kendi geliştirici hesabınızdan yayınlıyorsanız 4.2.6 sizi doğrudan etkilemez; ancak uygulamanızın şablon kokmayan, gerçek bir fayda sunan bir ürün olması gerekir.

Google Play tarafında kural daha somut yazılmış. İşlevsellik politikası, uygulamanın "stabil, duyarlı ve ilgi çekici" bir deneyim sunmasını istiyor; yalnızca metin veya PDF gösteren, uygulamaya özgü işlevi olmayan statik uygulamaları ve çok az içerikle ilgi çekici deneyim sunmayanları açıkça yasaklıyor (Google Play politikası).

Rakamlar bu eşiğin ne kadar ciddi olduğunu gösteriyor. Apple'ın 2025 App Store Şeffaflık Raporu'na göre şirket 9.100.620 başvuru inceledi ve 2.093.244'ünü geri çevirdi; yalnızca Design kategorisinde 415.532 red var (Apple). Apple ayrıca 2025'te 371 binden fazla başvuruyu başka uygulamaları kopyaladığı, spam olduğu ya da kullanıcıyı yanılttığı için geri çevirdiğini açıkladı. Yayına hazırlık adımlarını uygulama yayın kontrol listesi ile geçin; en sık görülen red gerekçelerini App Store uygulama reddi yazısında topladık.

Sınır 4: Veri Yerleşimi ve KVKK

Bir no-code uygulama kurduğunuzda kullanıcı verisi sizin sunucunuzda değil, platformun altyapısında durur. Bu durum KVKK kapsamında yurt dışına veri aktarımı sayılıyor ve 2024'ten beri aktarımın usulü değişti.

7499 sayılı Kanun'un 34. maddesi, 6698 sayılı Kanun'un "kişisel verilerin yurt dışına aktarılması" başlıklı 9. maddesini değiştirdi; "standart sözleşmeler" ve "bağlayıcı şirket kuralları" artık yurt dışına aktarımda başvurabileceğiniz uygun güvence yöntemleri arasında. Kişisel Verileri Koruma Kurulu, 4/6/2024 tarihli ve 2024/959 sayılı kararıyla kullanılacak standart sözleşme metinlerini ve bağlayıcı şirket kuralları başvuru formlarını kabul etti ve Kurum'un sitesinde yayımladı (KVKK duyurusu). Kurul, 17.10.2024 tarihli kararıyla bildirimler için çevrimiçi bir modül de açtı.

Pratikte bu, platform seçiminizin hukuk departmanınızı da ilgilendirdiği anlamına geliyor: aydınlatma metninizde aktarımı belirtmek, işleme envanterinizi güncellemek ve platformla standart sözleşmeyi imzalayıp Kurum'a bildirmek sizin yükümlülüğünüz. Barındırma konumunu seçme imkânı ise çoğu planda yok; Bubble'ın fiyat sayfası "choice of hosting location" seçeneğini yalnız Enterprise planında listeliyor. Bubble kendi dezavantaj yazısında da veri yerleşimi ve gizlilik kurallarındaki kısıtları bir risk başlığı olarak sayıyor. Web tarafındaki yükümlülükler için web sitesi ve KVKK yazısına bakın.

Sınır 5: Güvenlik ve Yönetişim

Görsel editör, güvenlik kararlarını ortadan kaldırmıyor; yalnızca onları alan kişiyi değiştiriyor. OWASP'ın bu alana ayırdığı proje adını bile güncelledi: bugün "OWASP Citizen Development Top 10" olarak yayımlanan liste, no-code platformlar, yapay zekâ destekli kodlama ve yapay zekâ ajanlarıyla üretilen yazılımların risklerini birlikte ele alıyor (OWASP).

Listedeki ilk dört madde, no-code uygulama projelerinde en çok karşılaştığımız hataların tam karşılığı: CD-SEC-01 Blind Trust (platformun varsayılanlarına sorgusuz güvenmek), CD-SEC-02 Account Impersonation (uygulamanın kurucusunun kimliğiyle çalışan akışlar), CD-SEC-03 Authorization Misuse (yetki kontrollerinin arayüz katmanında bırakılması) ve CD-SEC-04 Sensitive Data Leakage and Handling Failures. Dokuzuncu madde, CD-SEC-09 Asset Management Failures, kurumsal tarafın en büyük derdini anlatıyor: kimsenin envanterinde olmayan, ayrılmış bir çalışanın hesabına bağlı, hâlâ canlı veri işleyen uygulamalar.

Bubble'ın dezavantaj listesinde de kimlik bilgilerinin açığa çıkma riski, uygulama çoğalması, bilgi silolaşması ve ölçekte hafife alınan fiyatlandırma yer alıyor. Bu yüzden bir no-code uygulama yayına çıkmadan önce üç şeyi yazılı hale getirin: hangi veri alanlarını kim görebilir, kayıt düzeyinde kural kim tarafından test edildi, platform hesabının sahibi hangi kurumsal e-posta. Mobil tarafta kontrol listesinin tamamını mobil uygulama güvenliği yazısında topladık.

Sınır 6: Platform Riski

Platformun kendisi de bir bağımlılıktır. 2026'da bunun en net örneği Bildr oldu: platform kapandı ve ana sayfasında "Bildr was built on a belief that creating software shouldn't require knowing how to write code. That world is arriving, and even though it won't be with Bildr..." cümlesiyle veda etti (Bildr). Satın almalar da aynı sonucu doğuruyor; Airtable, bünyesine kattığı Dopt'un 15 Ağustos 2024'te kapatılacağını duyurmuştu (Airtable).

Bu, bir platformu kullanmamak için gerekçe değil. Gerekçe olduğu şey hazırlıksız kullanmamak. Bubble, platformdan ayrılmak isteyenlere uygulama mantığı ve görsel tasarımının JSON dökümünü verebildiğini söylüyor; bu, dönüşümü hızlandıran bir doküman ama çalışan bir uygulama değil. Dolayısıyla bir no-code uygulama ile yola çıkarken şu üç şeyi baştan planlayın: verinizin düzenli yedeği, iş kurallarının platform dışında yazılı bir kopyası ve platform kapanırsa hangi mimariye geçeceğinizin kaba planı.

Kurumsal tarafta bu planı bir sayfaya indirin: hangi veri kümesi hangi sıklıkta nereye yedekleniyor, hesabın sahibi hangi kurumsal e-posta, platform bir yıl içinde kapanırsa hangi ekip hangi mimariye geçiyor ve bunun kaba bütçesi ne. Tedarikçi değerlendirme süreci olan şirketlerde bu tek sayfa, no-code uygulama tercihini savunulabilir bir karara dönüştürür; olmadığında ise platform kararı, kimsenin sahiplenmediği bir risk olarak şirketin üzerinde durur.

Platformdan Çıkış: Özel Koda Geçiş Yol Haritası

İyi haber: no-code uygulama ile başlayıp özel yazılıma geçmek başarısızlık değil, olgunlaşma. Kötü haber: bunu plansız yapan ekipler aynı ürünü iki kez ödüyor. Sırası önemli bir yol haritası:

1. Veriyi önce çıkarın. Bubble, kullanıcı verisini Excel uyumlu CSV olarak dışa aktarmanıza ve tek tıkla oluşturduğunuz REST API üzerinden erişmenize izin veriyor. Taşımanın ilk adımı her zaman veri modelinin dökümüdür.
2. Platformdan mantık dökümünü isteyin. Bubble'ın verdiği JSON dökümü, iş akışlarını yeni mimariye çevirirken şartname yerine geçer.
3. İş kurallarını insan diliyle yazın. Hangi durumda hangi bildirim gidiyor, hangi alan zorunlu, hangi rol neyi görüyor. Bu belge olmadan yeniden yazım tahmine dönüşür.
4. FlutterFlow kullanıyorsanız kodu alın. Ücretli planlar Flutter projesini indirmenize ya da GitHub'a aktarmanıza izin verir. Dokümantasyonun uyarısını atlamayın: "FlutterFlow always pushes changes to a branch named flutterflow" ve "Avoid making direct changes to this branch, as your changes will be overwritten by the next push from FlutterFlow" (FlutterFlow dokümantasyonu). Yani akış tek yönlüdür; el yazısı kodunuz ayrı bir dalda yaşamalıdır.
5. Lisansları kontrol edin. FlutterFlow, ürettiği yardımcı kütüphanelerin MIT veya BSD-3-Clause gibi izin veren lisanslara uyduğunu, ancak üçüncü taraf Flutter paketlerinin lisanslarının değişebileceğini yazıyor.
6. Arka ucu önce bağımsızlaştırın. Çoğu ekip için en düşük riskli sıra, önce API ve veritabanını kendi altyapısına taşımak, arayüzü sonra devretmektir.
7. Paralel çalıştırın. Eski uygulama canlıyken yeni sürümü sınırlı kullanıcı grubuyla açın, veriyi iki yönlü senkronize edin, sonra anahtarı çevirin.
8. Sözleşmeye kaynak kod ve depo devrini yazın. Yeni geliştirme bir ajansla yürüyorsa depo sahipliği ve teslim koşulları ilk günden sözleşmede yer almalı. Bizim bu konudaki yaklaşımımızı özel yazılım geliştirme yazısında anlattık.

No-Code mu, Özel Yazılım mı?

Kararı platformun yetenek listesi değil, ürünün önümüzdeki 24 ayda nereye gideceği şekillendirir.

No-code uygulama mantıklı olduğu durumlar: fikrin talep görüp görmediğini test edeceğiniz ilk sürüm; iç ekiplerin kullandığı form, onay ve raporlama araçları; tek bir departmanın sürecini dijitalleştiren uygulamalar; bir kampanya süresince yaşayacak ürünler; teknik ekibi olmayan şirketlerin ilk dijital adımı.

Özel yazılımın gerektiği durumlar: ürünün rekabet avantajı bir algoritmada ya da özgün bir iş akışındaysa; Türkiye'ye özgü zorunlu entegrasyonlar (e-fatura, yerli ödeme altyapıları, kurumsal ERP) akışın merkezindeyse; verinin nerede durduğu mevzuatla sınırlıysa; cihaz donanımını derinlemesine kullanıyorsanız; ya da uygulama şirketin ana gelir kanalıysa. Bubble'ın kendi ifadesiyle milisaniye hassasiyetli işleme, özel donanım ve on-premises kurulum bu platformların dışında kalıyor.

Arada kalan ekipler için üçüncü bir yol da var: ürünün çekirdeğini özel kodla kurup, yan süreçleri (iç araçlar, operasyon panelleri) no-code platformda bırakmak. Mobil uygulama geliştirme projelerinde bu melez kurulumu sık sık öneriyoruz, çünkü bütçenin tamamını tek mimariye yatırmak zorunda değilsiniz.

Hibrit kurulumun maliyet tarafı da nettir: iç araçları Adalo Professional ya da Bubble Starter seviyesinde tutarsanız yıllık platform gideriniz dört haneli dolarda durur, özel kod bütçesini de yalnız gelir getiren çekirdeğe ayırırsınız. Büyüme geldiğinde taşınacak yüzey küçülür, çünkü platformda yalnız operasyonel akışlar durur. Bu yaklaşımın bir yan faydası daha var: ekip, iş kurallarını görsel editörde yazarken zaten belgelemiş olur, bu da özel koda geçişte şartname işini kolaylaştırır.

Sıkça Sorulan Sorular

No-code uygulama gerçekten kod yazmadan bitiyor mu?

Basit uygulamalarda evet. Özel entegrasyon, özgün iş mantığı ya da ince ayar gerektiren arayüzlerde platformlar "custom code" kapısı açar ve o kapıdan itibaren bir geliştiriciye ihtiyaç duyarsınız. Pratikte kodsuz başlayan projelerin çoğu, yayına kadar en az bir kez kod yazar.

FlutterFlow ile yaptığım uygulamanın kodu bana mı ait?

FlutterFlow dokümantasyonu "you own the output of your work" diyor ve ücretli planlarda Flutter projesini indirmenize izin veriyor. Kod indirme 39 dolarlık Basic planda, GitHub entegrasyonu Growth planında açılıyor. Yani sahiplik var, erişim ise aboneliğe bağlı.

Bubble uygulamasının kodunu dışa aktarmak mümkün mü?

Hayır. Bubble'ın kendi destek makalesi uygulamaların geleneksel anlamda kod olarak var olmadığını ve yalnızca Bubble platformunda çalışabildiğini belirtiyor. Verinizi CSV ve API ile dışa aktarın; platformdan ayrılırken uygulama mantığının JSON dökümünü talep edin.

No-code uygulama App Store incelemesinden geçer mi?

Geçer, ancak uygulamanın paketlenmiş bir web sitesinden fazlasını sunması şart. Apple'ın 4.2.6 maddesi ticarileştirilmiş şablon veya uygulama üretme servisinden çıkan uygulamaları, içerik sahibi kendisi göndermediği sürece reddediyor. Kendi hesabınızdan yayınlanan özgün bir ürün bu maddenin dışındadır.

Kaç kullanıcıya kadar no-code platform yeterli?

Tek bir kullanıcı sayısı yok; Bubble'da sınır workload unit tüketiminizdir. Ücretsiz planda aylık 50 bin, Starter'da 175 bin, Growth'ta 250 bin unit var. Ağır sorgular, kullanıcı sayınız artmadan limiti tüketir; bu yüzden ölçüyü trafik değil, iş akışı verimliliği şekillendirir.

No-code'dan özel koda geçiş ne kadar sürer?

Süreyi veri modelinin ve entegrasyonların karmaşıklığı tayin eder. Arayüzü çoğunlukla sıfırdan yazarsınız; asıl iş, iş kurallarını eksiksiz çıkarmak ve veriyi kayıpsız taşımaktır. Bu yüzden geçişi tek seferlik bir göç değil, paralel çalışan iki sürümle yönetilen bir süreç olarak planlayın.

KVKK açısından no-code platform kullanmak uygun mu?

Uygun, fakat yükümlülük sizde. Veri yurt dışındaki bir altyapıda işlendiği için KVKK'nın 9. maddesi kapsamında standart sözleşme gibi bir uygun güvence yöntemine dayanmanız, aydınlatma metninizde aktarımı açıklamanız ve bildirim yükümlülüğünüzü yerine getirmeniz şart.

No-code uygulama platformları, 2026'da bir ürünü yayına çıkarmanın en hızlı yolu. FlutterFlow kaynak kodu verdiği için çıkış kapısını açık bırakıyor; Bubble ve Adalo hız karşılığında sizi kendi altyapısında tutuyor. Bu bir "iyi platform, kötü platform" tartışması değil; ürününüzün ömrü, veri yükümlülükleriniz ve büyüme hedefinizle ilgili bir tercih.

Önerimiz basit: ilk sürümü en hızlı çıkaracağınız araçla çıkarın, ama ilk günden veri yedeğinizi, iş kurallarının yazılı kopyasını ve çıkış planınızı hazır tutun. Projenizin hangi aşamada no-code ile devam edip hangi aşamada özel yazılıma geçmesi gerektiğini birlikte değerlendirmek isterseniz bize ulaşın — mevcut kurulumunuzu inceleyip ölçeklenebilir bir yol haritası çıkarıyoruz.