Mobil Uygulama Yaptırma Fiyatları: Teklifler Nasıl Karşılaştırılır?

Mobil uygulama yaptırma fiyatları tek bir rakamla açıklanamaz; fiyatı uygulamanın hangi platformlarda çalışacağı, kaç ekran ve özellik içereceği, arkasında bir sunucu ve yönetim paneli olup olmadığı, hangi sistemlerle konuşacağı ve tasarımın ne kadar özgün olacağı belirler. Bu yüzden iki teklifi karşılaştırmanın doğru yolu toplam tutara değil, her teklifin neyi kapsadığına bakmaktır. Kapsamı bilinmeyen bir uygulama için verilen rakam yanıltıcı olacağından bu yazıda fiyat vermiyoruz; aşağıda fiyatı belirleyen etkenleri, bir teklifte bulunması gereken kalemleri ve düşük görünen teklifin sonradan çıkarabileceği maliyetleri sırayla ele alıyoruz.

Mobil uygulama maliyetini belirleyen etkenler

Mobil uygulama maliyeti, büyük ölçüde harcanacak uzman emeğinden oluşur. Emeği artıran ya da azaltan her karar fiyata yansır. Aşağıdaki etkenler, iki teklif arasındaki farkın çoğunu açıklar.

Platform ve teknoloji

Uygulamanın yalnız iOS'ta mı, yalnız Android'de mi, yoksa ikisinde birden mi çalışacağı ilk belirleyicidir. İki platform için ayrı native uygulama yazmak, aynı işi iki kez yapmak anlamına gelir. Cross-platform yaklaşım tek kod tabanıyla iki platforma çıkar ve çoğu projede toplam emeği azaltır.

Native, hibrit ve cross-platform yaklaşımların farklarını ayrı bir yazıda karşılaştırdık. Tekliflerde önerilen teknolojinin ve gerekçesinin açıkça yazılması, iki teklifi karşılaştırmanın ön koşuludur.

Özellik ve ekran sayısı

Her ekran tasarlanır, geliştirilir ve test edilir. Üyelik, ödeme, harita, mesajlaşma, bildirim, çoklu dil, çevrimdışı çalışma gibi özelliklerin her biri ayrı bir iş kalemidir. Kullanıcı rolleri arttıkça (müşteri, kurye, yönetici gibi) ekran ve kural sayısı da artar.

Arka uç ve yönetim paneli

Mobil uygulamanın kullanıcıya görünen kısmı çoğu zaman işin yalnız bir bölümüdür. Veriyi saklayan sunucu, uygulamanın konuştuğu API ve içeriği yöneteceğiniz panel ayrı geliştirme gerektirir. Bazı tekliflerde bu kısım dahil, bazılarında hariçtir; karşılaştırmada en sık gözden kaçan fark budur.

Entegrasyonlar

Uygulamanın ödeme altyapısı, ERP, CRM, muhasebe ya da kargo sistemiyle veri alışverişi yapması gerekiyorsa her bağlantı ayrı bir iştir. Bağlanılacak sistemin iyi belgelenmiş bir arayüzü olup olmaması emeği doğrudan etkiler. Yazılımları birbirine bağlama yöntemlerini ayrı yazımızda anlattık.

Tasarım

Hazır bir arayüz kitiyle kurulan ekranlar ile markaya özel tasarlanan, kullanıcı araştırmasıyla desteklenen bir arayüz aynı emeği gerektirmez. Tasarımın tıklanabilir bir prototiple test edilip edilmeyeceği de kapsamı değiştirir.

Güvenlik, veri ve test

Kişisel veri, ödeme ya da sağlık bilgisi işleyen uygulamalar ek güvenlik önlemleri, yetkilendirme ve kayıt tutma gerektirir. Test kapsamı da fiyatı etkiler: kaç farklı cihaz ve işletim sistemi sürümünde test yapılacağı teklifte belirtilmelidir.

Etken	Maliyeti artıran	Maliyeti azaltan
Platform	İki platform için ayrı native geliştirme	Tek platformla başlamak ya da cross-platform
Özellikler	Çok sayıda rol, ödeme, gerçek zamanlı özellikler	İlk sürümü çekirdek özelliklerle sınırlamak
Arka uç	Özel sunucu, karmaşık iş kuralları, raporlama	Mevcut bir sistemin API'sini kullanmak
Entegrasyon	Belgesi zayıf, eski sistemler	İyi belgelenmiş, standart arayüzler
Tasarım	Markaya özel, çok sayıda özel animasyon	Tutarlı bir tasarım sistemi ve bileşen kiti

