Low-code platform kararı, özellik listesiyle değil tavanla verilir. Her platformun yayımlanmış bir kotası var ve projeniz o kotanın neresine düştüğünü bilmeden verilen "10 kat hızlı" sözü, altıncı ayda gelen faturayı ya da kısıtlanmış bir uygulamayı açıklamıyor.
Aşağıda iki platformun kendi dokümanından çıkan gerçek sayılarla hesap yapıyoruz: Microsoft Power Platform'un 24 saatlik istek limitleri ve Bubble'ın iş yükü birimi (workload unit) fiyatlaması. İkisi de birbirinden çok farklı iki tavan modeli, ve hangisini seçeceğiniz uygulamanızın şekline bağlı.
Power Platform: kota istek sayısı, ve gün sonunda sıfırlanmıyor
Power Apps ve Power Automate tarafında ölçü birimi "Power Platform isteği". Bu, konnektörlere ve Dataverse'e yapılan her API çağrısını kapsıyor; Power Automate tarafında başarısız aksiyonlar, yeniden denemeler ve sayfalama çağrıları da sayılıyor (bkz. Microsoft Learn, Requests limits and allocations).
Lisans başına 24 saatlik limitler:
| Lisans | 24 saatte istek |
|---|---|
| Ücretli Power Platform kullanıcı lisansları ve Dynamics 365 (Team Member hariç) | 40.000 |
| Power Apps per app, pay-as-you-go, Power Platform erişimi olan Microsoft 365 lisansları, D365 Team Member | 6.000 |
| Power Automate per flow / Process lisansı, Copilot Studio | 250.000 |
| Ücretli Power Apps Portals oturum açma | 200 |
Tablodaki en önemli satır ikincisi. Kurumların çoğu ilk Power Apps uygulamasını mevcut Microsoft 365 lisanslarıyla yapıyor, ve o yoldan gelen kullanıcının günlük bütçesi 6.000 istek. Dataverse üzerinde çalışan orta karmaşıklıkta bir ekranın tek açılışta 20-30 okuma yapması olağan; bu da kabaca günde 200 ekran geçişi demek. Sahada kullanılan bir iş uygulaması için bu tavan alçak.
Dördüncü satır ise müşteri portalı planlarını doğrudan vuruyor: portal oturum açma limiti günde 200.
Kotalar devretmiyor. Microsoft'un kendi ifadesi: istekler 24 saatlik bir pencere için var, kullanılmazsa ertesi güne aktarılmıyor ve ay içinde birikmiyor. Yani "ayda toplam şu kadar işlem yapıyoruz" hesabı yanlış hesap; doğru soru en yoğun günün yükü.
Beş dakikalık sınır, günlük limitten önce vurur
Az bilinen ikinci tavan: beş dakikalık pencere için 100.000 istek, ve bu sınır lisanstan bağımsız. Process lisanslı bir akış günde 250.000 istek yapabiliyor ama beş dakikada 100.000'i aşamıyor.
Bu, gece çalışan toplu veri aktarımlarını tasarlarken belirleyici. Elli bin kayıtlık bir senkronizasyonu tek seferde sürmek yerine pencereye yayın; aksi hâlde işi bitirmiyorsunuz, kısıtlanıyorsunuz.
Tek bir akış için kapasite eklemenin yolu da belgede net: kullanıcıya atanan ek paketler bir akışa atanamıyor. Akışa Process lisansı vereceksiniz (akış başına 250.000 istek), ve gerekiyorsa aynı akışa en fazla 10 Process lisansı yığarak 2,5 milyona çıkarabiliyorsunuz. Alternatif olarak bir flow group içindeki en fazla 25 akış 250.000'i paylaşıyor; alt akışlar üst akıştan kapasite miras almıyor, gruba ayrı ayrı eklenmeleri gerekiyor.
Arka plan işleri için üçüncü bir havuz var: uygulama kullanıcıları, etkileşimsiz kullanıcılar ve sistem kimlikleri kiracı düzeyinde ortak bir havuz kullanıyor. Power Apps ve Power Automate için bu havuz günde 25.000 istek ve lisans başına artmıyor. Entegrasyon işlerini bir servis kimliği üzerinden koşturmayı planlıyorsanız tavanınız burası.
Bubble: kota istek değil, iş yükü
Bubble tamamen farklı bir model kullanıyor. Ölçü birimi workload unit (WU) ve fiyatlama tüketime bağlı. Yayımlanmış başlangıç maliyetleri şunlar (bkz. Bubble Docs, The workload calculation):
- Veritabanına yazılan veya değiştirilen her kayıt: 0,5 WU
- Do a search for ile arama: 0,3 WU giriş maliyeti
- Toplu sorgu (aggregate): 0,2 WU giriş maliyeti
- Veritabanından dönen veri: karakter başına 0,000003 WU
Bubble bu sayıların başlangıç maliyeti olduğunu, işlemin karmaşıklığının nihai değeri belirlediğini açıkça yazıyor. Yani aşağıdaki hesaplar taban, tavan değil.
Somut bir örnek: her gece 50.000 kaydı güncelleyen tek bir arka plan işiniz var. Yalnızca yazma maliyeti 50.000 × 0,5 = 25.000 WU. Ayda 30 gün, 750.000 WU. Plan kotanızın üzerine çıkarsanız aşım ücreti 1.000 WU başına 0,30 USD; bu tek iş için ayda 225 USD ek maliyet demek (bkz. Bubble Docs, Pricing FAQ).
Plan bandı kendisi 32-649 USD arasında değişiyor (web, mobil veya ikisi birden). Ücretli uygulamalarda Development ortamı için ayrıca aylık 100.000 WU dâhil.
Okuma tarafı için de kaba bir formül çıkarılabilir: bir liste sayfası tek arama (0,3 WU) yapıp 100.000 karakterlik veri döndürüyorsa (0,3 WU), sayfa görüntüleme başına yaklaşık 0,6 WU. Ayda 100.000 görüntüleme 60.000 WU. Yani Bubble'da pahalı olan şey okuma değil, toplu yazma.
İki model, iki farklı proje şekli
Bu iki tavan modeli, hangi platformun hangi projeye uyduğunu doğrudan söylüyor.
| Projenin şekli | Nereye gider | Neden |
|---|---|---|
| Az sayıda iç kullanıcı, yoğun kullanım, Microsoft 365 zaten var | Power Platform, ama kullanıcı başı lisans ile | 6.000'lik seeded limit yoğun kullanımda yetmiyor |
| Çok sayıda dış kullanıcı, hafif kullanım | Bubble veya özel geliştirme | Portal oturum açma limiti günde 200 |
| Gecelik toplu veri işleme ağırlıklı | Hiçbiri; özel geliştirme | İkisinde de toplu yazma doğrudan faturaya yazılıyor |
| Kısa ömürlü kampanya aracı, form, onay akışı | Low-code, tereddütsüz | Yaşam süresi tavana ulaşmadan bitiyor |
Geçiş dönemi tuzağı: bugün ölçtüğünüz limit yarınki limit değil
Power Automate tarafında şu an tüm kuruluşlar bir geçiş döneminde. Bu dönemde Premium ve seeded lisans limitleri kullanıcı başına değil, bulut akışı başına uygulanıyor: Premium için akış başına 200.000, Office 365 için akış başına 10.000. Geçiş bittiğinde uygulama kullanıcı başına limite (sırasıyla 40.000 ve 6.000) dönüyor.
Pratik sonucu şu: bugün akış başına ölçüp "sığıyoruz" diyen bir kapasite planı, geçiş bittiğinde geçersiz olacak. Microsoft'un kendi tavsiyesi de bu yönde, akışlarınızı geçiş sonrası kullanıcı başına limitlere göre tasarlayın. Kapasite planınızı bugünün rakamıyla imzalamayın.
Ne zaman kod yazmak daha ucuz
Low-code kararını maliyet tarafında dürüst kurmanın yolu, tekrarlayan maliyeti tek seferlik maliyetle karşılaştırmak. Kendi teklif bandımız adam-gün başına 300-400 USD (bkz. ininia proje fiyat hesaplama). Yani 20 günlük bir iç araç 6.000-8.000 USD tek seferlik maliyet demek.
Karşısına koyacağınız sayı, platformun yıllık toplam maliyeti artı tavan aşımında ödeyeceğiniz ek paketler. Bubble örneğindeki tek gecelik iş bile yılda 2.700 USD'ye çıkıyordu. İki eğri kesiştiği anda karar teknik olmaktan çıkıp aritmetik hâline geliyor.
Buna rağmen üç durumda low-code hâlâ doğru cevap, ve bunlar maliyetle ilgili değil:
- Talebin doğrulanmadığı durumda. Bir iş biriminin gerçekten kullanıp kullanmayacağını bilmiyorsanız, iki haftalık bir low-code sürümü en ucuz araştırmadır.
- Sahipliğin IT'de olmadığı durumda. Kuralları haftada bir değişen bir onay akışını iş birimi kendisi değiştirebiliyorsa, bakım maliyeti sıfıra yaklaşıyor.
- Ömrü belli olan araçlarda. Altı ay sürecek bir geçiş dönemi aracı için mimari kararı vermek zaman kaybı.
Hesap tablosuna girmeyen iki kalem: kur ve çıkış
Yukarıdaki kesişim hesabı iki kalemi atlıyor, ikisi de Türkiye'de faturayı belirliyor.
Birincisi kur. Power Platform ve Bubble abonelikleri dövizle fiyatlanıyor, uygulamanın ürettiği fayda TL cinsinden ölçülüyor. Tek seferlik geliştirme bedeli sözleşmeyle sabitlenebilir; abonelik sabitlenemez. Karşılaştırmayı bugünkü kurla değil, taahhüt süresi boyunca ödeyeceğiniz toplam döviz tutarıyla yapın.
İkincisi çıkış. Low-code'da ürettiğiniz şey bir kaynak kod deposu değil, platformun kendi nesneleri; dışa aktarma menüsü olsa bile çıktısı başka bir yığında derlenmiyor. Platformdan ayrılmayı bu yüzden "geçiş" kalemi olarak değil, yeniden geliştirme kalemi olarak bütçeleyin.
Karar kuralı: çıkış maliyetini bilerek kabul edin, ya da o süreci baştan koda alın. Belirsiz bırakıldığında bu karar ikinci yılda ve kötü koşulda veriliyor.
Sözleşme imzalamadan önce ölçülecek üç şey
Pilotu başlatmadan bu üç sayıyı çıkarın; üçü de platformun kendi panelinden okunuyor ve üçü de sonradan sürpriz üretiyor:
- En yoğun günün istek sayısı (ay toplamı değil). Power Platform tarafında Power Platform admin center'daki Licensing bölümünden kullanıcı bazlı rapor indirilebiliyor.
- Tek bir tipik ekranın kaç çağrı ürettiği. Bu sayı, kullanıcı başına günlük ekran geçişi tavanınızı doğrudan veriyor.
- Toplu işlerin kayıt sayısı. Bubble'da 0,5 WU, Power Platform'da her CRUD bir istek; ikisinde de en büyük kalem burası.
Pilotun kabul kriterine "uygulama çalışıyor" yerine "en yoğun günde kota aşılmadı" yazın. Birincisi ikinci ayda, ikincisi altıncı ayda ölçülüyor.
Sırada ne var
Elinizdeki fikri iki sütuna ayırın: kaç kullanıcı ve ne sıklıkla yazma. Kullanıcı sayısı büyük ve yazma seyrekse low-code ekonomik; kullanıcı sayısı küçük ama yazma yoğunsa kod yazmak daha ucuza geliyor. Bu iki sayıyı bilmeden alınan platform kararı, ilk faturada yeniden alınıyor.
İş süreçleri otomasyonunun low-code dışındaki yolu için RPA ile iş süreçleri otomasyonu yazısına, müşteri verisi tarafı için CRM kurulum ve entegrasyon yazısına bakabilirsiniz. Kendi senaryonuzda tavan hesabı çıkarmak isterseniz iletişim sayfası üzerinden yazın.
Bilgiler 25 Eylül 2026 tarihinde doğrulanmıştır: Microsoft Learn, "Requests limits and allocations - Power Platform" (lisans başına 24 saatlik limitler, beş dakikalık 100.000 sınırı, lisanssız kimlik havuzu, Process lisansı ve flow group kuralları, geçiş dönemi tablosu); Bubble Docs, "The workload calculation" ve "FAQ: Pricing and Workload" (WU birim maliyetleri, aşım fiyatı, Development ortamı kotası). Microsoft lisans fiyatları birincil kaynaktan doğrulanamadığı için bu yazıda fiyat verilmemiştir. Adam-gün bandı ininia'nın kendi teklif motorundaki değerlerdir.
