Mobil Uygulama Geliştirme

Mobil uygulama, müşterinizin telefonunun ana ekranında duran, tarayıcıya girip site aramaya gerek kalmadan doğrudan işletmenize ulaştığı bir kısayoldur. Web sitesinden farkı, tekrar eden bir hizmet döngüsünde (randevu, sipariş, üyelik) müşteriyi işletmenize geri getiren push bildirim ve hesap geçmişi gibi araçlar sunmasıdır.

Somut bir örnek: Eryaman'da randevu alan bir kuaför salonu düşünün. Müşteri her seferinde salonu arayıp uygun saat soruyor, salon sahibi telefon trafiğiyle boğuşuyor. Bir mobil uygulama ile müşteri kendi telefonundan boş saatleri görüp randevu alıyor, salon da bir gün önceden hatırlatma bildirimi gönderip randevuya gelmeme oranını azaltıyor — hem müşteri hem işletme için sürtünme azalıyor.

Eryaman, Etimesgut, Sincan ve Gölbaşı'ndaki düzenli müşteri akışına dayanan işletmeler (spor salonları, kuaförler, restoranlar) için mobil uygulama, sadakati artıran somut bir araç. Örneğin bir spor salonu üyelik sistemi kurduğunda, üye artık salona her gidişinde kart göstermek yerine uygulamadan giriş yapıyor, kalan seans hakkını görüyor, salon da yeni ders programını push bildirimle anında duyurabiliyor. Bu tür pratik bir deneyim, üyenin salonu unutmasını ya da rakibe kaymasını zorlaştırıyor — Eryaman ve Sincan'da bu alanda henüz ciddi bir yerel rakip yok, Etimesgut ve Gölbaşı'nda köklü firmalar olsa da aynı titizlikle hizmet veriyoruz.

Türkiye'de küçük işletmelerin çoğu mobil uygulamayı sadece büyük şirketlerin işi sanıyor, oysa hazır altyapılar (React Native gibi tek kod tabanıyla hem iOS hem Android'e yayın) maliyeti eskisi kadar yüksek tutmuyor. Buna karşılık bazı işletmeler de tam tersi bir hataya düşüyor: hazır şablon bir uygulama satın alıp kendi iş akışına uydurmaya çalışıyor. Sincan'da bir restoran, hazır bir sipariş uygulaması şablonu kullanmış ama menü kategorileri restoranın gerçek menüsüne uymadığı için müşteri istediği ürünü bulamıyor, uygulamayı silip tekrar telefonla sipariş vermeye dönüyor — hazır şablon, gerçek iş akışına uymadığında güven kaybettiriyor.

Kapsam aşamasında uygulamanın temel özelliklerini ve hedef kullanıcı akışını netleştiriyoruz; arayüz aşamasında ekran tasarımlarını onayınıza sunuyoruz; geliştirme aşamasında uygulamayı test cihazlarında düzenli olarak sizinle paylaşarak ilerletiyoruz; yayın aşamasında mağaza onay süreçlerini yönetip canlıya alıyoruz.

Bir örnek: Eryaman'da bir kafe için kapsam aşamasında 'sadakat kartı' mantığını dijitalleştirmeyi netleştirdik diyelim — her 10 kahvede bir ücretsiz kahve. Arayüz aşamasında bu sayacın ana ekranda net görünmesini sağlıyoruz; geliştirme aşamasında kafe sahibiyle test cihazında sayacın doğru işlediğini birlikte kontrol ediyoruz. Böyle küçük ama gerçek bir iş kuralı, uygulamayı jenerik bir şablondan ayıran şey oluyor.

Bir uygulamayı geliştirip mağazaya yüklemek yeterli değil — ASO (App Store Optimization), uygulamanızın mağaza içi aramalarda bulunabilmesi için başlık, açıklama, anahtar kelime ve görsel materyalin optimize edilmesidir. Web sitesi için SEO neyse, mobil uygulama için ASO odur.

Somut bir senaryo: Etimesgut'ta bir restoran, kendi sipariş uygulamasını App Store'a yüklemiş ama uygulama adı sadece 'Restoran' gibi jenerik bırakılmış, açıklama kısmı boş, anahtar kelime alanı hiç doldurulmamış. Sonuç: bir kullanıcı 'Etimesgut yemek siparişi' diye Play Store'da arattığında bu uygulama hiç çıkmıyor — uygulama var ama bulunamıyor, geliştirmeye harcanan emek karşılıksız kalıyor. Biz her mobil uygulama projesinde yayın sürecinin bir parçası olarak mağaza başlığını, açıklamasını ve anahtar kelimelerini de gerçek arama davranışına göre kuruyoruz; uygulama sadece çalışır durumda değil, aynı zamanda bulunabilir durumda mağazaya çıkıyor.