Teklifleri aynı ölçüyle karşılaştırmak

Farklı ajanslardan gelen teklifler çoğu zaman farklı varsayımlara dayanır. Biri yönetim panelini dahil etmiştir, diğeri etmemiştir; biri iki platform, diğeri tek platform üzerinden hesaplamıştır. Aynı ölçüyle karşılaştırabilmek için önce herkese aynı bilgiyi vermek gerekir.

Bunun en sağlam yolu, ihtiyaçlarınızı yazılı bir talep dokümanında toplamaktır. RFP'nin (teklif talep dokümanı) nasıl hazırlandığını anlattığımız yazı bu konuda iyi bir başlangıçtır. İlk sürümün kapsamını daraltmak da hem maliyeti hem riski düşürür; MVP yaklaşımı tam olarak bunu hedefler.

Teklifler geldikten sonra her birini aşağıdaki gibi bir tabloya işleyin. "Belirsiz" kalan her satır, teklif sahibine sorulacak bir sorudur.

Kalem	Teklif A	Teklif B	Teklif C
Platformlar ve teknoloji	Dahil, belirtilmiş	Dahil, belirtilmemiş	Belirsiz
Tasarım ve prototip	Dahil	Hariç	Dahil
Arka uç ve yönetim paneli	Dahil	Hariç	Kısmen
Entegrasyonlar	Listelenmiş	Belirsiz	Listelenmiş
Test kapsamı	Cihaz listesi var	Belirsiz	Belirsiz
Mağaza yayını	Dahil	Dahil	Hariç
Kaynak kod ve lisans	Açıklanmış	Belirsiz	Açıklanmış
Yayın sonrası destek	Tanımlı	Belirsiz	Tanımlı

Tablodaki değerler yalnız örnektir; amaç, fiyat farkının hangi kalemden geldiğini görünür kılmaktır.

Tablo dolduktan sonra teklif sahipleriyle kısa bir görüşme yapmak, yazılı teklifte görünmeyen farkları ortaya çıkarır. Bu görüşmede şunları sorabilirsiniz:

• Kapsamı nasıl anladınız, bizim ihtiyacımızı kendi cümlelerinizle özetler misiniz?
• Teklifi hazırlarken hangi varsayımları yaptınız?
• Projede kimler çalışacak, bizim tarafımızdan hangi katkıyı bekliyorsunuz?
• Kapsam proje sırasında değişirse bu nasıl fiyatlanacak?
• Kabul testi nasıl yapılacak, bir özelliğin "tamamlandı" sayılması için ölçüt ne?

Cevapların netliği, çoğu zaman rakam kadar bilgi verir. Kapsamı sizinle aynı biçimde anlayan bir ekip, proje sırasında daha az sürprizle karşılaşmanızı sağlar.

Sabit fiyat ve zaman bazlı teklif

Teklifler genellikle iki modelden biriyle hazırlanır. Sabit fiyatlı teklifte kapsam baştan tanımlanır ve tutar bu kapsam için verilir; kapsam değiştiğinde ek teklif gerekir. Zaman bazlı modelde ise harcanan emek belirli aralıklarla faturalanır ve kapsam yolda esneyebilir.

Kapsamı net olan projelerde sabit fiyat bütçeyi öngörülebilir kılar; ihtiyacın kullanıcı geri bildirimiyle şekilleneceği projelerde zaman bazlı model daha esnektir. İki modeli karşılaştırırken tutarın yanında bu esnekliğin sizin için değerini de tartın.

Teklifte bulunması gereken kalemler

Aşağıdaki kontrol listesi, bir mobil uygulama teklifinde yazılı olarak görmeniz gereken başlıkları toplar:

