Mobil uygulama maliyeti ve süresi 2026: neye göre değişir?

Mobil uygulama maliyeti tek bir rakam değildir; uygulamanın kaç platformda çalışacağına, kullanıcı hesabı ve ödeme içerip içermediğine, arkasında bir sunucu ve yönetim paneli gerekip gerekmediğine, çevrimdışı çalışma, bildirim ve entegrasyon ihtiyacına göre değişir. Güvenilir bir tahmin, bu kalemleri kendi kapsamınızla tek tek işaretleyip her teklifi aynı listeyle karşılaştırarak çıkar.

Fiyat tablosu ya da ortalama rakam vermiyorum, çünkü kaynağını gösteremeyeceğim bir aralık sizin projeniz hakkında bir şey söylemez: aynı adı taşıyan iki uygulamanın kapsamı birbirinden çok farklı olabilir. Onun yerine bütçeyi büyüten kararları, yayından sonra süren giderleri ve kendi kapsam listenizden hafta cinsinden tahmin çıkarmanın yolunu anlatıyorum. Ben olsam teklif istemeden önce kapsamı bu kalemlere göre yazıya dökerdim; farklı firmalardan gelen teklifler ancak o zaman aynı işi fiyatlar.

Mobil uygulama maliyeti neye göre değişir?

Mobil uygulama maliyetini belirleyen şey ekran sayısından çok ekranların arkasındaki iştir: veri nereye yazılıyor, kim neye yetkili, para nasıl alınıyor, internet yokken ne oluyor. Bir giriş ekranı tasarımda tek ekran görünür; arkasında ise hesap açma, şifre yenileme, hesap silme ve oturum güvenliği vardır. Bu yüzden bir mobil uygulama bütçesini ekranlardan değil, şu maliyet kalemlerinden başlayarak konuşmak gerekir.

• Platform sayısı: Yalnızca iOS, yalnızca Android ya da ikisi birden; her platform ayrı test, ayrı mağaza hazırlığı ve ayrı bir cihaz yelpazesi demektir.
• Sunucu tarafı ve API: Verinin saklandığı, iş kurallarının çalıştığı ve uygulamanın konuştuğu arka uç, birçok uygulamanın görünmeyen yarısıdır.
• Hesaplar ve yetkiler: Kayıt, giriş, şifre yenileme, rol bazlı yetki ve uygulama içinden hesap silme.
• Ödeme: Dijital içerik mi, fiziksel ürün ya da hizmet mi sattığınıza göre mağazanın ödeme sistemi ya da kendi ödeme altyapınız.
• Çevrimdışı çalışma: İnternet yokken girilen veriyi telefonda saklamak ve bağlantı gelince çakışmaları çözerek eşitlemek.
• Anlık bildirimler: Bildirimin kime, hangi olayda ve hangi metinle gideceğinin kuralları ve kullanıcı izinleri.
• Yönetim paneli: İçeriği, kullanıcıları ve siparişleri yönetmek için uygulamanın arkasındaki web paneli.
• Entegrasyonlar: ERP, CRM, muhasebe, harita, kargo ya da e-fatura gibi mevcut sistemlere bağlantılar.
• Güvenlik ve KVKK: Kişisel verinin nerede, ne kadar süre ve kimin erişimiyle saklandığı.
• Analitik ve hata izleme: Hangi ekranın kullanıldığını ve uygulamanın nerede çöktüğünü görmek.
• Çoklu dil: Metinlerin, tarih ve para biçimlerinin ve mağaza sayfalarının her dil için ayrıca hazırlanması.

Platform, ödeme, çevrimdışı çalışma ve çoklu dil gibi maliyet kalemlerinin hepsi her projede yer almaz; maliyeti asıl belirleyen, hangilerinin ilk sürümde gerçekten gerektiğidir. Bir kalemi ilk sürümden çıkarmak büyük bir tasarruf sağlayabilir, ama bazı kalemleri sonradan eklemek baştan planlamaktan pahalıya gelebilir: çevrimdışı çalışma ve çoklu dil bunun iki tipik örneğidir. Bana göre ilk karar, hangi kalemin sonraya kalabileceğidir. İlk sürümün kapsamını daraltmanın yöntemini MVP geliştirme ve planlama rehberimizde adım adım anlattık.