ASO tek bir işlem değil, dört ayrı çalışmanın toplamı. Birincisi anahtar kelime optimizasyonu: App Store'da 100 karakterlik gizli bir anahtar kelime alanı, Google Play'de ise başlık ve açıklama metninin kendisi arama algoritmasını besliyor. 'Randevu uygulaması' yerine kullanıcının gerçekte yazdığı 'kuaför randevu Eryaman' gibi ifadeleri kullanıyoruz — bunu tahminle değil, benzer uygulamaların hangi terimlerle bulunduğunu inceleyerek belirliyoruz.

İkincisi ikon ve ekran görüntüsü optimizasyonu: mağazada kullanıcı önce ikonu, sonra ilk 2-3 ekran görüntüsünü görüyor, karar bu saniyeler içinde veriliyor. Sade, tek bir sembole odaklanan bir ikon; ekran görüntülerinde ürünün kendisini değil o ürünün çözdüğü faydayı gösteren kısa başlıklar ('3 saniyede randevu al' gibi) dönüşümü belirgin şekilde artırıyor. Karmaşık, metin dolu ikonlar küçük ekranda okunmuyor ve tıklanma oranını düşürüyor.

Üçüncüsü açıklama metni: ilk 2-3 satır mağaza önizlemesinde kesilmeden görünüyor, bu yüzden en güçlü faydayı en başa yazıyoruz; kalan metinde özellik listesi yerine somut senaryolar anlatıyoruz. Dördüncüsü yorum ve puan stratejisi: mağaza algoritması, indirme sayısı kadar yorum sayısını ve güncel puan ortalamasını da sıralamaya dahil ediyor. Uygulama içinde kullanıcı olumlu bir deneyim yaşadığı anda (örneğin randevusunu başarıyla tamamladığında) nazik bir yorum isteği gösteriyor, olumsuz deneyimi ise önce bize yönlendirip mağazaya taşınmadan çözmeye çalışıyoruz — bu, düşük puanların birikmesini engelleyen basit ama etkili bir akış.

Uygulama geliştirmeyi bitirmek, yayında olmak anlamına gelmiyor — önce mağazanın inceleme sürecinden geçmesi gerekiyor. Google Play tarafında bu inceleme genellikle birkaç saat ile 3 gün arasında sonuçlanıyor; Apple'ın App Store incelemesi ise insan gözden geçirmesi içerdiği için tipik olarak 1-3 gün sürüyor, ilk başvuruda ek belge istenirse bu süre uzayabiliyor.

En sık ret nedenleri şunlar: Apple tarafında eksik veya test edilemeyen özellik (örneğin giriş gerektiren bir ekranın incelemeci için çalışan bir test hesabıyla sunulmaması), gizlilik politikası linkinin eksik veya uygulamanın topladığı veriyle uyuşmaması, ve 'Guideline 4.2' kapsamında uygulamanın bir web sitesinin doğrudan sarmalanmışı (basit bir WebView) gibi görünmesi — Apple, uygulamanın yerel (native) bir değer sunmasını bekliyor. Google Play tarafında ise en sık ret nedeni izin (permission) kullanımının açıklanmaması — örneğin konum izni istenip bunun neden gerektiği Play Console'da belirtilmemesi — ve hedef kitle/içerik derecelendirmesi formunun eksik doldurulması.

Bu riskleri nasıl önlüyoruz: başvuru öncesi incelemeci için çalışan bir test hesabı hazırlıyoruz, gizlilik politikası sayfasını uygulamanın gerçekte topladığı veriyle birebir eşleştiriyoruz, ve uygulamanın push bildirim, offline kullanım gibi en az bir native özelliği barındırmasını baştan tasarıma dahil ediyoruz — böylece ret riski taşıyan noktalar geliştirme bitmeden, mağazaya yüklenmeden önce kapanmış oluyor. Bir ret alınsa bile bu genellikle projeyi durdurmuyor; Apple ret gerekçesini yazılı bildiriyor, düzeltip 24-48 saat içinde yeniden başvuru yapılabiliyor.

