Mobil uygulama maliyeti: kalem kalem model ve teklif karşılaştırma şablonu

Maliyeti belirleyen altı faktör

Mobil uygulama maliyeti tek bir sayı değil, bir kalem listesidir; kalemlerin payı da projeye göre değişir. Altı faktör, listenin hangi satırlarının uzayıp kısalacağını belirler. Mobil uygulama yaptırma sayfamızdaki fiyat tablosu faktörleri özetliyor; burada her birinin içine bakıyoruz.

1. Ekran ve akış sayısı, ama daha çok durum sayısı. Bir ekran tek bir iş değildir: aynı ekranın boş, yükleniyor, hata, yetkisiz ve bağlantısız halleri vardır ve her biri tasarım, geliştirme ve test demektir. İki teklifin ekran sayısı aynı olup içerdikleri iş çok farklı olabilir. Çok dilli arayüz, karanlık tema ve erişilebilirlik gibi gereksinimler her ekranın yükünü çoğaltır. Sorun: "Ekran listesi yazılı mı, durumları da sayılmış mı?"
2. Arka uç ve yönetim paneli. Uygulamaların çoğu bir sunucuya ihtiyaç duyar: kullanıcı hesabı, veri, bildirim, ödeme doğrulaması. Yönetim paneli, yani içeriği, kullanıcıları ya da siparişleri yönetecek ekran, ayrı bir ürün kadar iştir. Teklifte yalnızca "mobil uygulama" yazıyorsa ilk soru şudur: arka uç ve panel dahil mi? Sorun: "Veriyi kim, hangi ekrandan yönetecek?"
3. Özellik türü. Bir özelliğin yükü ekran sayısıyla orantılı değildir. Ödeme ve abonelik mağaza kurallarını ve sağlayıcı entegrasyonunu getirir, konum arka plan izinlerini, sohbet gerçek zamanlı altyapıyı, çevrimdışı çalışma ise senkronizasyon çakışmalarını. En çok belirsizlik taşıyan özellikler genellikle çevrimdışı ve gerçek zamanlı olanlardır. Sorun: "Hangi özellik ilk sürümde gerçekten şart?"
4. Üçüncü taraf entegrasyonlar. Her entegrasyon, karşı tarafın belge kalitesine, test ortamına, hız sınırlarına ve hata davranışına bağlıdır. Mevcut sistemlerinizle (stok, muhasebe, müşteri kaydı) bağlantı ayrı bir iş kalemidir. Sorun: "Hangi dış sistemler kapsamda, hangileri sizin tarafınızda kalıyor?"
5. Platform ve teknoloji seçimi. iOS, Android ya da ikisi; tek kod tabanı ya da ayrı. Seçim yalnızca ilk geliştirme maliyetini değil, bakım yükünü de belirler. Karşılaştırma ölçütleri mobil uygulama yaptırma sayfamızda. Sorun: "Seçimin gerekçesi teklifte yazılı mı?"
6. Tasarım derinliği, test, yayın ve bakım. Markaya özel bir tasarım sistemi ile platformun standart bileşenleri arasında tasarım ve test yükü farkı olur. Test, cihaz ve işletim sistemi çeşitliliğiyle büyür. Yayın, mağaza hazırlığı ve incelemeyi, bakım ise işletim sistemi güncellemelerini içerir. Sorun: "Yayından sonraki ilk dönemde kim, neyi düzeltir?"

Kalem kalem maliyet modeli

Aşağıdaki tablo bir teklifte görmeniz gereken on kalemi, her birinin nasıl görünmesi gerektiğini ve atlanmaması için sorulacak soruyu gösteriyor. Tabloda bilerek ağırlık, yüzde ya da TL yok: kalemlerin payı projeden projeye değişir ve bu yazı, dayanağı olmayan bir oran vermemeyi tercih ediyor.

Tablonun sağ sütunu, yazılım teklifi okuma yazımızdaki kırmızı bayrak mantığıyla birlikte kullanılabilir: yanıtı yazılı olmayan her satır, teklifin dışında kalmış bir maliyet olabilir.

