İzmir'de yazılım,uzaktan değil.

İzmir'de gelen taleplerin belki üçte birinde doğru cevap "uygulama yaptırmayın" oluyor. Mağazadan indirilen bir uygulama, kullanıcıdan kalıcı bir karar ister: yer ayırır, güncelleme ister, bildirime izin ister. İnsanlar bunu yalnızca tekrar tekrar kullanacakları şeyler için yapıyor.

Pratik ayrım şu: kullanıcı bu işi ayda birden fazla yapacaksa uygulama mantıklı. Ayda bir veya daha seyrekse mobil uyumlu bir web sitesi hem daha ucuz hem daha çok kullanılır — çünkü indirme adımı satışın en büyük kaybının yaşandığı yerdir.

• Uygulama mantıklı: sadakat ve puan biriktirme, sık tekrarlanan sipariş, saha ekibinin günlük kullandığı iç araç, rezervasyon geçmişi olan hizmetler, bildirimle değer üreten her şey.
• Web sitesi yeter: yılda birkaç kez kullanılan hizmetler, katalog ve vitrin, tek seferlik başvuru formları, kampanya sayfaları.
• Arada kalanlar: QR menü ve masadan sipariş gibi işler. Burada uygulama indirtmek yerine tarayıcıdan çalışan bir akış çoğu zaman daha çok sipariş getiriyor — müşteri masada uygulama indirmiyor.

Fiyat tekliflerinde konuşulmayan ama takvimi en çok bozan kalem, App Store ve Google Play onay süreçleridir. Kod bittiğinde iş bitmiyor. Kendi yayınladığımız uygulamalarda toplanan, tekrar eden ret sebepleri:

• Hesap silme akışı zorunlu. Kullanıcı hesabı oluşturan her uygulama, uygulama içinden hesabı silme yolu sunmak zorunda. Yalnızca "bize e-posta atın" demek yetmiyor.
• Kullanıcı içeriği varsa bildir ve engelle. Kullanıcıların içerik ürettiği veya birbirini gördüğü uygulamalarda şikâyet ve engelleme akışı olmadan onay çıkmıyor.
• Gizlilik ve veri formları. App Privacy ve Data Safety formları eksik ya da koddaki gerçekle tutarsızsa uygulama incelemeden dönüyor.
• Abonelik varsa satın almayı geri yükleme. Uygulama içi satın alma eklendiği anda "geri yükle" düğmesi ve şartlar bağlantısı zorunlu hale geliyor.
• Ekran görüntüleri ve açıklama. Mağaza görselleri uygulamada gerçekten olmayan bir ekranı gösteriyorsa ret sebebi.

Bunların hiçbiri teknik olarak zor değil; sorun zamanlaması. Geliştirme bittikten sonra keşfedilirse her ret turu bir haftaya mal oluyor. Biz bu maddeleri projenin başındaki kapsam listesine koyuyoruz — lansman tarihi vaadi ancak böyle tutulabiliyor.

Uygulama bir kere yapılıp bitirilen bir iş değil; yaşayan bir üründür ve yıllık sabit giderleri vardır. İzmir'de teklif alırken bu kalemlerin teklife dahil olup olmadığını sormak, toplam maliyeti tahmin etmenin tek yolu:

• Geliştirici hesapları: Apple yıllık 99 dolar, Google Play tek seferlik 25 dolar.
• Zorunlu güncellemeler: Apple ve Google her yıl yeni işletim sistemi sürümüyle birlikte hedef SDK sürümünü yükseltiyor. Güncellenmeyen uygulama bir süre sonra mağazadan düşüyor — bu, yeni özellik değil, yerinde durmak için yapılan iştir.
• Sunucu ve altyapı: uygulamanın arkasında bir servis varsa aylık gideri var.
• Çökme takibi ve destek: kullanıcı sayısı arttıkça kaçınılmaz.

Kabaca bir çerçeve: ilk yıldan sonra yıllık bakım, projenin ilk maliyetinin %15-25'i bandında oturuyor. Bunu baştan bütçeye koymayan projelerin ikinci yılında uygulama sessizce terk ediliyor.

Şehirdeki taleple ilgili gözlemimiz, genel Türkiye tablosundan biraz ayrışıyor:

• Restoran ve kafe: İzmir'de yoğun. Ama burada uygulamadan çok, teslimat platformlarına ödenen komisyondan kaçma ihtiyacı konuşuluyor — çözüm çoğu zaman kendi sipariş sistemi ve QR menü tarafında.
• Sağlık ve klinik: randevu, hasta takibi ve yurt dışı hasta iletişimi. Sağlık turizmi güçlü olduğu için çok dilli yapı neredeyse her projede çıkıyor.
• Üretim ve lojistik: saha ekibinin kullandığı iç uygulamalar — mağazada yayınlanmayan, şirket içi dağıtılan işler. En az konuşulan ama en çok geri dönüş üreten kategori.
• Turizm ve organizasyon: sezonluk yoğunluk, rezervasyon ve program akışı.