Mobil uygulama yaptırmak ne kadar sürer ve neye mal olur?

Mobil uygulama fikriniz var, fakat aldığınız teklifler farklı bütçeler ve teslim tarihleri mi söylüyor? Aynı görünen uygulamaların arkasında farklı iş kuralları, yönetim ekranları ve entegrasyonlar bulunabilir. Bu rehber, ilk sürümünüzü tanımlamanızı, süreyi gerçekçi planlamanızı ve bütçeyi hangi kalemlerle hesaplayacağınızı gösterir.

Önce hangi uygulamayı yaptıracağınızı netleştirin

Bir servis işletmesinin müşterilerine randevu aldırmak istediğini düşünün. Müşteri hizmet seçsin, boş saatleri görsün ve randevusunu oluştursun; çalışan da yönetim panelinden takvimi düzenlesin. Bu, sınırları çizilebilen bir ilk sürümdür.

Aynı projeye kapora, paket üyelik, çoklu şube, personel primi ve muhasebe bağlantısı eklediğinizde farklı bir iş yükü ortaya çıkar. Ekran sayısı aynı kalsa bile arkadaki kurallar çoğalır. Bu nedenle “on ekranlık uygulama” tanımı, tek başına fiyat veya teslim tarihi belirlemeye yetmez.

• Kullanıcılar: Müşteri, çalışan ve yönetici hangi işlemleri yapacak?
• Temel akış: Randevu oluşturma, değiştirme ve iptal nasıl işleyecek?
• Veri: Hizmetler ve çalışan takvimleri nereden alınacak?
• Başarı koşulu: İlk sürümün çalıştığını hangi senaryolarla kabul edeceksiniz?

İlk çalışan sürüm, yani MVP, gerçek müşterinin temel işini tamamlayabildiği sınırlı üründür. Örneğimizde sadakat puanı sonraki sürüme kalabilir; aynı saatin iki müşteriye satılmasını önlemek ise ertelenemez. “Sonra ekleriz” kararını özellik adlarına değil, işletmenin çalışması için gerekli kurallara göre verin.

İhtiyacınız yalnızca tanıtım ve basit bir talep formuysa önce mobil uyumlu web sitesi seçeneğini değerlendirin. Müşterinin düzenli geri döndüğü, cihaz özelliklerinden yararlandığı veya çevrimdışı işlem yaptığı bir deneyim hedefliyorsanız uygulama seçeneğini ayrıca inceleyin.

Mobil uygulama maliyeti nasıl hesaplanır?

Geliştirme bütçesini anlamanın pratik yolu, işi parçalara ayırıp her parçanın iş yükünü hesaplamaktır. Kişi-gün, bir kişinin bir günlük çalışmasını temsil eder. Analiz, tasarım, mobil geliştirme, sunucu, yönetim paneli, test ve proje koordinasyonu bu hesaba dahil edilmelidir.

Aşağıdaki tablo, randevu örneği için oluşturulmuş varsayımsal bir hesaplama senaryosudur. Rakamlar piyasa araştırması, gerçekleşmiş müşteri projesi veya Navdion fiyat teklifi değildir. Amacı, teklifin toplamına hangi işlerin girdiğini görünür kılmaktır.

Yalnızca hesap yöntemini göstermek için kişi-gün bedelini 5.000-8.000 TL varsayarsak, bu iş yükü 300.000-480.000 TL geliştirme bütçesi üretir. Orta örnekte 60 × 6.000 TL = 360.000 TL olur. Bu tutarlar KDV, mağaza hesapları, altyapı ve üçüncü taraf hizmetlerini içermez; güncel piyasa fiyatı olarak kullanılmamalıdır.

Gerçek bütçe için tedarikçiden hem iş yükünü hem fiyatın dayandığı varsayımları isteyin. Hazır bir altyapının kullanılması işi azaltabilir; eski bir sistemin belgelenmemiş bağlantıları ise yeni iş çıkarabilir. Web tarafındaki benzer ayrımı web sitesi maliyetini belirleyen faktörler yazısında da inceleyebilirsiniz.