Mağaza kuralları da bir maliyet kalemidir

Mağazaların koyduğu kurallar, ekran listesinde görünmeyen ama emek isteyen işler doğurur. Resmî sayfalardan üç örnek:

• Gizlilik beyanı. Apple, her uygulamanın hangi veri türlerini topladığını, bunların kullanıcıya bağlı olup olmadığını ve izleme için kullanılıp kullanılmadığını App Store Connect'te beyan etmesini ister; uygulamadaki üçüncü taraf kod (analitik, reklam ağı, SDK) da kapsama girer (Apple). Google Play'in Veri güvenliği bölümü yayınlanmış tüm uygulamalar için zorunludur; veri toplamayan uygulamalar da formu doldurup bir gizlilik politikası bağlantısı vermek zorundadır, üçüncü taraf kütüphanelerin topladığı veri de beyana girer ve beyanın doğruluğundan geliştirici sorumludur (Google). Bu hem bir yazı işi hem bir mühendislik işidir: uygulamanın gerçekte ne topladığını bilmek gerekir.
• Hesap silme. Apple'ın inceleme yönergesine göre hesap oluşturmayı destekleyen bir uygulama, hesap silmeyi de uygulama içinde sunmalıdır (5.1.1(v)) (Apple). Google Play, hesap oluşturan uygulamalardan uygulama içinde bir silme yolu ve ayrıca uygulama kaldırılmış olsa bile silme talebi alınabilen bir web sayfası ister (Google). Hesap silme akışı arka uçta bir iş kalemidir; teklifte yoksa sonradan ek iş olarak çıkar.
• Gizlilik politikası bağlantısı. Apple, tüm uygulamaların gizlilik politikasına App Store Connect'te ve uygulama içinde kolay ulaşılabilir bir bağlantı vermesini ister (Apple).

Bunların hiçbiri bir "özellik" değildir; ama mağaza kuralı oldukları için incelemede karşınıza çıkabilir. Teklifteki "mağaza hazırlığı" satırının bunları kapsayıp kapsamadığını sorun.

Teklifin dışında kalan sürekli giderler

Mobil uygulama maliyeti geliştirme teklifiyle bitmez. Aşağıdaki giderler genellikle teklifin dışında kalır ve doğrudan sağlayıcıya ödenir. Tutarlar resmî sayfalardan, okunma tarihiyle alınmıştır; zamanla değişir, karar vermeden önce sayfaları yeniden açın.

İşletim sistemi satırı özellikle önemlidir: bir uygulama yayınlandığı gün bitmez. Mağazaların gereksinimleri her yıl yükselir ve bu, yeni bir özellik eklemeseniz bile mühendislik emeği demektir. Teklifteki bakım kalemi bunu karşılıyor mu, yoksa ayrı mı ücretlendiriliyor, sorun.

Yıllık işletme bütçesi nasıl çıkarılır?

Sürekli giderleri üç türe ayırmak bütçeyi kolaylaştırır.

Yıllık işletme gideri kabaca şudur: sabit giderler artı birim fiyat çarpı beklenen kullanım artı bakım emeği. Beklenen kullanımı kestiremiyorsanız tahmini büyütmeyin; sağlayıcı konsolunda bir üst sınır tanımlayın.

Teklifler neden birbirinden bu kadar farklı çıkar?

Üç teklifin fiyatı çok farklıysa, nedeni üç teklifin üç farklı işi fiyatlaması olabilir; kötü niyet gerekmez. Kapsam yazılı değilse her teklif veren boşlukları kendi varsayımıyla doldurur. Kurgusal bir örnek (rakam yok): aynı "mobil uygulama" isteğine üç teklif geliyor.

Böyle bir tabloda Teklif A'nın fiyatının diğerlerinden düşük çıkması şaşırtıcı olmaz: Android, arka uç, yayın ve bakım sizin üstünüzde kalmıştır. "Aynı kapsamı varsayın" demek, tabloyu bu şekilde doldurup her teklife eksik satırları eklemek, sonra fiyatları karşılaştırmaktır.

Teklif karşılaştırma şablonu

