Mobil uygulama yaptırmak: Süreç, teknoloji seçimi ve maliyet rehberi

Mobil uygulama yaptırmak; doğru teknolojiyi seçmek, kapsamı bir ilk sürüme (MVP) indirmek, tasarım, geliştirme, backend ve testten geçip App Store ile Google Play'de yayınlamak ve sonrasında uygulamayı canlı tutmak demektir. Maliyeti ekran sayısı, backend ihtiyacı, entegrasyonlar ve yayın sonrası bakım belirler. Bu rehberde teknoloji seçimini, süreci adım adım, maliyet kalemlerini ve sık yapılan hataları anlatıyoruz.

Uygulamaya gerçekten ihtiyacınız var mı?

Bu soruyu sormak, en çok parayı kurtaran adımdır. Kullanıcılarınız sizinle ayda bir kez etkileşime giriyorsa, mobil uyumlu bir web sitesi veya web paneli çoğu zaman yeterlidir. Mobil uygulama; düzenli ve tekrar eden kullanımın olduğu, bildirimlerin değer yarattığı ya da kamera, konum, çevrimdışı çalışma gibi cihaz özelliklerinin gerektiği durumlarda anlam kazanır.

İyi bir test şudur: Kullanıcı bu uygulamayı telefonunda tutmak için bir neden bulacak mı? Sadakat programı, sipariş takibi, saha ekibinin günlük iş akışı veya sık kullanılan bir hizmet için cevap genellikle evettir. Kurumsal tanıtım için ise çoğu zaman hayırdır.

Önce karar: Native mi, cross-platform mu, PWA mı?

Teknoloji seçimi hem bütçeyi hem uygulamanın ileride nasıl büyüyeceğini belirler. Üç ana yol var:

• Native: iOS için Swift, Android için Kotlin ile iki ayrı uygulama. Cihaz özelliklerine en derin erişim ve en iyi platform uyumu.
• Cross-platform: Flutter veya React Native ile tek kod tabanından iOS ve Android. Çoğu işletme uygulaması için verimli yol.
• PWA (Progressive Web App): Tarayıcıda çalışan, ana ekrana eklenebilen web uygulaması. Mağaza süreci yok; ama cihaz özelliklerine erişim sınırlı.

Çoğu işletme için mantıklı başlangıç noktası cross-platform geliştirmedir. Detaylar için Flutter uygulama geliştirme, platforma özel ihtiyaçlar için iOS ve Android uygulama geliştirme sayfalarımıza bakabilirsiniz.

Mobil uygulama yaptırmak: Süreç adım adım

1. Keşif: Uygulamanın hangi sorunu çözdüğü, kimin kullanacağı ve başarının nasıl ölçüleceği netleşir. Rakip uygulamalar incelenir, kullanıcı akışları çıkarılır.
2. Kapsam ve MVP: Tüm fikirler listelenir, ilk sürüme girecek olanlar seçilir. MVP, kullanıcıya gerçek değer veren en küçük sürümdür; "her şey olsun" listesi değil.
3. UI/UX tasarımı: Önce wireframe, sonra tıklanabilir prototip ve görsel tasarım. Kodlamadan önce akışları test etmek, en ucuz hata ayıklama yöntemidir.
4. Geliştirme: Genellikle 1-2 haftalık sprintlerle ilerlenir; her sprint sonunda test edilebilir bir sürüm paylaşılır.
5. Backend ve API: Kullanıcı hesapları, veritabanı, bildirim servisi, yönetim paneli ve dış sistem bağlantıları bu katmandadır. Birçok projede backend, mobil arayüz kadar emek ister.
6. Test: Farklı ekran boyutları, işletim sistemi sürümleri, zayıf internet bağlantısı ve hata senaryoları test edilir. TestFlight ve Google Play iç test kanalları ile gerçek kullanıcılara kapalı sürüm verilir.
7. Mağaza yayını: Mağaza görselleri, açıklamalar, gizlilik bilgileri ve inceleme süreci (aşağıda ayrıca anlatıyoruz).
8. Yayın sonrası: Hata takibi, kullanıcı geri bildirimleri, işletim sistemi güncellemelerine uyum ve yeni özellikler.

App Store ve Google Play: Hesaplar ve yayın süreci

Uygulamanın mağazalarda sizin adınıza yayınlanması için iki geliştirici hesabı gerekir:

• Apple Developer Program: Yıllık üyelik ücreti 99 USD'dir. Şirket adına yayın için D-U-N-S numarası istenir; bu numaranın alınması zaman alabileceği için sürecin başında başlatılmalıdır.
• Google Play Console: Tek seferlik 25 USD kayıt ücreti vardır. Kimlik ve kurum doğrulaması yapılır; yeni bireysel hesaplarda yayından önce kapalı test şartı uygulanabilir.