Bu, ilk görüşmede en çok karşılaştığımız soru ve doğru cevap işletmeden işletmeye değişiyor. Web sitesi; bir müşteri adayının işletmenizi Google'da ilk kez bulduğu, link paylaşarak kolayca ulaştığı, kurulum gerektirmeyen bir temas noktasıdır — her işletmenin ihtiyaç duyduğu temel katman budur. Mobil uygulama ise müşteri sizi zaten tanıdıktan sonra, tekrar eden bir etkileşimi (randevu, sipariş, üyelik, sadakat puanı) kolaylaştırmak için devreye giren ikinci bir katmandır; kurulum gerektirir ve kullanıcı bunu ancak tekrar tekrar değer göreceğini düşünürse telefonunda tutar.

Somut ayrım şöyle: Etimesgut'ta ayda bir kez ziyaret edilen bir avukatlık bürosu için web sitesi yeterli ve doğru yatırımdır — müşteri o kadar sık etkileşime girmeyeceği bir uygulamayı indirmeye zaten ikna olmaz. Buna karşılık haftada birkaç kez ziyaret edilen bir spor salonu veya kuaför için mobil uygulama, web sitesinin sağlayamayacağı bir şeyi sağlar: push bildirimle hatırlatma, geçmiş randevu kaydı, uygulama içi sadakat sayacı. Kısa kural: müşteri işletmenizle ayda bir defadan az etkileşiyorsa web sitesi yeterli; haftalık/aylık tekrar eden bir hizmet döngünüz varsa mobil uygulama yatırımı kendini geri ödüyor. Emin değilseniz, ilk görüşmede mevcut müşteri tekrar sıklığınızı birlikte değerlendirip hangisinin doğru öncelik olduğunu netleştiriyoruz.

Randevu, sipariş veya üyelik gibi tekrar eden bir hizmet döngüsü olan işletmeler için mobil uygulama en yüksek getiriyi sağlar: kuaförler, spor salonları, restoranlar, kliniklerdeki takip programları, sadakat sistemi olan kafeler. Tek seferlik hizmet veren (örneğin bir kez ev tadilatı yapan bir usta) işletmeler için ise genellikle bir web sitesi ve WhatsApp hattı, mobil uygulamadan daha uygun bir yatırım oluyor — çünkü müşteri o işletmeyle tekrar tekrar etkileşime girmiyor. İlk görüşmede iş modelinizin bu iki uçtan hangisine yakın olduğunu birlikte değerlendiriyoruz.

Maliyet, uygulamanın özellik sayısına (randevu sistemi, ödeme entegrasyonu, push bildirim gibi) ve iOS/Android'den kaçının hedeflendiğine göre değişir. Örneğin sadece randevu görüntüleme yapan basit bir uygulama ile içinde ödeme, sipariş takibi ve puan sistemi olan bir uygulamanın geliştirme kapsamı çok farklıdır. İlk görüşmede ihtiyacınızı netleştirip yazılı, net bir teklif sunuyoruz.

En sık gördüğümüz hata, uygulamayı web sitesinin bir kopyası gibi tasarlamak — oysa telefon ekranı farklı bir etkileşim mantığı gerektirir (tek elle kullanım, parmakla kaydırma, bildirim akışı). İkinci hata, ilk sürümde çok fazla özelliği aynı anda kapsamaya çalışmak: kullanıcı ilk açılışta karmaşık bulduğu bir uygulamayı genellikle bir daha açmıyor. Üçüncü hata, yayın sonrası uygulamayı tamamen unutmak — mağaza güncellemeleri ve işletim sistemi değişiklikleri takip edilmezse, uygulama zamanla bozulur ya da mağazadan kaldırılma riskiyle karşılaşır.

İkisi rakip değil, farklı aşamalara hizmet eden araçlar. Web sitesi, bir müşteri adayının işletmenizle ilk kez tanıştığı, sürtünmesiz temas noktasıdır — link paylaşmak, arama sonucunda bulunmak kolaydır. Mobil uygulama ise, müşteri zaten sizi tanıyıp tekrar etkileşime girmeye karar verdikten sonra devreye giren bir sadakat katmanıdır. Bu yüzden çoğu işletme için doğru sıralama önce web sitesiyle güveni kurmak, sonra düzenli müşteri akışı oluştuğunda mobil uygulamayla bu ilişkiyi derinleştirmektir.