Aşağıdaki boş tabloyu kopyalayın, her teklif için doldurun ve boş kalan hücreleri teklif sahibine yazılı soru olarak gönderin. Hücrelere "yazılı", "sözlü" ya da "yok" yazın; "sözlü" ve "yok" hücreleri fiyat satırından daha çok şey anlatır. Sözleşme ve kapsam belgesi odaklı sorular için yazılım teklifi nasıl okunur yazısındaki tabloya da bakın.

Fiyatın en altta olması bilerek yapılmıştır: önce neyi aldığınızı, sonra ne kadara aldığınızı karşılaştırın.

Teklif sahiplerine gönderebileceğiniz bir mesaj taslağı:

Teklifiniz için teşekkürler. Teklifleri aynı kapsam üzerinden karşılaştırabilmek için aşağıdaki başlıkların yazılı yanıtını rica ediyorum: kapsam ve ekran listesi (durumlarıyla), platform ve teknik yol ile gerekçesi, arka uç ve yönetim paneli, entegrasyonlar, mağaza hesabının kimin adına açılacağı, kaynak kod mülkiyeti, takvim ve kilometre taşları, revizyon sınırı, test ve kabul ölçütü, yayın desteği, bakım süresi ve kapsamı, KDV durumu ve ödeme planı. Yanıtları teklifin bir parçası olarak e-postayla iletmenizi rica ederim.

Hazır araç, serbest çalışan, ajans

Hazır araç, serbest çalışan, yazılım stüdyosu ve kendi ekibiniz arasındaki karşılaştırmayı mobil uygulama yaptırma sayfamızda yaptık ve burada tekrarlamıyoruz. Maliyet açısından tek ek not şu: her seçenekte farklı kalemler sizin üstünüzde kalır. Hazır araçta abonelik bittiğinde uygulamaya ve veriye ne olacağını, serbest çalışanda hangi kalemlerin tek kişiye bağlı olduğunu ve bıraktığında ne olacağını, stüdyoda ise kapsamın yazılı olup olmadığını ve kodu kimin yazdığını sorun. Hazır bir araç işinizi görüyorsa bunu açıkça söyleriz.

Maliyeti düşürmenin dürüst yolları

1. Kapsamı kesin. Tek ana akışla başlayın; her özelliği şimdi, sonra ya da hiç kutularından birine koyun. Yöntemi MVP geliştirme sayfamızda anlattık. Kapsam kesmek, maliyetin ve takvimin en güçlü aracıdır.
2. Önce bir platformla başlayın. Hangi platformla başlayacağınız, kullanıcılarınızın hangi cihazları kullandığına bağlıdır. İki platformu birlikte ya da sırayla yapmak tekliflerde ayrı kalemler olmalıdır; birini sonraya bırakmak ilk sürümün yükünü azaltır.
3. Hazır servisleri değerlendirin. Kimlik doğrulama, ödeme, bildirim ve harita gibi alanlarda hazır servis, sıfırdan yazmaktan hızlı olabilir. Karşılığında bağımlılık ve kullanım ücreti gelir; ayrılırsanız taşıyabilir misiniz, sorun.
4. İlk sürümde standart bileşenlerle başlayın. Özel animasyonlar ve markaya özgü bileşenler tasarım ve test yükünü artırır; bunları ilk sürümden sonraya bırakmak çoğu zaman mümkündür.
5. İlk sürümü ölçerek büyütün. İkinci kapsam kararını, ilk sürümden öğrendiklerinize göre verin.
6. Sürekli giderleri baştan planlayın. Yukarıdaki tablo bir bütçe satırıdır; yayınlandıktan sonra sürpriz olması gerekmez.
7. Yarım kalmış bir uygulamanız varsa, önce denetleyin. Baştan yazma ya da devam etme kararını varsayıma değil denetime dayandırın; yöntem yarım kalmış yazılım projesi devralma yazısında.

Biz teklifi nasıl yazıyoruz