Mobil uygulama geliştirme maliyetini en çok hangi kalemler büyütür?

Geliştirme bütçesini en çok büyüten kalemler, ekranın dışındaki sistemlerle ve kurallarla konuşan parçalardır: hesaplar ve ödeme, sunucu tarafı ve yönetim paneli, çevrimdışı çalışma ve bildirimler, güvenlik ve KVKK. Bu parçalar ekran tasarımında görünmez, bu yüzden tekliflerde atlanabilir ya da belirsiz kalabilir. Bir teklifte ilk bakılacak yer, bu başlıkların ayrı kalemler olarak yazılıp yazılmadığıdır.

Hesaplar, giriş ve ödeme neden ayrı bir iş kalemidir?

Kullanıcı hesabı olan bir mobil uygulama, mağaza kurallarından gelen ek işleri de üstlenir. Ekim 2026 itibarıyla Apple'ın App Store İnceleme Kuralları (yeni sekmede açılır), hesap açmayı destekleyen bir uygulamanın hesabı silmeyi de uygulama içinden sunmasını istiyor (madde 5.1.1(v)). Ana hesabı üçüncü taraf bir sosyal girişle açtırıyorsanız, belirli gizlilik koşullarını taşıyan eşdeğer bir giriş seçeneği de sunmanız gerekebiliyor (madde 4.8). Uygulama içi hesap silme ve eşdeğer giriş seçeneğinin her biri tasarım, sunucu ve test tarafında iş çıkarır.

Mobil uygulamada ödeme için Apple'ın kuralı, ne sattığınıza göre ayrılır. Uygulama içinde dijital içerik ya da özellik kilidi açıyorsanız uygulama içi satın alma şart (madde 3.1.1); uygulama dışında tüketilen fiziksel ürün veya hizmet satıyorsanız uygulama içi satın alma dışındaki yöntemleri, örneğin kartla ödemeyi kullanmanız gerekiyor (madde 3.1.3(e)). Bu maddelerin bazı ülkelere özel istisnaları da var, bu yüzden yayın öncesinde güncel kılavuzu kontrol ederdim. Kendi ödeme altyapınızı bağlayacaksanız sanal pos entegrasyonu rehberimizdeki kart verisi, iade ve mutabakat başlıkları mobil uygulama için de geçerlidir.

Sunucu tarafı ve yönetim paneli neden teklifte ayrı yazılmalı?

Mobil uygulamanın telefonda görünen kısmı, verinin tutulduğu ve iş kurallarının çalıştığı sunucu tarafı olmadan iş görmez. Uygulama bu sunucuyla bir API üzerinden konuşur; API'nin ne olduğunu ve entegrasyonların nasıl planlandığını API nedir yazımızda anlattık. İçeriği güncellemek, kullanıcıları yönetmek ya da siparişleri görmek için ayrıca bir web yönetim paneli gerekir ve bu parça tekliflerde gözden kaçabilir. Teklifte sunucu, API ve paneli üç ayrı kalem olarak görmek isterdim; birinin eksik olması, fiyatın düşük görünmesinin en basit açıklamasıdır.

Çevrimdışı çalışma ve bildirimler maliyeti nasıl etkiler?

Çevrimdışı çalışma kâğıt üzerinde tek cümledir, yazılımda ise ayrı bir mimari ister. Sahadaki bir ekip internet yokken kayıt girdiğinde, bu kaydın telefonda güvenle saklanması, bağlantı gelince sunucuya gönderilmesi ve aynı kaydı iki kişi değiştirdiyse hangisinin geçerli olacağına karar verilmesi gerekir. Anlık bildirimler de göründüğünden fazla iş çıkarır: hangi olayın bildirim tetiklediği, kullanıcı izin vermezse ne olacağı ve metinleri kimin yöneteceği ayrı kararlardır.