Mobil uygulama yaptırmak ne kadar sürer?

İş yükü ile takvim süresi farklıdır. Altmış kişi-günlük iş, tek kişinin altmış gün boyunca kesintisiz çalışacağı anlamına gelmediği gibi, altı kişiyle on günde biteceği anlamına da gelmez. Tasarım kararları, birbirine bağlı görevler ve sizin vereceğiniz onaylar teslim tarihini etkiler.

Örnek randevu uygulaması için 8-12 haftalık bir planlama varsayımı kullanılabilir. Bu aralık; kapsamın sabit kalması, tasarım ve geliştirme rollerinin kısmen paralel çalışması, dış sistem erişimlerinin hazır olması ve düzenli geri bildirim verilmesi koşuluna dayanır. Bir sektör ortalaması veya teslim taahhüdü değildir; mağaza hesap doğrulaması ve inceleme beklemeleri ayrıca planlanmalıdır.

1. 1-2. haftalar: İş akışını netleştirin, kabul koşullarını yazın ve prototipi onaylayın.
2. 3-6. haftalar: Mobil ekranları, sunucu işlevlerini ve yönetim panelini birlikte geliştirin.
3. 7-8. haftalar: Gerçek cihazlarda test yapın, işletme ekibinin kabul çalışmasını tamamlayın.
4. 9-12. haftalar: Gerekli düzeltmeler, pilot kullanım ve yayın hazırlığı için planlama payı ayırın.

“Bitti” kelimesini de tanımlayın: Telefonda çalışan deneme sürümü mü, işletmenizin kabul ettiği ürün mü, mağazada indirilebilir uygulama mı? Sözleşmedeki kilometre taşlarını bu çıktılarla ilişkilendirin. Aksi durumda geliştirme tamamlandığı hâlde açılış kampanyanızın beklediği bir durum yaşayabilirsiniz.

Google, 13 Kasım 2023 sonrasında açılan kişisel geliştirici hesaplarında üretim erişimine başvurmadan önce en az 12 test kullanıcısının kesintisiz 14 gün kapalı teste katılmış olmasını istiyor. Bu şart her şirket hesabına uygulanıyormuş gibi yorumlanmamalıdır; hesabınızın türüne göre kontrol edin. Kaynak: Google Play test gereklilikleri, kontrol tarihi 27 Ekim 2026.

Hangi kararlar süreyi ve bütçeyi büyütür?

Platform seçimi ve mevcut sistem bağlantıları

Android ve iOS için ortak kod tabanı değerlendirmek, bazı geliştirme işlerini paylaşmanızı sağlayabilir. Ancak kamera, konum, bildirim ve çevrimdışı veri gibi ihtiyaçlar platforma özgü çalışma gerektirebilir. Tek kod tabanını, iki platformun test ve yayın işlerinin ortadan kalkacağı şeklinde değerlendirmeyin.

Entegrasyonda “muhasebeye bağlanacak” ifadesi yeterli değildir. Hangi verinin hangi yönde aktarılacağı, bağlantı kesilince ne olacağı ve test ortamını kimin sağlayacağı belirlenmelidir. Tekliften önce örnek veri ve bağlantı dokümanı paylaşmanız, belirsizlikleri erken ortaya çıkarır.

Ödeme, roller ve istisna senaryoları

Tek şubenin randevu takvimiyle birden fazla işletmenin hizmet sattığı platformun kapsamı aynı değildir. Farklı satıcılar, iadeler, komisyonlar ve mutabakat ayrı süreçler doğurur. Satış odaklı bir uygulama planlıyorsanız e-ticaret başlangıç rehberindeki operasyon hazırlığını da dikkate alın.

Asıl iş yükü bazen olağan akıştan çok istisnalardadır: Müşteri işlem sırasında internetini kaybederse ne olacak? Aynı randevuya eş zamanlı iki talep gelirse hangisi kabul edilecek? Bu sorulara geliştirmeden önce yanıt vermek, sonradan yeniden yapılan işleri azaltabilir.