Burada yalnızca sitemizde yazdığımızı tekrarlıyoruz. Kapsam, takvim ve maliyet iş başlamadan yazılı teklifte yer alır; siz onaylamadan iş başlamaz ve kapsam yazılı onaylandıktan sonra fiyat değişmez. Mağaza hesabı ve yayın süreci gibi sorular teklif aşamasında yazılı olarak netleşir. Siz aksini tercih etmedikçe altyapıyı biz kurar ve yönetiriz; kendi bulut hesaplarınız varsa dağıtımı oraya yaparız. Teslim edilen işin mülkiyeti proje bedelinin tamamı ödendiğinde size geçer. Yayına girdikten sonra tam bir yıl doğrudan destek veririz; bunun ötesindeki destek projeye göre ölçeklenir. Ayrıntılar mobil uygulama yaptırma ve Süreç sayfalarında. Bağlayıcı olan, işiniz için imzalanan yazılı sözleşmedir.

Sık sorulan sorular

Mobil uygulama yaptırmak ne kadar tutar?

Mobil uygulama yaptırma maliyeti için tek bir rakam vermiyoruz, çünkü maliyet kapsamla birlikte değişir: ekran ve durum sayısı, arka uç ve yönetim paneli, özellikler, entegrasyonlar, platform seçimi ve bakım beklentisi. Bu yazıdaki kalem tablosu ve karşılaştırma şablonu, kendi teklifinizi çözümlemeniz içindir. Kapsam netleştikten sonra, yazılı teklifte kapsam, takvim ve maliyet birlikte yer alır.

iOS ve Android uygulaması birlikte mi yapılır?

İkisi de yapılabilir; tek kod tabanıyla ya da her platform için ayrı kodla. Seçim ürünün ihtiyaçlarına ve bakım yüküne göre değişir ve teklifte gerekçesiyle ve ayrı bir kalem olarak yazılmalıdır. Hangisini neden önerdiğimizi her teknik karar gibi yazılı hale getiririz.

Uygulamanın yıllık işletme maliyeti neleri içerir?

Geliştirme teklifinin dışında kalan sürekli giderleri: mağaza hesapları (Apple için üyelik yılı başına 99 USD, Google Play için tek seferlik 25 USD; 24 Ekim 2026'da resmî sayfalardan okundu), sunucu ve depolama, bildirim ve SMS gibi servislerin kullanımı, alan adı ve sertifikalar, mağaza gereksinimleri yükseldikçe gereken güncellemeler ve bakım. Kalem kalem liste yukarıdaki tabloda.

Yönetim paneli ve sunucu teklife dahil mi?

Bunu teklifte ayrı kalemler olarak sorun. "Mobil uygulama" yazan bir satır, arka ucu ve yönetim panelini kapsıyor olabilir ya da kapsamıyor olabilir; yazılı yanıt istenmeden bilinemez. Biz altyapıyı siz aksini tercih etmedikçe kurar ve yönetiriz.

Ucuz teklif neden riskli olabilir?

Ahlaki bir yargı olarak değil, kalem eksikliği olarak: düşük fiyat, arka ucu, yönetim panelini, ikinci platformu, testi, yayını ya da bakımı kapsamıyor olabilir. Bu durumda eksik kalemler sonradan ek maliyet olarak size döner. Karşılaştırma şablonunu doldurun; fiyat farkı kapsam farkından geliyorsa, tablo bunu gösterir.

Kaynaklar

Aşağıdaki sayfalar 24 Ekim 2026'da açılıp okundu. Ücret, komisyon ve gereksinim bilgisi taşıyan sayfalar sık değişir; karar vermeden önce yeniden açın.

• Apple Developer Program: kayıt · Apple: yaklaşan gereksinimler · Apple: App Store Küçük İşletme Programı
• Google Play: geliştirici hesabı kaydı · Google Play: hizmet ücretleri · Google Play: hedef API düzeyi gereksinimleri
• Apple: App Store inceleme yönergeleri · Apple: uygulama gizlilik ayrıntıları · Google Play: Veri güvenliği bölümü · Google Play: hesap silme gereksinimi
• Firebase fiyatlandırma

Bu yazı genel bilgi içindir; teklif ya da sözleşme yerine geçmez.