Her iki mağaza da uygulamayı yayından önce inceler. Gizlilik politikası bağlantısı, toplanan verilerin beyanı (Apple'da gizlilik etiketleri, Google Play'de veri güvenliği formu), hesap silme imkânı ve test için demo hesap bilgisi en sık istenen kalemlerdir. Dijital içerik ve abonelik satışlarında mağazaların kendi ödeme sistemlerinin kullanılması gerekir; fiziksel ürün ve hizmet satışlarında ise kendi ödeme altyapınızı kullanabilirsiniz. Politikalar zaman zaman değiştiği için yayından önce güncel kuralları kontrol etmek gerekir.

Maliyeti belirleyen kalemler

Mobil uygulama maliyeti, harcanan geliştirme eforuyla doğru orantılıdır. Eforu artıran başlıca kalemler:

• Ekran ve akış sayısı: Her ekran; tasarım, geliştirme, durum yönetimi (yükleniyor, boş, hata) ve test demektir.
• Backend: Hazır bir API'ye bağlanmak ile sıfırdan backend kurmak arasında büyük fark vardır.
• Entegrasyonlar: ERP, CRM, kargo, harita, SMS, e-fatura gibi dış sistemler.
• Ödeme ve uygulama içi satın alma: Sanal POS veya mağaza içi abonelik; fatura, iade ve abonelik yenileme senaryoları dahil.
• Push bildirimler: Basit duyurudan kişiye özel, segmentli ve zamanlanmış bildirimlere kadar farklı seviyeler.
• Çevrimdışı çalışma: Verinin cihazda saklanıp bağlantı gelince senkronize edilmesi, dikkatli tasarım gerektirir.
• Yönetim paneli: İçerik, kullanıcı, sipariş ve raporların yönetildiği web paneli çoğu projede gerekir ve ayrı bir iş kalemidir.
• Çoklu dil, erişilebilirlik ve tablet uyumu.

Kapsamı netleştirmek ve fiyat almak için mobil uygulama yaptırma sayfamızdaki adımlar iyi bir başlangıçtır.

MVP kapsamı nasıl belirlenir?

Kapsamı daraltmanın pratik bir yolu, özellikleri üç gruba ayırmaktır: olmazsa olmaz (uygulamanın ana vaadini yerine getiren akış), olsa iyi olur (deneyimi iyileştiren ama ana vaadi değiştirmeyen özellikler) ve sonra (kullanıcı verisi geldikten sonra karar verilecek fikirler). İlk sürüm yalnızca birinci grubu ve yayın için zorunlu olanları (giriş, hesap silme, gizlilik metinleri, temel analitik) içermelidir.

Örneğin bir randevu uygulamasında olmazsa olmaz akış; hizmet seçmek, uygun saati görmek, randevu almak ve hatırlatma bildirimi almaktır. Sadakat puanı, yorum sistemi ve kampanya modülü ikinci sürüme kalabilir. Bu yaklaşım hem bütçeyi korur hem de hangi özelliğe gerçekten ihtiyaç olduğunu kullanıcı davranışından öğrenmenizi sağlar.

Teklif karşılaştırırken nelere bakmalı?

Mobil uygulama teklifleri arasında da web projelerindeki gibi büyük farklar görülür. Farkın nedenini anlamak için teklifte şu kalemlerin açıkça yazılı olup olmadığına bakın:

• Kaç ekran ve hangi kullanıcı akışları kapsamda?
• Backend ve yönetim paneli dahil mi, yoksa sadece mobil arayüz mü?
• Tasarım revizyon hakkı ve test süreci nasıl işleyecek?
• Mağaza yayını, ilk inceleme reddi durumunda yapılacak düzeltmeler kapsamda mı?
• Kaynak kod, mağaza hesapları ve sunucu erişimleri kime teslim edilecek?
• Yayın sonrası garanti süresi ve bakım anlaşmasının içeriği nedir?

Yayından sonra devam eden maliyetler

Sunucu tarafında da benzer bir planlama gerekir. Uygulama büyüdükçe veritabanı yedekleri, güvenlik güncellemeleri, izleme ve ölçeklendirme ihtiyaçları ortaya çıkar. Bu işlerin kimin sorumluluğunda olacağını ve aylık bakım anlaşmasının hangi kalemleri kapsadığını yayından önce netleştirmek, ilk büyük kullanıcı artışında hazırlıksız yakalanmanızı önler. Bakım anlaşmasında yanıt süresi ve acil müdahale koşulları da yazılı olmalıdır.