• Uygulamanın hangi platformlarda çalışacağı ve kullanılacak teknoloji
• Ekran ve özellik listesi, kullanıcı rolleri
• Tasarım kapsamı: kaç tasarım turu, prototip ve revizyon yaklaşımı
• Arka uç, API ve yönetim panelinin kapsamı
• Entegre edilecek sistemlerin listesi
• Test kapsamı: cihazlar, işletim sistemi sürümleri, kabul testi süreci
• Mağaza yayını: hesapların kimin adına açılacağı ve yayın sürecinde kimin ne yapacağı
• Sunucu ve barındırma maliyetinin teklife dahil olup olmadığı
• Aşamalar, teslim edilecekler ve ödeme planı
• Kaynak kod ve lisans koşulları
• Yayın sonrası hata düzeltme süresi ve bakım modeli
• Kapsam dışında kalanların açık listesi

Son madde en az ilgi gören ama en çok anlaşmazlık önleyen maddedir. Neyin dahil olmadığını bilmek, neyin dahil olduğunu bilmek kadar önemlidir.

Kaynak kod ve lisans maddesi

Mobil uygulama yaptırırken sorulması gereken en önemli sorulardan biri, uygulamanın kodunun ve kullanım haklarının kimde kalacağıdır. Bu konuda sektörde tek bir standart yoktur; her proje kendi koşullarıyla değerlendirilir ve konunun yazılı hale getirilmesi gerekir.

Teklif aşamasında şu soruların cevabını isteyin:

1. Proje bitiminde kaynak kod teslim edilecek mi, hangi biçimde?
2. Uygulamada kullanılan hazır bileşenler ya da ajansa ait kütüphaneler var mı, bunların lisans koşulları ne?
3. Uygulamayı başka bir ekiple geliştirmeye devam etmek isterseniz buna engel bir durum var mı?
4. Sunucu, alan adı ve mağaza hesapları kimin adına açılacak?

Bu maddeler fiyatı da etkileyebilir. Bu yüzden iki teklifi karşılaştırırken kaynak kod ve lisans koşullarının aynı olup olmadığına da bakın.

Yayın sonrası bakım maliyeti

Uygulama yayına çıktığında maliyet bitmez. Bütçe planlarken şu kalemleri de hesaba katın:

• İşletim sistemi güncellemeleri: Apple ve Google her yıl yeni işletim sistemi sürümleri yayınlar. Uygulamanın yeni sürümlerde sorunsuz çalışması için düzenli güncelleme gerekir.
• Mağaza politikaları: Mağazalar teknik ve içerik gereksinimlerini zaman içinde değiştirir. Örneğin Google Play, uygulamaların güncel bir Android sürümünü hedeflemesini ister ve bu eşik düzenli olarak yükselir; güncel gereksinimler Play Console üzerinden takip edilir.
• Geliştirici hesapları: Apple'ın geliştirici programı yıllık üyelik ücreti, Google Play ise tek seferlik kayıt ücreti ister; güncel tutarlar platformların kendi sayfalarında yer alır.
• Sunucu ve üçüncü taraf hizmetler: Barındırma, bildirim, harita, SMS ya da e-posta servisleri kullanım arttıkça maliyet üretir.
• Hata düzeltme ve küçük geliştirmeler: Gerçek kullanıcıların geri bildirimi, yayın sonrasında yeni bir iş listesi oluşturur.

Bakımın nasıl fiyatlanacağını (aylık sabit, saat bazlı ya da talep bazlı) teklif aşamasında sormak, sonraki yılın bütçesini öngörülebilir kılar.

Bakım için ayrı bir anlaşma yapılacaksa şu başlıkların yazılı olmasına dikkat edin: hangi işlerin bakım kapsamında sayıldığı, bir hata bildirildiğinde ne kadar sürede yanıt verileceği, yeni özellik taleplerinin nasıl tahmin edilip onaylanacağı ve işletim sistemi güncellemelerine uyum çalışmasının kapsama dahil olup olmadığı. Bu maddeler belirsiz kaldığında, küçük bir güncelleme bile beklenmedik bir fatura kalemine dönüşebilir.

Düşük teklifin gizli maliyetleri

Diğerlerinden belirgin biçimde düşük bir teklif her zaman kötü değildir, ama nedenini anlamak gerekir. Düşük fiyatın arkasında sık görülen durumlar şunlardır:

• Yönetim paneli ya da arka uç kapsam dışıdır ve sonradan ayrıca teklif edilir.
• Test tek bir cihazda yapılır; farklı cihazlardaki hatalar yayından sonra ortaya çıkar.
• Tasarım hazır bir şablona dayanır ve markaya uyarlanması ek iş olarak çıkar.
• Kaynak kod teslim edilmez, uygulama başka bir ekibe devredilemez.
• Belgelendirme yapılmaz, her değişiklik için aynı ekibe bağımlı kalınır.
• Sunucu, mağaza hesapları ve üçüncü taraf hizmetlerin maliyeti teklife yansıtılmamıştır.