Bence çevrimdışı çalışma ve bildirimler ilk sürümde gerekiyorsa, baştan mimariye yazılmalı. Sonradan eklemek, mevcut veri yapısını ve sunucudaki kayıt mantığını değiştirmeyi gerektirebilir; bu da daha önce test edilmiş akışların yeniden test edilmesi demektir. Gerekmiyorsa ilk sürümden çıkarılabilirler; ileride gerekme ihtimali varsa veri yapısını buna hazır kurmak, sonradan eklemekten ucuza gelir.

Güvenlik, KVKK, analitik ve çoklu dil ne kadar iş çıkarır?

Güvenlik, KVKK, analitik ve çoklu dil, ilk sürümde küçük görünüp yayından sonra büyüyen dört maliyet kalemidir. Kişisel veri işleyen bir uygulamada verinin nerede saklandığı, kimin erişebildiği, ne kadar tutulduğu ve erişimlerin kaydının tutulup tutulmadığı tasarım kararlarıdır; yazılım ekibinden isteyeceğiniz başlıkları web sitesi KVKK kontrol listemizde topladık. Hukuki değerlendirme için bir avukata danışmak gerekir; buradaki başlıklar yazılım tarafının iş listesidir.

Analitik ve hata izleme, uygulamanın kullanıcıların telefonunda nasıl davrandığını ve nerede çöktüğünü görmenizi sağlar; bunlar olmadan yayından sonraki düzeltmeler tahmine dayanır. Çoklu dil ise yalnızca çeviri değildir: metin uzunluğuna göre ekran düzeni, tarih ve para biçimleri ve her dildeki mağaza sayfası da işe dahildir. Ben iki dilli bir uygulamayı baştan iki dilli tasarlamayı, sonradan ikinci dil eklemeye tercih ederdim.

Tek kod tabanı, native, hazır paket ya da web: hangi yol hangi maliyeti getirir?

Mobil uygulamada tek kod tabanı, native, hazır paket ve web arasındaki seçim maliyetin yapısını belirler: özel geliştirilen bir uygulama ilk yatırımı büyütüp sonraki yılları sizin kontrolünüze bırakır, abonelikli bir hazır uygulama paketi ise ilk maliyeti düşürüp tekrarlayan gideri ve sınırları satıcının kurallarına bağlar. Özel geliştirmenin içinde de iki seçenek vardır: tek kod tabanıyla iki platforma çıkmak ya da her platform için ayrı native uygulama yazmak.

Tek kod tabanı ile iki ayrı native uygulama bütçeyi nasıl etkiler?

Tek kod tabanıyla iki platforma çıkan (cross-platform) bir mobil uygulama, iOS ve Android için her platformun kendi diliyle ayrı ayrı yazılan iki native uygulamaya göre genelde daha az geliştirme işi ister; native yaklaşım ise cihaza derin erişim gerektiğinde daha az risk taşır. Ortak kod, iş kurallarının ve ekranların bir kez yazılmasını sağlar. Ancak iki mağaza hazırlığını, iki cihaz ailesinde testi ve her platformun yeni işletim sistemi sürümüne uyumu ortadan kaldırmaz.

Benim varsayılan tercihim, uygulama ağırlıkla form, liste, harita, ödeme ve bildirimden oluşuyorsa tek kod tabanıyla başlamak olurdu. Kamera ya da sensörlerle yoğun çalışan, arka planda uzun süre konum izleyen veya platformun en yeni özelliklerini ilk gün kullanması gereken bir uygulamada ise native yaklaşımın ek maliyetini riski azaltmak için ödemeye değer bulurdum. Web ile mobil arasındaki önceliği mobil uygulama mı web uygulaması mı yazımızda karar kriterleriyle ele aldık.

Tek kod tabanı, native, hazır paket ve web uygulamasının maliyet yapısı nasıl karşılaştırılır?

Tek kod tabanı, native, hazır paket ve mobil uyumlu web uygulaması arasında ilk maliyet genelde abonelikli hazır pakette ve web uygulamasında daha düşük, iki ayrı native uygulamada daha yüksektir; sahiplik ve kontrol ise hazır paket dışındaki üç yolda sizde kalır. Tablo tek kod tabanlı özel uygulamayı, iki ayrı native uygulamayı, hazır paketi ve web uygulamasını aynı üç ölçütle karşılaştırıyor.

