Mobil Uygulama Geliştirme

Mobil uygulama yaptırmak isteyen iki farklı işletme, aynı cümleyi kurup tamamen farklı iki işi kastediyor. Birincisi zaten çalışan bir e-ticaret sitesinin mobil karşılığını istiyor; ikincisi ise henüz var olmayan bir ürünü sıfırdan kurmak istiyor. Bu sayfa iki işi ayırıyor, her birinin kapsamını ve fiyatını neyin belirlediğini anlatıyor. Mobil uygulama geliştirmenin genel işleyişini, mağaza kurallarını ve alıcı tarafın kontrol listesini mobil uygulama yaptırmak rehberinde ele aldık; burası hizmetin kendisi.

İki ayrı iş: hangisinden bahsediyoruz

E-ticaret mobil uygulaması: siteyle aynı üye, aynı sepet

Bu işin tanımı nettir: uygulama, mağazanızın mobil yüzüdür. Üyeler, sepet, siparişler, adresler, kuponlar ve stok mevcut altyapınızda kalır; uygulama bu verinin üzerine oturur. Somut karşılığı şudur: siteye kayıtlı bir müşteri uygulamayı indirdiğinde aynı bilgilerle giriş yapar, yeniden üye olmaz. Bilgisayarda sepetine attığı ürünü telefonda kaldığı yerde bulur. Panelde bir fiyatı değiştirdiğinizde uygulama da aynı fiyatı gösterir; iki ayrı katalog yönetmek zorunda kalmazsınız.

Bu ayrım yalnızca teknik bir tercih değil, ticari bir karardır. Ayrı üyelik havuzuyla çalışan bir uygulama, mevcut müşterinizi yeniden kayıt olmaya zorlar ve bu adımda büyük bölümünü kaybeder. Aynı şekilde ayrı stok yönetimi, kampanya dönemlerinde fazla satış ve iptal üretir. E-ticaret mobil uygulamasının mantığını ve ne zaman erken olduğunu e-ticaret mobil uygulaması yazısında ayrıntılı anlattık.

Çalıştığımız altyapılar arasında Ticimax, IdeaSoft, ikas, T-Soft, Shopify, WooCommerce, Faprika, Akinon, Magento ve özel yazılımla geliştirilmiş siteler var. Belirleyici olan altyapının adı değil, üyelik, sepet ve sipariş uçlarının erişilebilir olmasıdır; bunu projeye başlamadan bir uygunluk incelemesiyle doğruluyoruz. Altyapınızı yenilemeyi de düşünüyorsanız, kendi geliştirdiğimiz RapiSoft e-ticaret altyapısı ile uygulamanın birlikte planlanması iki işi tek takvime alır.

Sıfırdan isteğe özel uygulama

İkinci iş tipinde ortada bağlanılacak bir sistem yoktur; uygulama, arka uç, veri modeli ve yönetim paneliyle birlikte kurulur. Randevu ve rezervasyon, saha ekibi uygulamaları, sadakat programları, üyelik temelli içerik servisleri ve şirket içi araçlar bu gruba girer. Burada kapsam belirsizliği yüksektir, bu yüzden önce bir keşif turu yapıyor, ilk sürümü kullanıcıyı geri getirecek çekirdek akışla sınırlıyoruz. Uygulamanın arka ucu genellikle kişiye özel yazılım kapsamıyla iç içe geçer; iki hizmeti tek proje olarak da yürütüyoruz.

iOS Android uygulama tek kod tabanıyla mı geliştirilsin?

Projelerin büyük çoğunluğunda tek kod tabanıyla ilerliyoruz: iki platform aynı koddan çıkıyor, ekranların davranışı platform kurallarına göre ayarlanıyor. Bunun sebebi maliyetten çok süreklilik: iki ayrı kod tabanı, her yeni özelliğin iki kez yazılması ve iki kez test edilmesi demektir; zamanla iki uygulama birbirinden ayrışır.

Native geliştirmeyi tercih ettiğimiz durumlar da var: yoğun kamera veya sensör kullanımı, arka planda sürekli çalışan konum takibi, ağır grafik işleme ya da platforma özgü bir yeteneğin merkezde olduğu ürünler. Karar, projenin en zorlayıcı ekranına bakılarak veriliyor; ortalama ekrana bakarak verilen kararlar sonradan pahalıya patlıyor. Kapsam görüşmesinde hangi yaklaşımın seçildiğini ve gerekçesini yazılı olarak veriyoruz.

Mobil uygulama geliştirme kapsamında ne teslim ediyoruz

