Mobil Uygulama Geliştirme Maliyetini Hangi Kalemler Belirler?
Beş kalem bütçeyi belirler: ekran, platform, entegrasyon, tasarım ve bakım. Bu beşi netleşmeden söylenen rakam tahminden ibarettir. Kapsamı yazıya döktüğünüzde aynı iş için aldığınız teklifler birbirine yaklaşır. Aradaki farkın gerekçesini kalem kalem görürsünüz. Mobil uygulama geliştirme bütçesi böylece pazarlık konusu olmaktan çıkar.
Bir ürünün bedelini geliştiricinin saat ücreti değil, işin kaç ayrı parçadan oluştuğu belirler. Beş ekranlı bir katalog uygulaması düşünün. Bir de ödeme alan, kurye takibi yapan bir uygulama. İkisi aynı meslekten çıkar; aynı iş değildir.
Aşağıdaki kalemler her projede karşımıza çıkar. Hangisinin ağır bastığı ürüne göre değişir. Mobil uygulama geliştirme tekliflerini okurken önce bu beş başlığı arayın. Görüşmeye hangi soruları getireceğinizi uygulama yaptırma soruları yazısında sıraladık.
- Ekran ve durum yoğunluğu — kaç ekran değil, ekran başına kaç hâl.
- Platform sayısı — tek mağaza mı, iki mağaza mı.
- Entegrasyon derinliği — ödeme, kargo, kimlik, harita.
- Tasarım özgünlüğü — hazır bileşen mi, marka dili mi.
- Yayın sonrası bakım — ürün yaşadığı sürece süren gider.
Ekran Sayısı Neden Tek Başına Yeterli Bir Ölçü Değil?
Herkes ekran sayarak başlar, çünkü saymak kolaydır. Oysa bir listeleme arayüzüyle canlı konum gösteren bir arayüz aynı emeği istemez. Biz ölçü olarak ekran başına düşen mantık yoğunluğunu kullanırız. Şunu sorarız: o arayüzde kaç durum var, kaç hata hâli çizmemiz gerekiyor, veri gelmediğinde kullanıcı ne görüyor. Yanıtlar arttıkça bütçe de artar. Ekran sayısı aynı kalsa bile bu yanıtlar bütçeyi ikiye katlayabilir.
Entegrasyon Derinliği Bütçeyi Nasıl Hareket Ettirir?
Uygulamanın dışarıyla konuştuğu her nokta ayrı bir iş doğurur. Ödeme, kargo, e-fatura, kimlik doğrulama, harita, bildirim: her biri kendi kuralıyla gelir. Bu bağlantıların çoğunu hazır servisler karşılar. Asıl yükü servisin kendisi değil hata hâlleri yaratır. Ödeme yarıda kalırsa ne olacağı sorusu, bağlantının kendisinden uzun sürer.
Tek Platform mu, İki Platform mu? Karar Bütçeyi Ne Kadar Etkiler?
İki platform iki katı iş anlamına gelmez. Tek kod tabanı seçtiğinizde fark belirgin biçimde daralır. Kararı iki şey belirler: kullanıcılarınızın hangi cihazda olduğu ve donanıma ne kadar yaklaşmanız gerektiği. Kamera, sensör ve arka plan konumu gibi ihtiyaçlar tabloyu değiştirir. Bunlar yoksa tek kod tabanı bütçenizi korur.
Projelerin çoğu iOS ve Android'i birlikte ister. Bu isteğin bütçeye yansımasını seçtiğiniz mimari belirler. Tek kod tabanıyla ilerlerken ortak işi bir kez yaparız. Platforma özgü kısımları ayrı yazarız. Native yolda ise iki ekip iki ayrı ürün kurar.
Şu soruyu erken sormak, sonradan gelen pahalı dönüşleri önler: uygulamanın donanıma yakın çalışması gerekiyor mu? Kamera, sensör, arka plan konumu ve ağır grafik varsa yanıt genelde evet çıkar. Geliştirilen mobil uygulama bu ihtiyaçları taşımıyorsa tek kod tabanı bütçeyi korur.
Mobil uygulama geliştirme bütçesini asıl şişiren şey, kararın geç verilmesidir. Altı ay sonra mimari değiştirmek, baştan iki platform yazmaktan pahalıya gelir.
Hangi Durumda Tek Platformla Başlamak Mantıklı?
Kullanıcı kitleniz belirgin biçimde tek tarafta toplanıyorsa, tek platformla başlayın. Önce ölçün, sonra genişletin; bu sıra bütçenizi korur. Kurumsal içi kullanım, saha ekibi uygulamaları ve bayi panelleri bu gruba girer. Oralarda cihaz parkı zaten bellidir.
Tasarım Bütçesi Nerede Şişer, Nerede Kısılabilir?
Maliyeti ekran çizmek değil, durumları çoğaltmak yaratır. Her arayüzün dolu, boş, yükleniyor ve hata hâlini ayrı ayrı çizeriz. Hazır bileşen kitiyle başlamak bu yükü azaltır; marka dilini tümüyle özgün kurmak artırır. Seçimi uygulamanızın deneyim iddiası belirler. Vitrin işinde hazır kit yeter, deneyimin kendisi ürünse özgün dil kazandırır.
Bir uygulama arayüzü, web sayfasından farklı olarak durumlarla yaşar. Kullanıcı çevrimdışıysa ekranda ne çıkacak? Liste boşsa, istek zaman aşımına uğradıysa kullanıcı ne görecek? Bu soruları tasarım aşamasında yanıtlamazsanız iş geliştirme aşamasına kayar. Orada çözmek daha pahalıya gelir.
Geliştirme masasında mobil uygulama kararlarının yarısı zaten tasarımda verilmiştir. Arayüz kararlarının kullanıcı davranışına etkisini arayüz tasarımı ilkeleri yazısında ayrıca ele aldık.
Özgün Tasarım Her Projede Gerekli mi?
Hayır. Marka deneyiminin kendisi ürün olduğunda özgün tasarım yatırıma dönüşür. İç kullanım araçlarında ise platformun kendi bileşenleri hem ucuza gelir hem kullanıcıya tanıdık görünür. Kapsam görüşmesinde bu ayrımı en başta yaparız. Mobil uygulama geliştirme bütçesinde tasarım ilk kısılan kalemdir. Çoğu zaman da yanlış kalemdir.
Tasarım Sistemi Kurmanın Geri Dönüşü
Bileşenleri bir kez tanımladığınızda sonraki ekranlar hızlanır. Yatırımı ilk aylarda hissedersiniz, getirisini ikinci sürümde görürsünüz. Uygulamayı büyütmeyi planlıyorsanız burası kısacak yer değildir.
Yayın Sonrası Bakım Neden Bütçenin Parçası?
Uygulama yayına çıktığında iş bitmez. İşletim sistemleri her yıl büyük sürüm çıkarır, mağazalar da uyum kuralları koyar. Bakım kalemi ayırmayan ekipler ikinci yılda çalışmayan bir ürünle kalır. Bu yüzden sürdürme giderini baştan bütçeye yazarız. Mobil uygulama geliştirme kararı, ürünün ilk gününü değil ömrünü kapsar.
Web sitesi güncellenmese de açılmaya devam eder. Mobil yazılım öyle davranmaz: mağaza kuralları değişir, kütüphaneler eskir, sertifikalar süresini doldurur. Bu nedenle bakımı isteğe bağlı bir hizmet gibi değil, ürünün sürekli gideri olarak konumlandırırız. Aşamaların nasıl sıralandığını geliştirme süreci yazısında anlattık.
Türkiye'de mobil cihaz üzerinden internet kullanımı yaygın. Bu yaygınlık kurumları uygulama tarafındaki sürekliliği ciddiye almaya itiyor. Güncel hane halkı bilişim teknolojileri istatistiklerini TÜİK düzenli olarak yayımlıyor.
Bakım Kaleminde Neler Var?
İşletim sistemi uyumu, kütüphane güncellemeleri, mağaza politikası değişiklikleri, çökme takibi ve küçük iyileştirmeler. Bu başlıkların hiçbiri yeni özellik anlamına gelmez. Ürünü ayakta tutan bakımı tarif ederler. Yeni özellik ayrı bir kalemdir ve ayrı konuşulur. Bu ayrımı sözleşmede yazılı tutmak, ikinci yılda çıkan tartışmaların çoğunu baştan bitirir.
İki Teklif Arasındaki Fark Nereden Doğar?
Farkı genelde kapsamın farklı okunması yaratır. Bir taraf hata hâllerini ve bakımı fiyata katar, diğeri yalnız mutlu senaryoyu hesaplar. Kalemleri yazılı karşılaştırdığınızda fark hızla küçülür. Rakamlar o noktadan sonra konuşulabilir hâle gelir. Aynı kapsamı gören iki ekip, birbirine yakın iki rakam söyler.
Teklifleri Eşitlemenin Üç Sorusu
Teklifleri yan yana koyarken şu üçüne bakın. Hangi platformlar kapsama giriyor? Kaç ekran ve hangi durumlar çizilecek? Yayın sonrası hangi süre dahil? Bu üçünü eşitlemeden yaptığınız fiyat karşılaştırması sizi yanıltır.
Uygulamanız web tarafıyla ortak bir arka uç kullanacaksa, özel yazılım tarafındaki işi de aynı bütçenin içinde konuşun. Benzer bir kapsam tartışmasını e-ticaret altyapısı seçimi yazısında da yürüttük. Mobil uygulama geliştirme teklifinde en az bilgilendirici satır, en alttaki toplam rakamdır. Kalem adlarını arayın.
“Bir defaya mahsus olarak 25 ABD doları tutarında kayıt ücreti alınır.”
— Play Console Yardım, Google Play Console'u kullanmaya başlama
Bütçenizi Kapsamla Birlikte Çıkaralım
Kapsam netleşmeden söylenen rakam iki tarafı da yanıltır. Ekran sayınızı, bağlantılarınızı ve platform ihtiyacınızı birlikte konuşuyoruz. Hangi kalemin bütçeyi ne kadar hareket ettirdiğini yazılı çıkarıyoruz. Elinizde bir fiyat değil, fiyatın gerekçesi kalıyor. Mobil uygulama geliştirme kararını o gerekçeyle vermek, sonradan gelen sürprizleri azaltır.
Görüşmeden Elinizde Ne Kalır?
Görüşme sonunda size bıraktığımız belge bir rakam listesi değil. Hangi kalemi kısarsanız neyi kaybedeceğinizi de aynı sayfada görürsünüz. Geliştiren ekip mobil uygulamayı sizinle birlikte tanımlarsa, sürpriz payı küçülür.
Maliyet kalemleri ve bütçeye etkisi
Bütçeyi en doğrudan ekran sayısı ve durum yoğunluğu büyütür; bu kalem kapsamla doğrusal artar. Platform sayısının etkisi mimariye göre değişir; tek platformla başlamak bu kalemi daraltır. Entegrasyon derinliği, hata hâlleri hesaba girince yükselir. Tasarım özgünlüğünü hazır bileşenlerle kısabilirsiniz. Yayın sonrası bakımı ise ertelemek pahalıya gelir.
| Kalem | Bütçeye etkisi | Kısılabilir mi? |
|---|---|---|
| Ekran sayısı ve durum yoğunluğu | Doğrudan ve doğrusal | Kapsam daraltarak evet |
| Platform sayısı (iOS + Android) | Mimariye göre değişken | Tek platformla başlayarak evet |
| Entegrasyon derinliği | Hata hâlleriyle birlikte yüksek | Aşamalandırarak kısmen |
| Tasarım özgünlüğü | Orta; sistem kurunca geri döner | Hazır bileşenle evet |
| Yayın sonrası bakım | Sürekli gider | Hayır — ertelemek pahalıya gelir |
Teklifleri Nasıl Karşılaştırmalısınız?
Mobil uygulama geliştirme bütçesi tek bir rakamdan değil, beş kalemin toplamından çıkar. Kapsamı yazıya döktüğünüz an hem teklifleri karşılaştırabilir hem de hangi kalemi kısarsanız neyi kaybedeceğinizi görebilirsiniz.