Mağazalar, hedef işletim sistemi sürümü gibi teknik gereksinimleri düzenli olarak yükseltir. Hiç güncellenmeyen bir uygulama bir süre sonra yeni kullanıcılara görünmez hale gelebilir; bu yüzden bakım bütçesi baştan planlanmalıdır.

KVKK, aydınlatma metni ve analitik

Mobil uygulamalar genellikle ad, telefon, konum ve cihaz bilgisi gibi kişisel veriler işler. Bu nedenle uygulama içinde erişilebilir bir aydınlatma metni, gerekiyorsa açık rıza akışı ve gizlilik politikası bulunmalıdır. İzinler (konum, kamera, bildirim) ihtiyaç anında ve gerekçesi açıklanarak istenmelidir.

Analitik ise baştan kurgulanmalıdır: hangi ekranlar kullanılıyor, kullanıcılar hangi adımda bırakıyor, uygulama nerede çöküyor? Firebase Analytics ve Crashlytics gibi araçlarla temel olay takibi ve çökme raporlaması kurulmazsa, yayından sonra karar vermek tahmine kalır.

Sık yapılan hatalar

• İlk sürüme her şeyi sığdırmak: Kapsam büyüdükçe yayın gecikir, öğrenme de gecikir.
• Backend ve yönetim panelini unutmak: Teklifte sadece "uygulama ekranları" varsa, verinin nerede tutulacağını ve kimin yöneteceğini sorun.
• Kaynak kodu ve hesapları teslim almamak: Kod deposu, mağaza hesapları ve sunucu erişimleri sizde olmalı.
• Mağaza kurallarını sona bırakmak: Ödeme modeli, hesap silme ve gizlilik gereksinimleri tasarım aşamasında düşünülmeli.
• Yayın sonrası planı olmamak: İlk kullanıcı geri bildirimleri en değerli veridir; ikinci sürüm için bütçe ve zaman ayırın.

Kendi uygulamalarımızdan öğrendiklerimiz

Infumia olarak sadece müşteri projesi değil, kendi mobil uygulamalarımızı da geliştirip yayında tutuyoruz. Yapay zekâ ile fotoğrafları karikatüre çeviren Cartoonizer, Google Play'de 50.000'den fazla indirmeye ulaştı ve yapay zekâ modelini cihaz üzerinde çevrimdışı çalıştırıyor. İlişki analizi uygulaması Vena ve görev yap kazan uygulaması Kazanço da ekibimizin ürünleri. Mağaza incelemeleri, abonelik akışları ve sürüm güncellemeleri gibi konuları bu uygulamalarda bizzat yaşadığımız için müşteri projelerinde de baştan planlıyoruz.

Uygulama fikrinizi konuşmak isterseniz mobil uygulama hizmetimizi inceleyin ya da teklif formunu doldurun; kapsamı birlikte netleştirip size süre ve maliyet planı çıkaralım.

Sık sorulan sorular

Mobil uygulama yaptırmak ne kadar sürer?

Süre kapsama bağlıdır. Sınırlı bir MVP birkaç ayda yayına çıkabilirken backend, yönetim paneli ve çok sayıda entegrasyon içeren projeler daha uzun sürer. Mağaza inceleme ve hesap doğrulama süreleri de takvime eklenmelidir.

Flutter mı, native mi seçmeliyim?

İşletme uygulamalarının çoğu için Flutter veya React Native gibi cross-platform çözümler tek kod tabanıyla iki platformu verimli şekilde karşılar. Yoğun grafik, AR veya derin donanım erişimi gereken projelerde native geliştirme daha uygun olabilir.

App Store ve Google Play hesabı için ne ödenir?

Apple Developer Program yıllık 99 USD, Google Play Console ise tek seferlik 25 USD kayıt ücretine tabidir. Hesapların işletmenizin adına açılması önerilir.

Uygulamanın kaynak kodu kime ait olur?

Bu, sözleşmede açıkça yazılması gereken bir konudur. Kaynak kodun, mağaza hesaplarının ve sunucu erişimlerinin size teslim edilmesini sözleşmeye eklemenizi öneririz.

Yayından sonra uygulama için ne gibi giderler olur?

Apple geliştirici üyeliği, sunucu ve veritabanı, SMS veya bildirim gibi üçüncü taraf servisler, uygulama içi satışlarda mağaza komisyonu ve yeni işletim sistemi sürümlerine uyum için bakım düzenli giderlerdir.