Özel geliştirmenin artısı, uygulamanın sizin iş kurallarınızla çalışmasıdır: fiyatlandırma, onay akışı, bayi ya da şube yapısı paketin ayarlarına göre değil, işinize göre yazılır. Uygulama kendi markanızla ve kendi geliştirici hesabınızda yayınlanır, ERP, CRM ya da muhasebe sisteminize doğrudan bağlanır ve bir değişiklik için satıcının yol haritasını beklemezsiniz. Uygulamanın kendisi için kullanıcı ya da şube başına lisans ödemezsiniz; harita, SMS ya da kimlik doğrulama gibi servisler ise kullanıcı veya işlem başına ücret alabilir. Yapay zekâ destekli geliştirme araçları da tekrar eden kodun yazımını hızlandırarak ilk sürümün maliyetini düşürebiliyor; nerede işe yaradığını yapay zekâ ile uygulama geliştirme yazımızda anlattık.

Özel mobil uygulama geliştirmenin bedeli; daha uzun bir ilk sürüm, daha yüksek başlangıç maliyeti ve sistemi yayından sonra sahiplenecek birine duyulan ihtiyaçtır. Abonelikli hazır paketin aylık ücreti ise kullanıcı, şube ya da modül sayısıyla büyüyebilir. Özel uygulama ile hazır paketi üç-beş yıllık toplam maliyet üzerinden, kendi kullanıcı ve şube sayınızla karşılaştırmak daha sağlıklı olur; ilk yılın faturası tek başına yanıltıcı olabilir.

Hangi durumda hangi yolu seçmelisiniz?

Mobil uygulamada yol seçimini bütçeden önce uygulamanın cihazdan ne istediği ve kaç kişinin ne sıklıkla kullanacağı belirler; her yol şu durumlarda öne çıkar:

• Tek kod tabanı: Uygulamanız ağırlıkla veri girişi, listeleme, randevu, sipariş ve bildirimden oluşuyorsa ve iki platformda aynı anda yayına çıkmanız gerekiyorsa.
• Native yaklaşım: Uygulama kamera, Bluetooth, arka planda konum ya da yoğun grafik gibi cihaz özelliklerine dayanıyorsa veya tek platformda en yüksek performans zorunluysa.
• Tek platformla başlamak: Kullanıcılarınızın hangi telefonları kullandığını biliyorsanız ve ilk hedef fikri az bütçeyle sınamaksa.
• Hazır paket: Süreciniz paketin modüllerine birebir uyuyorsa ve kendi kurallarınıza göre değişiklik ihtiyacınız yoksa.
• Mobil uyumlu web uygulaması: Kullanıcılar uygulamayı seyrek açıyorsa, mağazada bulunmak şart değilse ve cihaz özelliği gerekmiyorsa.

App Store ve Google Play hesapları maliyete ne ekler?

App Store ve Google Play hesaplarının ücreti küçüktür; asıl etkileri takvimde ve sahiplikte görülür. Ekim 2026 itibarıyla Apple Developer Program üyeliği (yeni sekmede açılır) yıllık 99 ABD doları; Apple fiyatın bölgeye göre değişebileceğini ve kayıt sırasında yerel para birimiyle gösterildiğini belirtiyor. Google Play geliştirici hesabı (yeni sekmede açılır) için ise bir defaya mahsus 25 ABD doları kayıt ücreti alınıyor.

Mağazaların dijital satışlardan aldığı hizmet ücreti ayrı bir kalemdir ve gelir modelinizi doğrudan etkiler. Google, hizmet ücretlerinin (yeni sekmede açılır) pazara göre değiştiğini ve güncellenmiş ücretleri bölgelere kademeli olarak getirdiğini belirtiyor. Bu yüzden uygulama içi satış ya da abonelik planlıyorsanız oranı tahmin etmek yerine, iş planınızı kurarken güncel oranı mağazanın kendi sayfasından okumanızı tavsiye ederim.

