Mobil uygulama yaptırmadan önce bilinmesi gerekenler

“Mobil uygulama yaptırma fiyatları” ya da “mobil uygulama yaptırma maliyeti” diye arattığınızda çok geniş bir aralık görürsünüz, çünkü soru eksik: hangi platformlar, ne kadar özellik, kim yönetecek? Bu yazı, bir teklif almadan önce netleştirmeniz gereken şeyleri anlatıyor — rakam vermeden, çünkü rakam kapsamdan bağımsız bir anlam taşımıyor.

İki platform, tek kod tabanı

Bir işletme “mobil uygulama” dediğinde genelde hem iOS hem Android’i kastediyor. Bunları ayrı ayrı, ayrı dillerde (Swift ve Kotlin) yazmak iki kat mühendislik demek. BILPP’de Flutter kullanıyoruz — tek kod tabanından hem iOS hem Android’e çıkan bir çerçeve. Bu, geliştirme süresini kısaltmanın yanında, ileride bir özelliği iki platformda ayrı ayrı bakım etmek zorunda kalmamak anlamına da geliyor. “Önce Android’i yapalım, iOS’u sonra ekleriz” yaklaşımı çoğu zaman gereksiz; ikisini aynı anda çıkarmanın ek maliyeti, sonradan ayrı bir proje olarak eklemekten genelde daha düşük.

Maliyeti belirleyen asıl etkenler

Ekran ve akış sayısı, sayfa sayısından çok daha belirleyici. Bir uygulamanın “kaç ekranı var” sorusu bile yeterli değil; asıl soru her ekranın ne kadar mantık taşıdığı. Bir liste ekranı ile filtrelenebilir, arama yapılabilen, sunucudan canlı veri çeken bir ekran aynı kalemde değil.

Abonelik veya uygulama içi satış olup olmadığı. Bir uygulama ücretli abonelik satıyorsa RevenueCat gibi bir katmanla App Store ve Google Play’in farklı satın alma kurallarını tek yerden yönetmek gerekiyor. Bu, “sadece bir buton ekleyelim” değil; iptal, yenileme, deneme süresi gibi durumların hepsinin doğru yönetilmesi demek.

Sunucu tarafı ihtiyacı. Uygulama sadece cihazda mı çalışıyor, yoksa bir hesap sistemi, bildirimler, sunucuda saklanan veri mi var? İkincisi varsa bu aslında iki proje demek: uygulama ve onu besleyen arka uç.

Mağaza süreci. Kod bitince iş bitmiyor. Mağaza listelemesi, ekran görüntüleri, inceleme başvurusu ayrı bir iş kalemi ve genelde hafife alınıyor.

Etken	Basit uygulama	Karmaşık uygulama
Ekranlar	Sabit, statik içerik	Canlı veri, filtre, arama
Satın alma	Yok	Abonelik + deneme süresi
Arka uç	Yok, tamamen cihazda	Hesap sistemi + bildirimler
Mağaza süreci	Tek seferlik yayın	Düzenli güncelleme takvimi

İki senaryo, iki farklı iş

Bir örnek: bir hizmet işletmesi, müşterilerinin randevu görebileceği, bildirim alabileceği basit bir uygulama istiyor. Ekranlar sabit, veri az değişiyor, satın alma yok. Bu iş görece dar bir kapsam ve birkaç haftalık bir geliştirme döngüsüyle bitebilir.

Başka bir örnek: abonelik satan bir platform, kullanıcı hesabı, deneme süresi, bildirimler, sunucudan gelen canlı veri ve düzenli içerik güncellemesi istiyor. Burada uygulamanın kendisi kadar onu besleyen arka uç da bir proje. Ekran sayısı benzer görünebilir ama ikinci iş, birincinin kat kat üzerinde bir mühendislik yükü taşıyor — çünkü zorluk ekranda değil, ekranın arkasındaki veri akışında.

Bildirimler ve çevrimdışı kullanım gözden kaçan kalemler

