Mobil uygulama yaptırmanın maliyeti tek bir rakamla söylenemez; çünkü fiyatı belirleyen şey "uygulama" kelimesi değil, uygulamanın ne yaptığıdır. Aynı adı taşıyan iki proje arasında kat kat fark olabilir. Bu yazıda bir teklifin içindeki kalemleri tek tek açıyoruz; okuduktan sonra hem kendi projenizin bütçesini kabaca tahmin edebilir hem de aldığınız teklifleri anlamlı biçimde karşılaştırabilirsiniz.
Mobil uygulamanın fiyatını en çok ne etkiler?
En büyük etken kapsamdır: uygulamada kaç ekran, kaç kullanıcı rolü ve kaç farklı iş akışı olduğu. Bir randevu alma uygulaması ile ödeme alan, stok düşen ve fatura kesen bir uygulama arasındaki fark, ekran sayısından çok arkadaki iş kurallarından gelir. Her yeni kural (iade, indirim, yetki, onay adımı) hem geliştirme hem test süresini artırır.
Kapsamı netleştirmenin en iyi yolu, uygulamayı kullanacak kişilerin yapacağı işleri cümle cümle yazmaktır: "Müşteri ürünü sepete ekler", "Yönetici siparişi onaylar", "Kurye teslimatı işaretler". Bu liste, teklif verecek ekibin işi doğru fiyatlamasını sağlar.
Hangi özellikler karmaşıklığı hızla artırır?
Bazı özellikler kâğıt üzerinde tek satırdır ama arkasında ciddi bir iş yükü taşır. Teklifiniz beklediğinizden yüksek geldiyse önce bu kalemlere bakın:
- Çevrimdışı çalışma: İnternet yokken girilen verinin telefonda saklanması ve bağlantı gelince sunucuyla çakışmadan eşitlenmesi gerekir. İki kişi aynı kaydı aynı anda değiştirdiğinde hangisinin geçerli olacağı ayrıca tasarlanır.
- Gerçek zamanlı özellikler: Canlı sohbet, kurye takibi ya da anlık sipariş ekranı, sunucuyla sürekli açık bir bağlantı ve buna uygun bir altyapı ister.
- Roller ve yetkiler: "Şube müdürü yalnızca kendi şubesinin raporlarını görsün" gibi bir kural, her ekranda ve her veri sorgusunda kontrol edilmesi gereken bir mantık demektir.
- Ödeme: Tek seferlik ödeme ile abonelik, iade ve kısmi iade akışları birbirinden farklıdır. Uygulama içinde dijital içerik satılıyorsa mağazaların kendi satın alma sistemlerini kullanma kuralı da devreye girer.
- Çoklu dil: Metinlerin çevrilmesinin ötesinde tarih, para birimi ve sağdan sola yazılan diller gibi düzen farklılıkları da ele alınır.
iOS, Android ya da ikisi birden: platform seçimi bütçeyi nasıl değiştirir?
Çoğu iş uygulaması için iki platformu tek kod tabanıyla çıkarmak en ekonomik yoldur. Bugün çoğu iş uygulaması iki platformda birden yayınlanıyor ve burada iki yol var:
- Çapraz platform (React Native, Flutter gibi): Tek kod tabanından iOS ve Android çıkar. Çoğu iş uygulaması için hem daha hızlı hem daha ekonomiktir.
- Native (Swift ve Kotlin ile ayrı ayrı): Her platform için ayrı geliştirme yapılır. Kamera, sensör, arka planda çalışma gibi cihaza yakın özelliklerin yoğun olduğu ya da en üst düzey performansın şart olduğu ürünlerde tercih edilir.
Teklif alırken hangi yaklaşımın önerildiğini ve neden önerildiğini sorun. Gerekçesi açıklanamayan bir native önerisi bütçeyi gereksiz yere büyütebilir; tersine, cihaza çok bağımlı bir ürün için çapraz platform ısrarı ileride sorun çıkarabilir.
Tasarım ayrı bir kalem midir?
Evet, ve çoğu zaman en çok küçümsenen kalemdir. Mobil uygulama tasarımı üç katmandan oluşur:
- Kullanıcı akışı (UX): Kullanıcının bir işi kaç adımda, hangi sırayla yaptığı.
- Arayüz (UI): Renk, tipografi, bileşenler ve ekranların son görünümü.
- Prototip: Geliştirmeye başlamadan önce tıklanabilir bir taslakla akışın test edilmesi.
Tasarımı atlayıp doğrudan koda geçen projeler genellikle geliştirme sırasında defalarca geri döner; bu da maliyeti tasarımdan tasarruf edilen miktarın üzerine çıkarır.
Arka uç (backend) ve yönetim paneli neden fiyatı büyütür?
Çünkü kullanıcının telefonda gördüğü kısım işin yalnızca yarısıdır. Verilerin saklandığı sunucu, kullanıcı hesapları, bildirimler ve sizin içeriği yönettiğiniz yönetim paneli ayrı birer geliştirme işidir. "Basit bir uygulama" diye başlayan projelerin bütçesi genellikle burada büyür, çünkü panelin varlığı baştan konuşulmamıştır.
Teklif alırken şunu netleştirin: Yönetim paneli teklife dahil mi? Dahilse hangi işlemleri yapabiliyor? Ürün ekleme, sipariş durumunu değiştirme, kullanıcıyı engelleme, rapor alma ve toplu bildirim gönderme gibi işlemleri tek tek sorun. Panelde olmayan her işlem, ileride ya geliştiriciye iş olarak döner ya da veritabanında elle yapılır.
Ekip yapısı fiyatı nasıl etkiler?
Fiyatın bir kısmı da projede kimlerin çalıştığından gelir. Sağlıklı bir mobil projede genellikle bir proje yöneticisi ya da analist, bir tasarımcı, mobil ve arka uç geliştiriciler ile test sorumlusu bulunur. Küçük ekiplerde bu roller aynı kişide birleşebilir; önemli olan rolün hiç yok sayılmamasıdır.
Tek bir serbest geliştiricinin teklifi çoğu zaman daha düşüktür, çünkü tasarım, test ve proje yönetimi genellikle teklifin içinde değildir ya da sizden beklenir. Karşılaştırırken bu işlerin kimin sorumluluğunda olduğunu yazılı olarak isteyin.
Entegrasyonlar maliyete ne ekler?
Uygulamanın konuşacağı her dış sistem ayrı bir iş kalemidir:
- Ödeme altyapısı (sanal POS, abonelik)
- e-Fatura ve e-Arşiv entegratörleri
- Kargo firmaları
- Muhasebe ya da ERP yazılımları
- Harita, SMS, e-posta ve WhatsApp servisleri
Her entegrasyonun kendi dokümantasyonu, test ortamı ve hata senaryoları vardır. Bazılarının ayrıca aylık ya da işlem başı ücreti olur; bu ücretler geliştirme bedelinin dışında kalır.
Entegrasyon maliyetini en çok karşı tarafın altyapısı belirler. Belgelenmiş, test ortamı olan bir servise bağlanmak öngörülebilir bir iştir; dokümanı olmayan eski bir sisteme bağlanmak ise önce onu çözmeyi gerektirir. Kullandığınız yazılımların adlarını teklif aşamasında paylaşın.
Yayın sonrası maliyetler: bakım, sunucu, mağaza
Uygulama mağazaya çıktığında harcama bitmez. Bütçeye şunları da ekleyin:
- Sunucu ve altyapı: Kullanıcı sayısıyla birlikte artar.
- Mağaza üyelikleri: Apple yıllık geliştirici üyeliği ister, Google Play tek seferlik kayıt ücreti alır.
- Bakım: iOS ve Android her yıl yeni sürüm çıkarır; uygulamanın bu sürümlere uyarlanması gerekir.
- Geliştirme yol haritası: Kullanıcı geri bildirimleriyle gelen yeni özellikler.
Bakım için ayrı bir anlaşma yapılıp yapılmayacağını en baştan konuşmak, yayından sonraki sürprizleri önler.
Tekliflerde sıkça unutulan kalemler
Aşağıdaki işler küçük görünür, ama teklifte yer almıyorsa birinin bunları yapması ve birinin ödemesi gerekir:
- Mağaza incelemesi: Apple ve Google uygulamaları yayına almadan önce inceler. Ret gelirse gerekçeye göre düzeltme yapılıp yeniden gönderilir. Bu turların teklife dahil olup olmadığını sorun.
- Bildirim altyapısı: Push bildirimleri için servis kurulumu, sertifikalar ve panelden bildirim gönderme ekranı ayrı bir iştir.
- Analitik ve hata raporlama: Kullanıcıların uygulamayı nasıl kullandığını ve uygulamanın nerede çöktüğünü görmenizi sağlayan araçların kurulması. Bunlar olmadan yayından sonra kör uçarsınız.
- Yasal metinler ve KVKK ekranları: Aydınlatma metni, açık rıza onayları, hesap silme seçeneği ve gizlilik politikası. Metinleri hukukçunuz hazırlar, ama uygulamada gösterilmeleri ve onayların kaydedilmesi geliştirme işidir.
- İçerik girişi: Ürünlerin, kategorilerin ve görsellerin sisteme ilk kez girilmesi. Yüzlerce ürününüz varsa bunu kimin yapacağını baştan kararlaştırın.
Basit ve karmaşık bir uygulamayı yan yana koyalım
Aynı sektörde iki hayali işletme düşünün. Birincisi tek şubeli bir pastane; müşterilerinin telefondan sipariş verip dükkândan teslim almasını istiyor. İkincisi birden fazla şubesi olan bir pastane zinciri; eve teslimat, kurye takibi ve sadakat puanı istiyor.
| Kalem | Tek şubeli pastane | Çok şubeli zincir |
|---|---|---|
| Kullanıcı rolleri | Müşteri, yönetici | Müşteri, şube personeli, kurye, merkez yöneticisi |
| Ödeme | Kapıda ödeme ya da tek seferlik kartla ödeme | Kartla ödeme, iade, puanla indirim |
| Gerçek zamanlı özellik | Yok, sipariş durumu bildirimle iletilir | Canlı kurye konumu |
| Yönetim paneli | Ürün ve sipariş yönetimi | Şube bazlı yetki, stok, raporlar, kampanyalar |
| Entegrasyon | Ödeme altyapısı | Ödeme, e-Fatura, harita, SMS, muhasebe |
İki uygulama da "sipariş uygulaması" olarak anılır. Ancak ikincisinde her satır, ayrı tasarım, geliştirme ve test emeği demektir. Teklif karşılaştırırken kendi projenizin bu tablonun hangi sütununa yakın olduğunu bilmek, gelen fiyatların makul olup olmadığını anlamanın en hızlı yoludur.
Bütçeyi düşürmenin doğru yolu: önce MVP
Bütçe sınırlıysa özellik kesmek yerine sırayı değiştirin. Ürünün değerini kanıtlayan en küçük sürümü (MVP) önce çıkarıp gerçek kullanıcıyla test etmek, tüm özellikleri tek seferde yaptırmaktan hem daha ucuz hem daha az risklidir. Bu yaklaşımı MVP nedir yazımızda ayrıntılı anlattık.
Kaliteden ödün vermeden maliyeti düşürmenin yolları
- Hazır bileşen kullanın: Giriş, ödeme formu ve harita gibi parçalar için olgun hazır çözümler varken bunları sıfırdan yazdırmayın.
- Panel için sade bir arayüz kabul edin: Yönetim panelini yalnızca siz ve ekibiniz kullanacaksa, onu müşteriye dönük ekranlar kadar özenli tasarlatmak şart değildir.
- Kararları hızlı verin: Geliştirme ekibi sizden onay bekledikçe takvim uzar ve ekip başka işe geçip geri döner. Tek bir karar vericinin olması maliyeti doğrudan etkiler.
- İçeriği kendiniz hazırlayın: Metinler, ürün görselleri ve kategori listeleri hazır gelirse ekip bunları beklemez.
Test, güvenlik ve tasarımdan kısmak ise tasarruf değildir; bu kalemlerin eksikliği yayından sonra daha pahalı düzeltmeler olarak geri gelir.
Ucuz teklifte hangi işaretlere dikkat etmeli?
Düşük fiyat tek başına sorun değildir; sorun, düşüklüğün nereden geldiğinin belli olmamasıdır. Şu işaretleri gördüğünüzde soru sorun:
- Teklif tek satırdan oluşuyor, hangi ekranların ve özelliklerin dahil olduğu yazmıyor.
- Yönetim paneli, test ya da mağazaya yükleme hakkında hiçbir şey söylenmiyor.
- Kaynak kodun size teslim edilip edilmeyeceği belirsiz.
- Ekip daha önce yaptığı mobil uygulamaları gösteremiyor ya da gösterdiği uygulamalar mağazada bulunamıyor.
- Kapsamınızı dinlemeden, ilk görüşmede kesin fiyat veriliyor.
Bir ekibin gerçekten yayınlanmış işlerini görmek bu soruların çoğunu yanıtlar; bizim projelerimize portfolyo sayfamızdan bakabilirsiniz. Firma seçerken sorulacak diğer sorular için Konya'da yazılım firması seçme rehberimiz de işinize yarar.
Doğru teklif almak için hazırlamanız gerekenler
Teklif isteyeceğiniz ekiplere aynı belgeyi gönderin; ancak böyle karşılaştırılabilir fiyatlar alırsınız:
- Uygulamanın tek cümlelik amacı
- Kullanıcı rolleri (müşteri, yönetici, personel…)
- Her rolün yapacağı işlerin listesi
- Olmazsa olmaz entegrasyonlar
- Benzer bulduğunuz uygulamalar ve neyini beğendiğiniz
- Hedef yayın tarihi
Gelen teklifleri değerlendirirken nelere bakmanız gerektiğini yazılım teklifi değerlendirme rehberimizde topladık.
Sık sorulan sorular
Hazır bir uygulama şablonu kullanmak daha mı ucuz?
Başlangıçta evet. Ancak şablonlar sizin iş akışınıza göre değil, genel ihtiyaca göre yazılır. Özelleştirme ihtiyacı arttıkça şablonu değiştirmek, sıfırdan doğru kurgulanmış bir yapıdan daha pahalı hâle gelebilir. Karar için hazır yazılım ve özel yazılım karşılaştırmamıza bakabilirsiniz.
Sabit fiyat mı, saatlik ücret mi?
Kapsamı net projelerde sabit fiyat bütçe kontrolü sağlar. Kapsamı belirsiz ya da sürekli değişecek projelerde aşamalı (sprint bazlı) çalışmak daha sağlıklıdır. Önemli olan, kapsam değiştiğinde fiyatın nasıl güncelleneceğinin yazılı olmasıdır.
Sabit fiyatta riski ekip üstlenir, bu yüzden belirsiz kalemlere bir pay ekler ve kapsam dışı her isteği ek iş olarak değerlendirir. Saatlik ya da aşamalı çalışmada esneklik sizdedir, ama bütçeyi takip etme sorumluluğu da size geçer. Pratikte iyi işleyen yol, tasarım ve ilk sürümü sabit fiyatla, sonraki geliştirmeleri aşamalı olarak yürütmektir.
Teklifler arasında neden bu kadar fark oluyor?
Çoğu zaman ekipler aynı işi fiyatlamıyordur. Biri yönetim panelini, testi ve mağaza yüklemesini dahil etmiştir, diğeri etmemiştir. Farkın kaynağını bulmak için tekliflerin kalem kalem dökümünü isteyin ve aynı başlıkları yan yana koyun.
Mağaza uygulamayı reddederse ek ücret öder miyim?
Bu, sözleşmenize bağlıdır. Ret, ekibin yaptığı bir hatadan kaynaklanıyorsa düzeltmenin teklife dahil olması beklenir. Ret, sizin içeriğinizden ya da iş modelinizden kaynaklanıyorsa (örneğin mağaza kurallarına uymayan bir ödeme yöntemi) yapılacak değişiklik ek iş sayılabilir. Bu ayrımı teklif aşamasında yazılı hâle getirin.
Kaynak kodu bana ait olacak mı?
Olmalı. Sözleşmede kaynak kodun, tasarım dosyalarının ve mağaza hesaplarının mülkiyetinin size ait olduğu açıkça yazmalı.
Uygulama fikrinizi konuşmak ve kapsamınıza göre net bir tahmin almak isterseniz mobil uygulama geliştirme sayfamıza göz atabilir ya da doğrudan bize yazabilirsiniz.