Yayın sonrası hangi giderleri ayırmalısınız?

Uygulamanın ilk teslim bedeli, tüm kullanım ömrünün maliyeti değildir. İlk yıl bütçenizde geliştirme, kurulum, düzenli işletim ve değişiklik taleplerini ayrı kalemler hâlinde görün. Her kalemin ödeme periyodunu ve kullanım arttığında nasıl değişeceğini sorun.

• Mağaza hesapları: Apple Developer Program yıllık 99 ABD dolarıdır; yerel fiyat bölgeye göre değişebilir. Kaynak: Apple üyelik bilgileri, 27 Ekim 2026 kontrolü.
• Google Play kaydı: Tek seferlik kayıt bedeli 25 ABD dolarıdır. Kaynak: Google Play Console kayıt bilgileri, 27 Ekim 2026 kontrolü.
• Altyapı ve kullanım: Sunucu, dosya depolama, yedekleme, izleme, SMS ve harita gibi hizmetler için ayrı teklif alın.
• Bakım ve geliştirme: Hata düzeltme garantisini, işletim sistemi uyumunu ve yeni özellik taleplerini ayrı tanımlayın.

Mağaza kayıt ücretleri, uygulama içindeki satışlara ilişkin olası komisyonlarla aynı kalem değildir. Gelir modeliniz belli olduğunda ilgili mağazanın güncel koşullarını ayrıca inceleyin. Dövizli giderleri bütçeye aktarırken ödeme tarihindeki kur ve uygulanabilecek vergileri hesaba katın.

Altyapı için gelişigüzel sabit tutar belirlemek yerine beklenen aktif kullanıcıyı, işlem sıklığını ve dosya hacmini paylaşın. Örneğin fotoğraf yüklemeyen randevu sistemiyle yoğun video saklayan uygulamanın ihtiyacı farklıdır. İlk ayın kullanımını ölçüp bütçeyi buna göre güncelleyecek bir takip düzeni kurun.

Teklif almadan önce hangi soruları sormalısınız?

Tedarikçilere aynı kısa ihtiyaç belgesini gönderin. Örneğimizde belge; müşteri kaydı, uygun saat seçimi, iptal sınırı, yönetici yetkileri, bildirim türü ve hedef platformları içermelidir. Tasarım örnekleriyle birlikte kapsam dışındaki özellikleri de yazın.

• Teslimler: Kaynak kod, tasarım dosyaları, kurulum dokümanı ve yönetim eğitimi dahil mi?
• Hesap sahipliği: Mağaza, sunucu ve dış hizmet hesaplarının kontrolü kimde olacak?
• Kabul: Hangi cihazlarda, hangi senaryolarla test yapılacak; hatalar nasıl önceliklendirilecek?
• Değişiklik: Yeni isteklerin fiyat ve takvim etkisi kim tarafından, nasıl onaylanacak?
• Destek: Garanti süresi, yanıt süreleri, yedekleme ve bakım kapsamı açık mı?

Sık yapılan hata, bütün özellikleri ilk sürüme sıkıştırıp test zamanını kısmaktır. Bütçe sınırınız varsa önce sonradan eklenebilecek özellikleri erteleyin. Temel akışın doğruluğu ve işletmenin uygulamayı yönetebilmesi, gösterişli fakat tamamlanmamış ekranlardan daha fazla değer taşır.

Sonuç: Önce kapsamı yazın, sonra bütçeyi karşılaştırın

Mobil uygulama için güvenilir süre ve maliyet hesabı, kullanıcı akışlarıyla başlar; iş yükü, ekip kapasitesi ve yayın bağımlılıklarıyla tamamlanır. Bugün ilk adım olarak tek sayfalık bir ihtiyaç listesi hazırlayın ve ilk sürümde bulunmayacak özellikleri de belirtin. Navdion ile kapsamı ve uygulanabilir bir başlangıç planını değerlendirmek için ücretsiz proje analizi talep edebilirsiniz.