Bu kalemlerin her biri sonradan eklendiğinde, başlangıçtaki fark kısa sürede kapanabilir.

Bütçeyi planlarken

Uygulama yaptırma fiyatları hakkında teklif toplamaya başlamadan önce kendi bütçe çerçevenizi belirlemek, görüşmeleri daha verimli kılar. Planlarken şu yaklaşımlar işe yarar:

1. Bütçeyi ilk sürüm ve sonrası olarak ikiye ayırın. İlk sürümün geliştirme maliyeti ile yayın sonrası ilk yılın bakım ve geliştirme maliyetini ayrı kalemler olarak düşünün.
2. Aşamalı ödeme isteyin. Tasarım, geliştirme ve yayın gibi aşamalara bağlı ödeme planı, hem sizin hem ekibin riskini dengeler.
3. Belirsizlik payı bırakın. Kullanıcı testleri ve mağaza incelemesi, planlanmamış küçük değişiklikler doğurabilir.
4. Gelir ve tasarruf beklentisini yazın. Uygulamanın hangi işi kolaylaştıracağını ya da hangi geliri destekleyeceğini yazmak, bütçenin makul olup olmadığını değerlendirmenizi sağlar.

Bütçe çerçevesini teklif veren ekiple paylaşmak da faydalıdır. Böylece ekip, o çerçeveye sığacak ilk sürüm kapsamını önerebilir; siz de hayal edilen ürün ile yapılabilecek ürün arasındaki farkı baştan görürsünüz.

Granobra'da nasıl çalışıyoruz

Mobil uygulama projelerinde fiyatı konuşmadan önce kapsamı birlikte netleştiriyoruz: kullanıcılar, ekranlar, bağlanılacak sistemler ve ilk sürümün sınırları. Teklifi bu kapsamın üzerine hazırlıyoruz; kaynak kod ve lisans koşulları teklifte açıklanır, sözleşmede belirlenir.

Granobra, İstanbul merkezli bir dijital ajans olarak mobil uygulama geliştirme projelerinde bu yaklaşımla çalışır. Rakam, ancak kapsam netleştiğinde anlamlı hale gelir.

Sık sorulan sorular

Mobil uygulama yaptırma fiyatları neden bu kadar farklı?

Çünkü teklifler çoğu zaman aynı şeyi fiyatlamaz. Platform sayısı, arka uç ve panelin dahil olup olmaması, tasarım derinliği, test kapsamı ve kaynak kod koşulları tutarı doğrudan değiştirir. Teklifleri kalem kalem aynı tabloya işlemek farkın nereden geldiğini gösterir.

Uygulama geliştirme maliyetini düşürmenin yolu nedir?

İlk sürümü çekirdek özelliklerle sınırlamak en etkili yoldur. Cross-platform yaklaşım, hazır ve tutarlı bir tasarım sistemi ve iyi belgelenmiş entegrasyonlar da emeği azaltır. Kalite kaybı yaratan kısıntılar (test ve belgelendirme gibi) ise sonradan daha pahalıya çıkar.

Mobil uygulama yaptırmak ne kadar sürer?

Süre, fiyat gibi kapsama bağlıdır ve tek bir cevabı yoktur. Sağlıklı bir teklif, işi aşamalara böler ve her aşamanın teslim edilecekleriyle birlikte bir takvim sunar. Takvimin sizin onay ve geri bildirim sürelerinize de bağlı olduğunu hesaba katın.

Yayından sonra ek ödeme çıkar mı?

Çoğu uygulamada evet. İşletim sistemi güncellemeleri, sunucu, geliştirici hesapları ve yeni özellikler yayın sonrasında da maliyet oluşturur. Bu kalemlerin teklif aşamasında konuşulması, sürprizleri önler.

Teklifinizi birlikte netleştirelim

Mobil uygulama yaptırma fiyatlarını karşılaştırırken en güvenilir ölçü, her teklifin neyi kapsadığıdır. Uygulamanızın kapsamını birlikte netleştirmek isterseniz teklif alın; projenizi konuşalım.