Mağaza yayın süreci: hesaplar, formlar ve inceleme

Yayın süreci geliştirmeden bağımsız ilerleyen bir iştir ve projelerin en çok gecikme yaşadığı yerdir. Baştan bilinmesi gerekenler şunlar:

• Hesaplar şirketiniz adına açılır. Apple Developer Program ve Google Play Console hesaplarının sahibi siz olursunuz; biz yetkili geliştirici olarak çalışırız. Uygulamanın ajansın hesabında durması, ileride ilişki değiştiğinde ciddi sorun üretir.
• Kurumsal hesapta doğrulama istenir. Şirket adına açılan hesaplarda kimlik ve şirket doğrulaması yapılır; bu süreç kimi zaman haftalara yayılabildiği için projenin ilk adımına alıyoruz.
• Gizlilik bildirimi ve veri formları zorunludur. Uygulamanın hangi veriyi topladığı, ne için kullandığı ve üçüncü taraflarla paylaşıp paylaşmadığı mağaza formlarında beyan edilir. Beyan ile uygulamanın davranışı uyuşmuyorsa red gelir.
• Hesap silme yolu uygulama içinde bulunmalıdır. Kullanıcı hesabı oluşturulabilen uygulamalarda hesabın silinebilmesi de gerekir; bunu tasarım aşamasında planlıyoruz.
• İncelemeye test hesabı verilir. Giriş gerektiren uygulamalarda çalışan bir test hesabı sağlanmazsa inceleme reddedilir.
• Google tarafında yeni bireysel hesaplar için ek test şartları uygulanabiliyor. Kurumsal hesapla ilerlemek bu yüzden hem daha hızlı hem daha öngörülebilir.

İnceleme süresi mağazaların inisiyatifindedir ve garanti edilemez. Bu yüzden belirli bir kampanya tarihine bağlı lansmanlarda takvime pay bırakıyor, uygulamayı hedeflenen tarihten önce incelemeye gönderiyoruz.

Ödeme ve komisyon: fiziksel ürün satan uygulamalar

Mağaza komisyonu konusu tekliflerde sık sık yanlış anlaşılıyor. Fiziksel ürün ve uygulama dışında tüketilen hizmet satışlarında ödeme kendi sanal POS altyapınız üzerinden yürür; mağazaların uygulama içi satın alma zorunluluğu bu satışları kapsamaz. Zorunluluk dijital içerik, abonelik ve uygulama içinde tüketilen özellikler için geçerlidir. E-ticaret uygulamalarında bu ayrım genellikle satıcının lehinedir ve ödeme akışının sitedekiyle aynı kalmasını sağlar.

Push bildirim: uygulamanın asıl getirisi

Bir mağaza uygulamasının en somut kazancı, müşteriye reklam bütçesi harcamadan doğrudan ulaşabilmektir. Ancak bu kanal kolayca yakılır: sık ve alakasız bildirim gönderen uygulamaların önce bildirimleri kapatılır, sonra kendileri silinir. Kurduğumuz yapıda izin isteme anı geciktirilebilir, bildirimler segmente edilebilir ve gönderim sıklığına sınır konabilir. Bildirim stratejisinin ayrıntısını mobil uygulama push bildirim yazısında ele aldık.

Push, tek başına kullanılan bir kanal olmak zorunda değil. Uygulamayı indirmemiş müşterilere aynı senaryoları WhatsApp üzerinden kurabilirsiniz: sepetini bırakan ziyaretçi için WhatsApp sepet hatırlatıcı, sipariş sonrası bilgilendirme için WhatsApp kargo bildirimi modülleri aynı e-ticaret altyapısına bağlanır ve kurulumlarını biz yapıyoruz.

Sürüm bakımı neden bitmiyor

Web sitesinde yayınladığınız bir düzeltme anında yayına girer. Mobilde her değişiklik yeni bir sürüm, her sürüm bir inceleme demektir; üstelik kullanıcıların bir kısmı güncellemeyi almaz. Bunun yanında uygulamayı siz hiç değiştirmeseniz bile çevresi değişir:

• İşletim sistemleri yılda bir büyük sürüm çıkarır; eski uygulamalarda görsel bozulmalar ve davranış farkları oluşur.
• Mağazalar, güncelleme yayınlamak için belirli bir hedef sürüm seviyesini şart koşar; bu seviye her yıl yükselir.
• İmzalama sertifikaları ve bildirim anahtarları sürelidir; yenilenmezse yayın veya bildirim durur.
• Kullanılan kütüphaneler güvenlik güncellemeleri alır; geride kalan sürümler zamanla risk hâline gelir.
• Gizlilik ve izin kuralları değişir; beyanların güncellenmesi gerekir.

