Mobil uygulama yaptırmak ne kadar tutar?
Bir mobil uygulama yaptırmanın gerçekte ne kadara mal olduğu, fiyatı neyin belirlediği ve şeffaf bir teklifle nasıl fazla ödeme yapmaktan kaçınacağınız.
Kısa cevap
İyi yapılmış native bir iOS uygulaması genellikle 20.000 ile 120.000 dolar arasında değişir. Odaklı bir ilk sürüm alt sınırda, çok özellikli ve karmaşık bir backend’e sahip bir uygulama ise çok daha yüksekte yer alır. Fiyatı en çok kapsam, tasarım ve backend belirler, ekibin yeri değil. Ucuz şablon çoğu zaman en pahalı seçenektir; şeffaf, kalem kalem bir teklif ise fazla ödemeye karşı en iyi korumanızdır. Belirli bir sektör için, e-ticaret uygulaması yaptırmanın maliyeti rehberimiz bir örnek verir.
Fiyat neden bu kadar değişir
Anlaşılması gereken ilk şey, bir uygulamanın tek bir şey olmadığıdır. Biri uygulamanın maliyetini sorduğunda, dürüst yanıt bir soruyla başlar: uygulama gerçekte ne yapacak? İki kişi de bir uygulama isteyebilir ve çok farklı ürünleri kastediyor olabilir; biri beş ekranlı basit bir araç, diğeri onlarca özellik ve entegrasyon içeren bir sistem; biri hazır parçaları yeniden kullanan, diğeri çekirdeğinde özel mantık gerektiren.
İşte bu yüzden her gerçekçi aralık geniştir. Bir uygulamanın maliyeti neredeyse tamamen kapsam, tasarım derinliği ve backend karmaşıklığıyla belirlenir; coğrafyayla ancak çok az. İstanbul’daki bir ekibin saatlik ücreti yurt dışındaki bir atölyeden farklı olabilir, ama toplamı asıl belirleyen, ne yaptırmayı seçtiğinize bağlı olan saat sayısıdır. Kapsamı iyi belirleyin, fiyat makul biçimde onu izler; belirsiz bırakın, teklif bilinmeyeni karşılamak için şişer ya da bir ajans size düşük bir rakam verip sonradan ek maliyetlerle yükseltir. Bu yüzden fiyat sormadan önce yapabileceğiniz en yararlı şey, uygulamanın gerçekte ne yapması gerektiğini netleştirmektir.
Maliyeti ne belirler
Bir uygulamanın fiyatını en çok beş şey hareket ettirir:
- Lansmanda kaç özellik yaptırdığınız. Her ekran, akış ve sınır durumu tasarım artı geliştirme artı testtir. Maliyeti kontrol etmenin en etkili yolu, daha az özellikle, iyi yapılmış olarak lanse etmektir.
- Tasarım derinliği. Apple’ın arayüz kılavuzunu izleyen temiz ve düşünülmüş bir arayüz gerçek tasarım zamanı ister ve kullanıcının uygulamaya güvenip onu kullanmaya devam etmesini sağlar.
- Backend karmaşıklığı. Yalnızca içerik gösteren bir uygulama ucuzdur; kullanıcıları, ödemeleri veya gerçek zamanlı güncellemeleri koordine eden bir uygulama teknik maliyetin büyük kısmını ekranda değil sunucuda taşır.
- Entegrasyonlar. Ödemeler, haritalar ve üçüncü taraf hizmetleri her biri iş ekler ve her biri bir şeyin bozulup bakım gerektirebileceği bir noktadır.
- Lansman çıtası. App Store’da yayımlamak, gerçek ve cilalı bir ürünü ödüllendiren, zayıf veya bozuk olanları reddeden Apple’ın App Store inceleme kurallarından geçmek demektir.
Beşinin ardındaki desen aynıdır: maliyet, özün peşinden gider. Soyut bir uygulama değil, sizin uygulamanızın ihtiyaç duyduğu belirli işi ödersiniz. Bu yüzden dürüst bir fiyat konuşması, önce uygulamanın gerçekte ne yapacağını netleştirmekle başlar: hangi ekranlar, hangi entegrasyonlar, hangi süreçler. Bu netlik olmadan alınan her teklif ya bir tahmindir ya da eksik olanı sonradan ek maliyet olarak size döndürecek bir başlangıçtır.
Uygulama türüne göre maliyet
| Yaklaşım | Kaba maliyet (dolar) | Ne elde edersiniz |
|---|---|---|
| Ucuz şablon | 2.000 - 8.000 | Genel bir kabuk; markaya uymaz, sınırlı |
| Odaklı native uygulama | 20.000 - 45.000 | Çekirdek akış native, temiz, hızlı |
| Tam özellikli uygulama | 45.000 - 120.000+ | Çok özellik, karmaşık backend, ölçeklenebilir |
İki not. Şablon ucuzdur ama ciddi bir uygulama için yanlış bir tasarruftur, çünkü düşük kalite ve yeniden yapım, kazançtan fazlasına mal olur. Odaklı native uygulama ise genellikle en dengeli seçenektir: her şeyi değil, çekirdeği iyi yaparak makul bir fiyata gerçek bir uygulama sunar ve çoğu işletme için doğru başlangıç noktasıdır. Seviyeler arasındaki sıçramalar çoğunlukla backend ve özelliklerle ilgilidir, estetik cilayla değil; yani hangi seviyeyi satın alacağınızı kapsamı yöneterek seçersiniz, tasarım kalitesini keserek değil.
Şablon tuzağı ve şeffaf fiyatlandırma
Türkiye’de birçok alıcının asıl korkusu haklıdır: yerel ajanslar tarafından fazla ücretlendirilmek. Ama bundan korunmanın yolu daha ucuzu aramak değil, ne için ödeme yaptığınızı anlamaktır, ve işte burada şablon tuzağı ile şeffaf fiyatlandırma devreye girer.
Hazır bir şablon renkleri ve logoyu değiştirir ama altta herkesle aynı genel yapıyı korur. Markanız veya süreçleriniz biraz özelse, kısa sürede sınırlarına çarpar ve orada takılırsınız, çünkü kod sizin değildir. Buna bir de kalite sorunu eklenir: ucuza yapılmış bir uygulama çoğu zaman yavaş çalışır ve gerçek bir uygulamanın akıcılığından yoksundur; kullanıcılar bunu hisseder ve düşük puan verir. Sonunda işe yarayan bir şey için gerçek bir uygulamayı yeniden yaptırırsınız, ve baştaki tasarruf bir yıl içinde daha büyük bir faturaya dönüşür. Fazla ödemeye karşı gerçek koruma ise şeffaf, kalem kalem bir tekliftir: tasarım, geliştirme, backend, test ve yayının ayrı ayrı gösterildiği bir teklif, hem sizi şaşırtan gizli maliyetlerden hem de aslında daha az iş için ödeme yapmaktan korur. Bir tedarikçi kendi fiyatını açıklamaktan kaçınıyorsa, asıl uyarı işareti fiyatın büyüklüğü değil, bu belirsizliktir. İki ajansın aynı işi çok farklı fiyatlaması da her zaman kötü niyet değildir: biri daha zengin bir kapsam, daha fazla cila ya da daha çok sınır durumu varsayıyor olabilir, ve okunabilir bir teklif bu varsayımları görünür kılar. Bu yüzden şaşırtıcı bir teklifi bir hüküm değil, bir soru olarak görün: neyin bu fiyatı oluşturduğunu sorun, iyi bir ajans size kapsamı ve varsayımları anlatarak açıklar. Kendi fiyatını açıklayamayan ya da açıklamak istemeyen bir ajans, rakamın büyüklüğünden çok daha ciddi bir uyarıdır.
MVP ile başlayın
Bir kurucunun yapabileceği en pahalı hata, kimse kullanmadan tüm vizyonu inşa etmektir. Para tasarrufu sağlayan ve riski azaltan yol MVP’dir: uygulamanın yapması gereken tek şeyi, gerçek insanların kullanıp ödeyeceği kadar iyi yapan bir ilk sürüm.
- Çekirdeği seçin. Uygulamanın var olma nedeni olan tek iş. Diğer her şey bir sonraki aşamaya bekleyebilir.
- İyi tasarlayın. İyi hissettiren küçük bir uygulama, kaba hissettiren büyük bir uygulamadan üstündür. Gerçek bir iPhone uygulaması gibi hızlı olması için Swift ile native yapın.
- Kanıtlanmış servisleri kullanın. Ödeme ve kimlik doğrulama, özel koddan değil, güvenilir servislerden gelir.
- Yayınlayın ve dinleyin. App Store’a koyun, gerçek kullanıcıların ne yaptığını izleyin ve sonraki adımı buna göre belirleyin.
Bu ilk sürüm aralığın alt ucundan başlar ve en önemlisi, ne inşa edileceğine karar vermek için gerçek kullanıcılar getirir; böylece tüm bütçeyi henüz hangi özelliklerin önemli olduğunu bilmeden bağlamak yerine, kanıta göre adım adım harcarsınız. Yayınlamak için bir Apple Developer Program hesabı gerekir. Sürecin tamamını anlamak için mobil uygulama yaptırmak istiyorum rehberimize bakabilirsiniz.
Gerçek bir örnek: bir işletmenin ilk uygulaması
Rakamları somutlaştırmak için, tipik bir Türk işletmesinin ilk uygulamasının nasıl dağıldığına bakalım: native bir iOS uygulamasıyla başlayan, tek bir çekirdek işi çözen odaklı bir sürüm. Bu, kapsamı iyi belirlemenin uygulanabilir bir bütçeyle şişen bir bütçe arasındaki farkı yarattığı türden bir projedir.
- Keşif ve tasarım. 3 ila 5 hafta. Burada kapsam, çekirdek akış ve markanın uygulamada nasıl görüneceği belirlenir. Bu aşama, sonraki her şeyin üzerine kurulduğu temeldir ve aceleye getirilirse maliyeti sonradan çıkar.
- Native iOS uygulaması. Çekirdek akış, temiz bir arayüz ve backend’e bağlantı ile 8 ila 10 hafta. Uygulamanın gerçek bir uygulama gibi hızlı ve akıcı hissettiği yer burasıdır.
- Backend ve entegrasyonlar. Paralelde ilerler ve çoğu zaman en zorlu kısımdır: veriler, mantık ve gereken dış sistemlerle bağlantı.
- Test ve yayın. 2 hafta. Gerçek cihazlarda test, yalnızca mutlu senaryonun değil, hatalı durumların da denenmesi ve Apple incelemesinden geçme.
Sonuç genellikle 4 ila 5 ay sürer ve aralığın orta-alt bandına oturur. Ürünü bozmadan maliyeti düşüren kararlar bellidir: birçok özellik yerine odaklı bir çekirdek, en baştan sofistike bir sistem yerine sade ve iyi çalışan bir akış, ve sonraya bırakılabilecek her şeyin ertelenmesi. Bunların hepsi kapsamı kısar, kaliteyi değil. Şeffaf bir ortak bu dökümü size kalem kalem gösterir, böylece toplam rakam bir sürpriz değil, anlayabildiğiniz ve savunabildiğiniz bir dizi karardır. İşte tam da bu, fazla ücretlendirilme korkusuna karşı en somut cevaptır: fiyatı gizleyen değil, açıklayan bir ortak.
Gizli maliyetler ve durumunuza göre bütçe
| Durumunuz | Mantıklı yaklaşım | Neden |
|---|---|---|
| Bir fikri test etmek | Odaklı MVP, aralığın alt ucu | Daha çok harcamadan talebi kanıtla |
| Net, hırslı bir ürün | Aşamalı yapım, etaplı bütçe | İnşa ederken öğren ve ayarla |
| Backend ağırlıklı uygulama | Sunucu tarafına daha çok ayır | Asıl maliyet oradadır |
| Uzun vadeli ürün | Bakımı baştan hesaba kat | Uygulama sadece yapmak değil, çalıştırmak da maliyettir |
Büyük tekliften önce gelen gizli maliyetler lansmandan sonra ortaya çıkar. Bakım için yılda geliştirme maliyetinin yaklaşık yüzde 15-20’sini ayırın, çünkü Apple her yıl yeni bir iOS sürümü çıkarır ve uygulamanın uyarlanması gerekir. Sunucular ve servisler her ay faturalanır ve uygulama başarıya ulaştıkça bu fatura büyür. App Store’da kalmak için yıllık bir Apple ücreti vardır. Uygulama içinde dijital içerik satacaksanız Apple komisyonunu da hesaba katın: App Store Small Business Program kapsamında, App Store’da yılda 1 milyon doların altında kazanan geliştiriciler standart yüzde 30 yerine yüzde 15 komisyon öder, ve yeni bir uygulama neredeyse her zaman bu eşiğin altında başlar. En derin gizli maliyet ise ucuz koddur: mümkün olan en ucuza yapılmış bir uygulama çoğu zaman değiştirmesi yavaş ve düzeltmesi pahalı, dağınık bir kodla gelir, böylece tekliften kazanılan bir yıl içinde kaybedilir. Bütçelemenin doğru yolu, harcamayı aşamaya göre eşleştirmek ve çalıştırma maliyetlerini baştan dahil etmektir; ucuz yapılan ama pahalıya çalışan bir uygulama tasarruf değil, planlamadığınız bir yere taşınmış bir maliyettir.
Ne zaman native app’e gerek yoktur
Gerçekten bir native uygulamaya ihtiyacınız olup olmadığı konusunda dürüst olun. Fikriniz özünde bir içerik sitesi veya basit bir formsa, iyi bir uyarlanabilir web sitesi daha iyi hizmet verebilir ve herhangi bir uygulamadan çok daha ucuza mal olabilir. Bir native uygulama; bildirim göndermek, çevrimdışı kullanım, cihaz özellikleri, gerçek performans ya da kullanıcıların uygulama aradığı App Store’da bir varlık istediğinizde maliyetini çıkarır. Bunların hiçbiri fikrinizde merkezi değilse, on binlerce dolarlık bir uygulama yanlış ilk adımdır ve iyi bir ortak bunu satmak yerine size söyler, çünkü uzun vadeli bir ilişkinin, ihtiyacınız olmayan bir uygulamayı satmaktan daha değerli olduğunu bilir.
Bir native uygulama doğru seçim olduğunda ise, satın aldığınız şey gerçek kullanıcıların tercih ettiği hızlı, iyi tasarlanmış bir üründür, büyümek için inşa edilmiş, atılmak için değil. Tek çatı altında tasarlayıp inşa eden bir ekip, bizim yaptığımız gibi, bütçenize göre bir MVP tanımlar, native inşa eder ve şişiren aktarım boşlukları olmadan App Store’a taşır, üstelik kalem kalem savunabileceğiniz bir fiyatla. Doğru ekibi seçmek için mobil uygulama ajansı nasıl seçilir rehberimize bakın, örnekleri çalışmalarımızda görün ve fikriniz için dürüst, net ve kalem kalem savunabileceğiniz bir tahmini kısa bir görüşmede alın.
FAQ
Mobil uygulama yaptırmak ne kadar tutar?
İyi yapılmış native bir iOS uygulaması genellikle 20.000 ile 120.000 dolar arasında değişir. Birkaç çekirdek özelliğe sahip odaklı bir ilk sürüm alt sınırda; karmaşık bir backend ve entegrasyonlar içeren çok özellikli bir uygulama çok daha yüksekte yer alır. Aralık geniştir çünkü fiyatı coğrafya değil kapsam belirler: ne yaptırdığınız ve kaç sistemle bağlandığı toplamı değiştirir.
App fiyatları neden bu kadar farklı?
Çünkü kapsam her şeyden çok değişir. Aynı uygulamayı isteyen iki kişi beş ekran ya da elli ekran kastediyor olabilir. Tasarım derinliği, backend karmaşıklığı, entegrasyonlar ve lansmanın ne kadar cilalı olması gerektiği fiyatı hareket ettirir. Belirsiz bir brief geniş bir teklif alır; net tanımlı bir uygulama, planlayabileceğiniz sıkı bir teklif alır. Saatlik ücret, saat sayısından daha az önemlidir.
Ucuz şablon uygulamalardan neden kaçınmalıyım?
Çünkü ucuz şablon çoğu zaman en pahalı seçenektir. Şablon renkleri ve logoyu değiştirir ama altta herkesle aynı genel yapıyı korur, markanıza uymaz ve büyüdükçe sınırlarına çarparsınız. Kötü yapılmış bir uygulama yavaş çalışır, kullanıcı kaybettirir ve sonunda yeniden yaptırmak gerekir. Ciddi bir uygulama için gerçek bir native uygulama farkı fazlasıyla hak eder.
Daha ucuz bir MVP ile başlayabilir miyim?
Evet ve önerilen yol budur. Çekirdek işi iyi yapan odaklı bir ilk sürüm, tüm vizyonun küçük bir bölümüne mal olur ve gerçek kullanıcılarla neyin işe yaradığını gösterir. Neredeyse her başarılı uygulama küçük başladı. Kimse denemeden her özelliği yaptırmak, modelin işe yarayıp yaramadığını öğrenmenin en pahalı yoludur.
Lansmandan sonra hangi gizli maliyetler var?
Bir uygulama tek seferlik bir alım değildir. Yılda geliştirme maliyetinin yaklaşık yüzde 15-20'sini bakıma, kullanıcılarla büyüyen aylık bir sunucu maliyetine ve yıllık Apple Developer Program ücretine ayırın. En derin gizli maliyet ucuz koddur: ucuz bir yapım çoğu zaman değiştirilmesi ve bakımı pahalı hale gelir, böylece baştaki tasarruf sonradan daha büyük bir faturaya dönüşür.