Türkiye'nin en büyük inovasyon ve girişimcilik bültenine katılın
Kanallar İlham Uygulamalar SSS Sözlük Giriş Üye Ol

Mobil Uygulama Geliştirme

/mobiluygulama · 1.YIL

Fikirden App Store ve Google Play'e uzanan yolun tamamı tek kanalda. Swift, Kotlin, Flutter, React Native — platform fark etmez; uygulamanı nasıl yapacağını burada konuşuruz. Mimari kararlar, arayüz desenleri, yayın süreçleri, test ve sürüm yönetimi; ilk satırdan ilk indirmeye kadar ne varsa burada. Takıldığın yeri sor, öğrendiğini paylaş, uygulamanı yapan diğer üreticilerle omuz omuza ilerle.

66 içerik Katıl
#mobil uygulama geliştirme akışına dön
@dandanakan · 36 gün önce

Mobil uygulama yaptırmak ne kadar tutar: Fiyat aralıklarını belirleyen şeyler

Bu sorunun tek bir cevabı yok ama fiyatı neyin belirlediğini bilmek, alınan teklifleri değerlendirmeyi mümkün kılıyor.

Maliyeti belirleyen ana kalemler şunlar:

Ekran sayısı ve karmaşıklığı. Beş ekranlı bir katalog uygulaması ile kırk ekranlı bir pazaryeri uygulaması aynı işi değil. Teklif alırken ekran listesi çıkarmak, fiyatı somutlaştıran ilk adım.

Arka uç ihtiyacı. Uygulama sadece mevcut bir servisi gösterecekse maliyet düşük. Kullanıcı hesabı, veri saklama, bildirim altyapısı ve yönetim paneli gerekiyorsa işin yarısı arka uçta demektir.

Platform sayısı. Tek platform mu, iki platform mu? Çapraz platform araçlar bu maliyeti azaltıyor ama sıfırlamıyor, her platformun kendi yayın ve test süreci var.

Entegrasyonlar. Ödeme alma, harita, kimlik doğrulama, kargo takibi gibi her dış servis ayrı iş kalemi. Özellikle ödeme entegrasyonu görünenden daha uzun sürüyor.

Tasarım. Hazır bileşenlerle ilerlemek ile özgün bir tasarım dili kurmak arasında ciddi fark var.

Göz ardı edilen kalemler: mağaza hesapları ve yıllık ücretleri, sunucu maliyeti, bakım ve işletim sistemi güncellemelerine uyum. Uygulama teslim edildiğinde iş bitmiyor, her yıl yeni işletim sistemi sürümü çıkıyor ve uyum çalışması gerekiyor.

En sağlıklı yaklaşım, işi tek seferlik proje yerine aşamalara bölmek. Önce dar kapsamlı ama çalışan bir sürüm çıkarıp gerçek kullanıcı geri bildirimiyle devam etmek, hem riski hem maliyeti düşürüyor.
0 2 yorum
Yorumlar (2)
@mardig · 33 gün önce 5
Bakım kalemi gerçekten en çok atlanan konu, teklif alan tarafın mutlaka sorması gereken şey.

Uygulama teslim edildikten sonra her yıl iki büyük işletim sistemi güncellemesi geliyor ve bunlar bazen çalışan özellikleri bozuyor. Mağazalar da zaman zaman yeni zorunluluklar getiriyor, gizlilik beyanı ve hesap silme kuralları buna örnek.

Bu yüzden sözleşmede bakım kapsamının net yazılması gerekiyor. Hata düzeltme dahil mi, işletim sistemi uyumu dahil mi, yeni özellik talebi nasıl fiyatlanıyor?

Bunu konuşmadan başlayan projelerde bir yıl sonra taraflar arasında hep aynı tartışma çıkıyor.
@bananaman · 30 gün önce 2
Aşamalara bölme tavsiyesine katılıyorum, buna somut bir yöntem ekleyeyim.

İlk sürümde sadece tek bir işi çok iyi yapan bir uygulama çıkarmak, on özelliği ortalama yapan bir uygulamadan hem ucuz hem daha başarılı oluyor.

Özellik listesini yazarken şu soruyu sormak işe yarıyor: bu özellik olmasa uygulama işe yaramaz mı, yoksa sadece daha iyi mi olur? İkinci gruba girenlerin hepsi ikinci sürüme kalabilir.

Bu yaklaşımın ek faydası, gerçek kullanıcı geri bildirimiyle yön belirlemek. Tahminle yaptığınız özelliklerin bir kısmının hiç kullanılmadığını göreceksiniz, o bütçeyi boşa harcamamış olursunuz.