Bakım paketinde bu döngüyü yürütüyoruz: düzenli sürüm güncellemeleri, çökme kayıtlarının takibi, mağaza kurallarına uyum ve tanımlı bir aylık geliştirme kapasitesi. Bakım almadan da uygulamayı kullanabilirsiniz, ancak bakımsız bir uygulamanın ömrü sınırlıdır.

Mağaza sayfası: indirme kararı orada veriliyor

Uygulamanın kendisi kadar, mağazadaki listeleme sayfası da bir tasarım işidir. Kullanıcı ilk ekran görüntüsüne bakarak birkaç saniyede karar verir ve açıklama metnini çoğu zaman hiç okumaz. Bu yüzden mağaza hazırlığını projenin son gününe sıkıştırılan bir formalite olarak değil, ayrı bir kalem olarak ele alıyoruz.

Pratikte üzerinde durduğumuz noktalar şunlar: ilk iki ekran görüntüsünün uygulamanın ne işe yaradığını tek başına anlatması, uygulama adının marka adıyla birlikte ne yaptığını da söylemesi, kısa açıklamanın liste görünümünde kesilmeden okunabilmesi ve ikonun küçük boyutta da tanınabilir kalması. Mağaza sayfası yayından sonra da güncellenebilir; ekran görüntülerini yeni sürümlerle birlikte tazelemek, sayfayı bir kez yapıp unutmaktan daha iyi sonuç verir. Kullanıcı yorumlarına yanıt vermek de aynı şekilde ihmal edilen ama karar aşamasındaki kişinin gördüğü bir alandır.

Mobil uygulama fiyatları neye göre değişiyor

Bu sayfada liste fiyatı yazmıyoruz ve bunun sebebi fiyatı gizlemek değil. Mobil uygulamada aynı cümleyle anlatılan iki iş arasında kat kat fark olabiliyor: mevcut e-ticaret altyapınıza bağlanan bir uygulama ile arka ucu, veri modeli ve yönetim paneli de yazılan bir proje aynı kalemde toplanamaz. Rakam vermek yerine fiyatı neyin belirlediğini kalem kalem yazmayı tercih ediyoruz; böylece kendi projenizin hangi uçta durduğunu daha teklif istemeden görebilirsiniz.

Geliştirme bedelini belirleyen kalemler

• İşin tipi. Mevcut altyapıya bağlanan uygulama ile arka ucu da yazılan proje arasındaki fark en büyük kalemdir. Birincisinde veri zaten var ve akışlar tanımlı; ikincisinde önce sistemin kendisi kurulur, uygulama onun üstüne gelir.
• Ekran ve akış sayısı. Her ekran tasarım, geliştirme ve iki platformda test demektir. Ekran sayısı arttıkça maliyet doğrusal değil, aralarındaki geçişler yüzünden daha hızlı büyür.
• Tasarımın kaynağı. Platform bileşenleriyle sade bir arayüz ile markaya özel tasarlanmış bir deneyim aynı emek değildir. Hazır bileşen kullanmak işi kısaltır ama uygulamayı marka olarak ayrıştırmaz; karar bu ikisi arasında verilir.
• Entegrasyon derinliği. Yalnızca katalog gösteren bir uygulama ile iade, kargo takibi ve sadakat puanı içeren bir uygulama ayrışır. Her entegrasyon karşı tarafın API sınırlarını, hata durumlarını ve test ortamını da beraberinde getirir.
• Bildirim ve segmentasyon ihtiyacı. Toplu gönderim ile kullanıcı davranışına göre tetiklenen bildirim farklı yapılardır. İkincisi olay toplama, segment tanımı ve gönderim kuralı gerektirir; yani bir bildirim özelliği değil, küçük bir alt sistemdir.
• Çevrimdışı çalışma ve cihaz özellikleri. Bağlantısız kullanım, kamera, konum veya cihaz sensörleri kapsamı büyütür. Çevrimdışı çalışma özellikle yanıltıcıdır: asıl iş veriyi saklamak değil, bağlantı geri geldiğinde çakışmaları çözmektir.
• Dil sayısı. Her dil, ekran metinleri ve mağaza listelemesi için ek iş demektir. Sağdan sola yazılan bir dil eklenecekse yerleşim de yeniden gözden geçirilir.
• Bakım kapsamı. Yayın sonrası hangi seviyede destek istendiği aylık maliyeti belirler. Yalnızca hata düzeltme ile yeni özellik geliştirmeyi de içeren bakım aynı paket değildir.