Push bildirimi göndermek basit bir özellik gibi görünüyor ama arkasında bir bildirim servisi, kullanıcı izinlerinin yönetimi ve hangi olayın hangi bildirimi tetikleyeceğine dair bir mantık var. Aynı şekilde “internet olmadan da çalışsın” isteği, uygulamanın veri modelini baştan değiştiriyor: cihazda saklanan veri ile sunucudaki veri arasında bir senkronizasyon kurmak gerekiyor. Bu iki özellik, teklif isteğinde nadiren belirtiliyor ama sonradan eklenmesi en pahalı özellikler arasında.

Mağaza süreci gerçekte ne kadar sürer

Bir uygulamayı App Store ve Google Play’e göndermek, “yükle ve bitti” değil. Apple’ın inceleme süreci belirsiz sürebiliyor ve reddedilme sebepleri bazen teknik değil, listeleme metniyle ilgili oluyor. Ekran görüntülerinin her dilde ayrı hazırlanması, açıklama metinlerinin mağaza kurallarına uyması, gizlilik bilgilerinin eksiksiz doldurulması — bunların hepsi geliştirmeden bağımsız, ayrı bir iş yükü. Bu yüzden mağaza sürecini son ana bırakmamak, geliştirmeyle paralel yürütmek gerekiyor.

Var olan bir uygulamayı devralmak

Herkes sıfırdan başlamıyor. Bazen elde eski, bakımı zor bir uygulama var ve soru “bunu devam ettirebilir miyiz” oluyor. Bu durumda önce bir denetim gerekiyor: kod hangi durumda, hangi bağımlılıklar güncel değil, mağaza hesapları kimde, hangi özellik gerçekten kullanılıyor. Bazı projelerde devralıp üzerine inşa etmek mantıklı; bazılarında yeniden yazmak daha az riskli çıkıyor. Bu kararı vermeden önce koda bakmadan rakam vermek gerçekçi değil.

Bir defalık iş değil

Bir mobil uygulama, bir web sitesinden farklı olarak sürekli bakım istiyor: işletim sistemi sürümleri değişiyor, mağaza kuralları güncelleniyor, kullanıcı geri bildirimleri birikiyor. “Bir kere yaptırdım, artık bitti” beklentisiyle giren işletmeler, altı ay sonra mağazadan kaldırılma uyarısı aldıklarında şaşırıyor. Bu yüzden teklif isterken sadece ilk sürümün maliyetini değil, yıl içindeki güncelleme ritmini de sormak gerekiyor — kim, ne sıklıkla, hangi kapsamda güncelleyecek.

Kim yönetecek sorusu unutuluyor

Uygulama yayına girdikten sonra mağaza hesaplarını, kullanıcı yorumlarına yanıt vermeyi, yeni işletim sistemi sürümüyle uyumluluğu kim takip edecek? Bazı işletmeler bu sorumluluğu kendi ekiplerine almak istiyor, bazıları geliştirici ekipte kalmasını tercih ediyor. Her iki seçenek de mümkün ama teklif aşamasında konuşulmazsa yayından sonra belirsizlik doğuruyor — özellikle mağaza hesabı kimin adına açıldıysa gelecekteki güncellemeler de o hesaba bağlı kalıyor.

Nereden başlamalı

Somut bir teklif almadan önce şunları netleştirmek yardımcı oluyor: uygulama hangi problemi çözüyor, para akışı var mı (abonelik, tek seferlik satın alma, hiç yok), sunucu tarafında ne saklanacak ve mağaza hesapları kimin adına açılacak. Bu dört cevap, “kaç ekran” sorusundan çok daha isabetli bir kapsam çizip; teklifi de ona göre anlamlı kılıyor.

BILPP, Flutter ile tek kod tabanından iki platforma çıkan uygulamalar geliştiriyor; mağaza listelemesi, ekran görüntüleri ve inceleme başvurusu sürecin bir parçası. Mevcut bir uygulamayı denetleyip devralmak da mümkün. Mobil uygulama hizmetimize göz atabilir, kendi ürünümüz TrackBil üzerinden nasıl çalıştığımızı görebilir, ya da doğrudan bize yazabilirsiniz.

Kural

Bir mobil uygulama teklifi isterken “kaç ekran” sormayın; “para akışı var mı, arka uç ne kadar ağır, mağaza süreci kimde” sorun. Fiyatı gerçekten belirleyen bu üçü — ekran sayısı değil.