Geliştirici hesapları neden şirketinizin adına açılmalı?

Geliştirici hesaplarının şirketinizin adına açılması, uygulamanın ve mağaza kaydının sahipliğini sizde tutar. Apple (yeni sekmede açılır), kuruluş üyeliği için D-U-N-S numarası (Dun & Bradstreet'in verdiği şirket kimlik numarası) istiyor; kuruluş hesabında App Store'da satıcı adı olarak kuruluşun adı, bireysel hesapta ise kişinin adı görünüyor. Google da kuruluş adına geliştirici hesabı (yeni sekmede açılır) açmak için D-U-N-S numarası istiyor ve bu numaranın Dun & Bradstreet üzerinden ücretsiz alındığını belirtiyor. Kuruluş hesabının takvim açısından da bir anlamı olabilir: Google'ın yardım sayfası 12 test kullanıcılı, 14 günlük kapalı test şartını kişisel hesaplar için tanımlıyor.

Ben App Store ve Google Play geliştirici hesaplarının baştan şirketinizin adına açılmasını şart koşardım. Geliştirici firmanın ya da bir çalışanın kişisel hesabında yayınlanan bir uygulama, firma değiştirdiğinizde taşıma işi ve gecikme demektir. D-U-N-S numarasının alınması da zaman alabileceği için bu işi geliştirmenin ilk haftasında başlatırdım.

İnceleme ve test süreleri takvimi nasıl etkiler?

Mağaza inceleme ve test süreleri bütçeden çok takvimi etkiler. Ekim 2026 itibarıyla Apple, başvuruların tipik olarak en az yarısını 24 saatten, yüzde 90'ını 48 saatten kısa sürede incelediğini (yeni sekmede açılır) söylüyor; eksik bir başvurunun gecikebileceğini ya da reddedilebileceğini de ekliyor. Google tarafında ise Ekim 2026 itibarıyla, 13 Kasım 2023'ten sonra açılan kişisel hesaplar, üretime çıkmadan önce en az 12 test kullanıcısının 14 gün boyunca kesintisiz katıldığı kapalı bir test (yeni sekmede açılır) yapmak zorunda.

Yayın tarihini bir kampanyaya bağlıyorsanız her durumda Apple incelemesi ve olası bir ret turu için, kişisel hesapla yayınlıyorsanız Google'ın 14 günlük kapalı testi için de takvimde pay bırakırdım. Mağazaya yayın sürecinin adım adım ayrıntıları ayrı bir konu; mobil uygulama bütçesi açısından önemli olan, ret turlarındaki düzeltmelerin teklife dahil olup olmadığıdır.

Yayından sonra hangi mobil uygulama giderleri devam eder?

Yayına çıkmak giderlerin sonu değildir: mağaza üyelikleri, sunucu ve servis ücretleri, işletim sistemi uyumu, hata izleme ve destek ilk geliştirme bedeline dahil değildir ve her yıl tekrar eder. Mobil uygulama bakım maliyeti bu yüzden bütçeye yıllık bir kalem olarak girmelidir. Teklif aşamasında bu kalemlerin her birinin kim tarafından, hangi süreyle ve hangi ücretle karşılanacağını yazılı olarak sorun.

• Mağaza üyelikleri: Apple üyeliği her yıl yenilenir; Google kaydı tek seferliktir.
• Sunucu, veritabanı ve servisler: Barındırma, yedekleme, e-posta ya da SMS gönderimi, harita ve bildirim servisleri; bir kısmı kullanım arttıkça büyür.
• iOS güncellemelerine uyum: Ekim 2026 itibarıyla Apple, 28 Nisan 2026'dan bu yana App Store Connect'e yüklenen uygulamaların Xcode 26 ve iOS 26 SDK'sı ile derlenmesini (yeni sekmede açılır) istiyor.
• Android güncellemelerine uyum: Ekim 2026 itibarıyla Google, 31 Ağustos 2026'dan itibaren yeni uygulama ve güncellemelerin Android 16'yı (API düzeyi 36) hedeflemesini (yeni sekmede açılır) şart koşuyor (Wear OS, Android TV, Android Automotive OS ve Android XR için farklı API düzeyleri geçerli).
• Hata izleme ve güvenlik güncellemeleri: Çökme raporlarının takibi, kütüphane güncellemeleri ve güvenlik açıklarının kapatılması.
• Destek ve küçük değişiklikler: Kullanıcı sorunları, mağaza ret yanıtları ve küçük metin ya da kural değişiklikleri.

Güncelleme yayınlamasanız bile Google, 31 Ağustos 2026'dan itibaren en az Android 15'i (API düzeyi 35) hedeflemeyen mevcut uygulamaları, daha yeni Android sürümlü cihazlardaki yeni kullanıcılara göstermiyor; bu yüzden yeni özellik eklemeseniz de düzenli uyum güncellemesi gerekir. Bakım kalemlerini teklif içinde ayrı bir destek dönemi olarak görmek isterdim: süresi, kapsadığı işler, yanıt süresi ve dönem bitince nasıl devam edileceği. Bakım ve SLA maddelerinin nasıl yazılacağını yazılım hizmet sözleşmesi örneğimizde madde madde ele aldık.

Sabit fiyat neyi kapsar, saat bazlı çalışma ne zaman daha uygundur?

Mobil uygulamada sabit fiyat, yazılı ve onaylanmış bir kapsamın karşılığıdır; kapsam henüz netleşmemişse ve ürün kullanıcı geri bildirimiyle haftadan haftaya şekilleniyorsa saat bazlı çalışma (time & material) daha uygundur. UlvionTech'te keşif aşaması yazılı kapsam, teslim planı ve sabit fiyatla biter; kapsam sonradan değişirse değişiklik geliştirilmeden önce fiyatlanır. Mobil uygulama için verilen sabit fiyatlı bir teklifte şu kalemlerin açıkça yazılmasını beklerdim:

• Ekranlar ve kullanıcı akışları listesi, her akış için kabul ölçütüyle.
• Sunucu tarafı, API ve yönetim paneli, ayrı kalemler olarak.
• Hangi cihaz ve işletim sistemi sürümlerinde test edileceği.
• Mağaza hazırlığı: ekran görüntüleri, gizlilik bildirimleri ve inceleme turlarındaki düzeltmeler.
• Kaynak kodun, hesapların ve verinin devri.
• Yayından sonraki destek döneminin süresi ve kapsamı.

Sabit fiyatlı bir mobil uygulama teklifinde kapsam dışında kalanlar da yazılmalıdır: yeni özellik talepleri, üçüncü taraf servislerin ücretleri, mağaza ve sunucu üyelikleri ve kapsamda olmayan entegrasyonlar sabit fiyata dahil olmaz. Saat bazlı modelde ise ödeme harcanan saat üzerinden yapılır; bu modelde haftalık raporlama ve bir üst sınır üzerinde anlaşmak bütçeyi korur.

Bence fikir aşamasındaki bir ürün için kısa, saat bazlı bir keşif dönemi ve ardından yazılı kapsamla sabit fiyat, iki modelin iyi bir birleşimidir. Böylece belirsizliğin bedelini kısa bir dönemle sınırlar, asıl geliştirmeyi ölçülebilir bir kapsamla fiyatlarsınız. Teklifleri aynı ölçüyle okumanın yolunu yazılım yaptırma maliyeti ve teklif karşılaştırma rehberimizde anlattık.

Mobil uygulama yaptırmak ne kadar sürer, maliyeti nasıl tahmin edilir?

Mobil uygulama yaptırmanın ne kadar süreceği ve ne kadar tutacağı, kendi kapsam listenizdeki kullanıcı akışlarından ve her akışın içerdiği maliyet kalemlerinden tahmin edilebilir; süreyi en çok uzatanlar ise geç verilen kapsam kararları, üçüncü taraf onayları (D-U-N-S numarası, ödeme kuruluşu, ERP erişimi) ve mağaza ret turlarıdır. Hazır bir hafta aralığı vermek yerine, teklif veren her firmadan aynı listeyi akış akış fiyatlamasını isteyen şu yöntemi öneriyorum; böylece süre ve fiyat sizin kapsamınızdan çıkar:

1. Kullanıcı tiplerini yazın: Uygulamayı kimler kullanacak (müşteri, saha personeli, yönetici) ve her biri neyi yapabilecek?
2. Akışları listeleyin: Her kullanıcı tipi için baştan sona bir iş akışı yazın: "müşteri randevu alır", "personel sahada form doldurur" gibi.
3. Her akışa maliyet kalemlerini işaretleyin: Hesap, ödeme, çevrimdışı çalışma, bildirim, entegrasyon, panel ve çoklu dil kalemlerinden hangileri o akışta var?
4. Önceliği belirleyin: Her akışı "ilk sürümde şart", "olsa iyi olur" ve "sonra" diye üçe ayırın; yalnızca ilk grubu fiyatlatın.
5. Akış başına hafta isteyin: Teklif veren her firmadan, işaretlediğiniz kalemleri dikkate alarak her akış için tahmini hafta ve kişi sayısını ayrı yazmasını isteyin.
6. Sabit kalemleri ekleyin: Mağaza hazırlığı, test, inceleme turları ve yayından sonraki destek dönemini ayrıca fiyatlanmış kalemler olarak toplama ekleyin.
7. Yıllık işletme giderini yazın: Mağaza üyeliklerini, sunucu ve servis ücretlerini kendi kullanıcı sayınızla birinci, üçüncü ve beşinci yıl için tahmin edin.

Akış başına süre ve kalem listesini üç firmaya aynı şekilde gönderdiğinizde, bir firmanın bir akışa diğerlerinden çok farklı süre yazdığı yer, konuşmanız gereken yerdir: o firma bir riski görmüş, kapsamı farklı anlamış ya da işi eksik fiyatlamış olabilir. Firmalardan gelen toplamlara bakmadan önce akış başına satırları yan yana koymak, farkın nereden geldiğini gösterir. Listeyi hazırlarken yazılım yaptırmak istiyorum brief şablonumuzdaki mobil projeye özgü başlıklar işinizi kolaylaştırır.

Teklif görüşmesine hangi soruları götürmeli, hangi hatalardan kaçınmalısınız?

Mobil uygulama teklif görüşmesine sahiplik, kapsam, test ve yayın sonrası hakkında net cevap isteyen bir soru listesiyle gitmek, teklifleri karşılaştırılabilir kılar. Şu soruların her birine yazılı cevap isteyin:

• Geliştirici hesapları, alan adı ve sunucu kimin adına açılacak?
• Kaynak kod ve uygulamayı imzalayan anahtarlar teslimde nasıl devredilecek?
• Hangi kısım iki platformda ortak, hangisi platforma özel yazılacak?
• Sunucu tarafı ve yönetim paneli teklifte ayrı satır olarak var mı?
• Hangi cihaz ve işletim sistemi sürümlerinde test edeceksiniz?
• Mağaza reddi olursa düzeltme turları fiyata dahil mi?
• Destek dönemi ne kadar, neyi kapsıyor, sonrasında ücret nasıl belirleniyor?
• Kişisel veriler hangi ülkede, hangi sunucuda saklanacak?

Mobil uygulama bütçesinde hangi hatalardan kaçınmalı?

Mobil uygulama bütçesindeki hataların ortak noktası, görünmeyen işin teklif dışında kalmasıdır:

• Ekran sayısıyla fiyat istemek: Ekranlar aynı kalsa bile arkadaki sunucu, yetki ve entegrasyon işi bütçeyi belirler.
• Yönetim panelini unutmak: İçerik ve kullanıcılar yönetilemeyince yayından sonraki ilk haftalarda ek iş çıkar.
• Hesapları geliştiricinin adına açtırmak: Firma değiştirdiğinizde uygulamayı taşımak zaman ve risk demektir.
• Bakım kalemini bütçeye koymamak: İşletim sistemi uyum güncellemeleri isteğe bağlı değildir; güncelleme yayınlamasanız bile mağaza kuralları uygulamanın yeni kullanıcılara görünmesini etkileyebilir.
• İlk sürüme her şeyi koymak: Kapsam büyüdükçe süre ve test yükü de büyür; önce birkaç akışı sorunsuz çalıştırmak çoğu zaman daha ucuza gelir.

Ben olsam bir mobil uygulama bütçesini nasıl kurardım?

Ben olsam bir mobil uygulama bütçesini ekranlardan değil, ilk sürümde mutlaka çalışması gereken bir veya iki kullanıcı akışından kurardım. Önce bu akışları içerdikleri maliyet kalemleriyle birlikte yazıya döker, sonra tek kod tabanının yetip yetmediğine uygulamanın cihazdan ne istediğine bakarak karar verirdim. Sunucu tarafını ve yönetim panelini baştan kapsamın içine alır, geliştirici hesaplarını ilk haftada şirket adına açtırırdım. Yayından sonraki ilk yılın işletme giderini de geliştirme bedeliyle aynı tabloda gösterirdim.

UlvionTech'in mobil uygulama hizmetinde varsayılan yaklaşım, tek kod tabanıyla iOS ve Android'i birlikte hedeflemektir; cihaz özelliği gerektiren yerde native geliştirmeyi öneriyoruz. Kod yazmaya başlamadan önce kapsamı yazıya döküyor, fiyatı bu yazılı kapsamdan sonra sabit olarak veriyoruz. Kod deposu, bulut hesapları, alan adları ve üçüncü taraf servisler ilk günden şirketinizin adına açılır; her teklifimizde süresi yazılı bir destek dönemi yer alır. Hizmetin kapsamını mobil uygulama geliştirme sayfamızda bulabilirsiniz.

Hangi durumlarda mobil uygulama yaptırmamalı ya da UlvionTech ile çalışmamalısınız?

Mobil uyumlu bir web uygulaması yetiyorsa, hazır bir paket sürecinize birebir uyuyorsa, kendi mobil ekibiniz varsa ya da fikir henüz sınanmadıysa, özel bir mobil uygulamaya veya UlvionTech'e ihtiyacınız olmayabilir. Bu durumları açıkça yazmayı, bütçe kararının bir parçası sayıyorum:

• Mobil uyumlu bir web uygulaması yetiyorsa: Kullanıcılar uygulamayı seyrek açıyorsa ve cihaz özelliği gerekmiyorsa, web uygulaması daha az maliyetle aynı işi görebilir; karşılaştırmayı mobil uygulama ile web uygulaması karar rehberimizde yaptık.
• Hazır bir paket ihtiyacınıza birebir uyuyorsa: Süreciniz standartsa ve paketin üç-beş yıllık toplam ücreti özel geliştirmeden düşük kalıyorsa, paketle başlamak mantıklıdır; ölçütleri özel yazılım mı hazır yazılım mı yazımızda bulabilirsiniz.
• Kendi mobil ekibiniz varsa: İçeride mobil geliştirme yapan bir ekip varsa, bütün uygulamayı dışarıya yaptırmak yerine yalnızca belirli bir parça için destek almak daha uygundur.
• Fikir henüz sınanmadıysa: Uygulamayı kimin kullanacağı belli değilse, önce bir prototip ya da basit bir web sürümüyle talebi ölçmek bütçenizi korur.

Kendi akış listenizi çıkardıysanız, o listeyi bize yazarak paylaşabilirsiniz; hangi kalemlerin ilk sürümde gerektiğini ve tek kod tabanının yetip yetmeyeceğini listeniz üzerinden birlikte değerlendiririz.

Fotoğraf kredisi: kapak fotoğrafı, Parker Byrd (Wikimedia Commons (yeni sekmede açılır), CC0) ve masa fotoğrafı, JESHOOTS.COM (Wikimedia Commons (yeni sekmede açılır), CC0); sunucu fotoğrafı, NOIRLab/NSF/AURA/T. Slovinský (Wikimedia Commons (yeni sekmede açılır), lisans: CC BY 4.0 (yeni sekmede açılır)). Fotoğraflar kırpıldı.