Tek seferlik bedelin dışında kalan süreklilik kalemleri

Mobil uygulamada bütçenin en çok şaşırtan tarafı, projenin bittiği gün bitmeyen kalemlerdir. Uygulamanın gerçek maliyeti ilk sürümde değil, ikinci yılda görülür.

• Geliştirici hesapları. Apple tarafında yıllık yenilenen, Google tarafında tek seferlik bir hesap bedeli vardır. Hesaplar şirketiniz adına açıldığı için bu kalem doğrudan sizde kalır; yenilenmediğinde uygulama mağazadan düşer.
• İşletim sistemi sürümleri. Apple ve Google her yıl yeni sürüm çıkarır ve bir süre sonra eski hedef sürümlerle yapılmış gönderimleri kabul etmeyi bırakır. Hiçbir özellik eklemeseniz bile uygulamanın güncel tutulması gerekir.
• Servis abonelikleri. Bildirim gönderimi, hata izleme ve kullanım ölçümü için kullanılan servislerin çoğu kullanım hacmine göre ücretlenir. Kullanıcı sayınız arttıkça bu kalem de artar.
• Mağaza komisyonu. Uygulama içinden dijital içerik satıyorsanız mağaza komisyonu devreye girer. Fiziksel ürün satan e-ticaret uygulamaları bu komisyonun dışındadır; bu ayrım bütçeyi doğrudan etkilediği için erken netleşmelidir.
• Bakım paketi. Hata düzeltme, sürüm yenileme ve mağaza gönderimlerinin yürütülmesi süreklilik gerektiren bir iştir ve aylık olarak planlanır.

Gerçekçi bir teklif almak için elinizde ne olmalı

Mobil projelerde ilk rakamı sapmaya uğratan şey genellikle ekran tasarımı değil, sonradan ortaya çıkan bağlantı işleridir: sipariş durumunun nereden okunacağı, iadenin hangi sistemde açılacağı, stoğun kimde tutulduğu. Görüşmeye şu dördü hazır gelirse verdiğimiz rakam ile faturalanan rakam arasındaki fark ciddi biçimde kapanıyor:

• Hangi işi istediğiniz. Mevcut altyapıya bağlanan uygulama mı, bağımsız bir ürün mü? Bu tek soru bütçenin büyüklük sırasını belirler.
• İlk sürümün ekran listesi. Yayına ilk çıkan sürümde hangi ekranların olacağı yazılı olsun. Sonraki sürümlere bırakılacaklar da ayrı bir listede dursun; ikisini ayırmak teklifi hem küçültür hem netleştirir.
• Bağlanacak sistemlerin listesi. E-ticaret altyapınız, ödeme sağlayıcınız, kargo firmalarınız, e-fatura ve varsa ERP'niz. Her birinin API belgesine erişiminiz olup olmadığı da bilgi olarak önemlidir.
• Yayın hedefi. Belirli bir tarihe yetişmesi gereken bir kampanya varsa baştan söyleyin. Mağaza incelemesi bizim kontrolümüzde olmayan bir süre eklediği için takvim buna göre kurulur.

Bu dördü elinizdeyse ilk görüşmenin sonunda kapsam listesi çıkarıp yazılı teklif veriyoruz. Elinizde değilse de sorun değil; keşif görüşmesinde birlikte çıkarıyoruz, ancak o durumda ilk verilen rakam bir aralık olur ve kapsam yazıya döküldükten sonra kesinleşir.

Önce uygulama mı, önce site mi

Mobil uygulama, mevcut müşteriyi elde tutma aracıdır; yeni müşteri kazanma aracı değildir. Henüz düzenli bir ziyaretçi kitleniz ve tekrar eden siparişleriniz yoksa, aynı bütçeyi sitenin mobil deneyimine ve dönüşüm tarafına harcamak daha hızlı geri döner. Bu kararı verirken web sitesi mi mobil uygulama mı yazısındaki ölçütlere bakmanızı öneriyoruz; keşif görüşmesinde de aynı soruları birlikte cevaplıyoruz ve erken bulduğumuz projelerde bunu açıkça söylüyoruz.

Projenizi konuşmak isterseniz destek@stools.digital adresine yazabilir veya 0547 007 54 24 numarasından ulaşabilirsiniz. İlk görüşmede fiyat değil, hangi işi yaptığımızı netleştiriyoruz; kapsam netleşmeden verilen mobil uygulama teklifleri neredeyse hiç tutmuyor.