Masanın üzerinde çoğu zaman tek bir cümle oluyor: "Bizim de bir mobil uygulamamız olsun." Arkasında haklı bir sezgi var — müşteriler günün büyük kısmını telefon ekranında geçiriyor, rakibin uygulaması mağazada duruyor, akıllardaki tablo net. Ama o cümleyle gerçek bir uygulama arasında, çoğu işletmenin baştan hesap etmediği bir mesafe var: ne tür bir uygulama, hangi platform, ilk sürümde ne olacak, yayından sonra kim bakacak.
Bu yazı tam da o mesafeyi kat etmek için. Mobil uygulama yaptırmayı düşünen bir işletme sahibinin kafasındaki sırayla gidelim — teknik bir broşür gibi değil, bu işi yapan tarafın masaya koyduğu sorularla.
Önce dürüst soru: gerçekten uygulama mı gerekiyor?
Gelen taleplerin azımsanmayacak bir kısmında, iş konuşulduğunda ortaya çıkan ihtiyaç aslında bir mobil uygulama değil, mobilde düzgün çalışan bir web sitesi oluyor. Aradaki fark hem bütçeyi hem de süreci baştan aşağı değiştiriyor.
Kabaca şöyle ayırıyoruz. Amacınız tanıtım, vitrin, iletişim, hatta çevrimiçi satışsa — yani kullanıcı sizi arada bir ziyaret ediyorsa — mobil uyumlu bir web sitesi çoğu zaman hem daha hızlı hem daha ucuz çözüm. Kullanıcı hiçbir şey indirmez, Google'dan direkt bulur, siz tek bir yeri güncellersiniz. Bu kararın ayrıntısını mobil uyumlu site neden şart yazımızda da tartışmıştık.
Mobil uygulama ise asıl değerini şu durumlarda gösteriyor: kullanıcının sık sık, neredeyse günlük geri döndüğü bir kullanım varsa; telefonun kamerasına, konumuna, bildirimine, çevrimdışı çalışmaya ihtiyaç duyuyorsanız; ya da bir sadakat/üyelik ilişkisi kurup ana ekranda yer tutmak istiyorsanız. Bir kargo takip firması, bir spor salonu üyelik uygulaması, saha ekibinin kullandığı bir sipariş aracı — bunlar uygulamanın gerçekten fark yarattığı yerler.
İşin aslı, birçok müşterimiz için en sağlıklı başlangıç ikisinin ortası oluyor: önce güçlü bir mobil web, ardından iş hacmi ve kullanıcı alışkanlığı oturduğunda uygulama. Kararı baştan verirken "rakipte var" demek yerine "kullanıcım bunu haftada kaç kez açar" diye sormak, sonradan çok para kurtarıyor.
Native mi, cross-platform mı?
Teknik tarafın ilk büyük çatalı bu. İki telefon dünyası var: iPhone'ların iOS'u ve Android. Bir uygulamanın ikisinde de çalışması gerekiyor ve bunu başarmanın iki yolu var.
Native geliştirmede her platform için ayrı, o platformun kendi diliyle yazılmış uygulama üretilir. Performans ve cihazın en uç özelliklerine erişim konusunda tavan buradadır; buna karşılık iki ayrı kod tabanı, kabaca iki ayrı emek demektir.
Cross-platform (ya da hibrit) tarafta ise tek bir kod tabanı yazılır, o kod hem iOS hem Android için derlenir. Bugün React Native ve Flutter gibi olgun teknolojiler sayesinde bu yaklaşım, birkaç yıl öncesine göre çok daha güçlü; çoğu ticari uygulama için performans farkı kullanıcının gözle göreceği seviyenin altında kalıyor.
Uygulamada çoğu işletme için cross-platform tarafı tercih ediyoruz, çünkü tek ekiple iki platformu birden yürütmek hem maliyeti hem de yayın sonrası bakımı belirgin biçimde hafifletiyor. Native'e yöneldiğimiz durumlar daha özel: ağır grafik, yoğun kamera/sensör işleme, oyunlaştırma ya da cihazın en yeni donanım özelliğine ilk gün erişme ihtiyacı varsa. Yani seçim bir moda meselesi değil, projenin ne yaptığıyla ilgili bir karar. Hangi yolun sizin işinize oturduğunu konuşmak, genelde ilk görüşmenin ana gündemi oluyor; bu kararı özel yazılım geliştirme sürecinin ilk adımında netleştiriyoruz.
MVP: en az özellikle başlayıp yolda öğrenmek
Mobil uygulama projelerinin en çok para yaktığı yer, teknoloji seçimi değil — baştan her şeyi birden yapmaya kalkmak. Aklınızdaki uygulamanın tam sürümü otuz özellik barındırıyor olabilir. Bunların tamamını ilk günde yaptırırsanız iki risk alırsınız: proje aylarca uzar ve kullanıcı daha tek kez açmadan koca bir bütçe harcanmış olur.
Burada MVP devreye giriyor — "Minimum Viable Product", yani işi gören en sade sürüm. Fikir basit: uygulamanızın var oluş sebebini oluşturan çekirdek işlevi önce yayınlayın, gerçek kullanıcıyla sınayın, geri bildirime göre büyütün.
Bir örnekle somutlaştıralım. Diyelim ki saha satış ekibi için bir sipariş uygulaması yaptıracaksınız. Tam hayalde; harita entegrasyonu, performans panosu, prim hesabı, çevrimdışı senkron, yönetici onay akışı var. MVP'de ise yalnızca şu olur: temsilci müşteriyi seçer, ürünleri listeler, siparişi kaydeder. Üç hafta sonra ekip bunu sahada kullanmaya başlar; gerçek kullanımdan çıkan "şu da olsa" listesi, masa başında hayal ettiğiniz listeden neredeyse her zaman daha isabetli oluyor.
Bize kalırsa bir uygulamayı doğru büyütmenin en güvenli yolu bu. Hem riski küçük tutar, hem de parayı gerçekten işe yarayan özelliklere yönlendirirsiniz. Bu aşamalı ilerleyişin bir özel yazılım projesinde nasıl kurulduğunu özel yazılım projesi nasıl yürür yazımızda ayrıntısıyla anlattık.
Maliyeti asıl belirleyen şey ne?
"Mobil uygulama ne kadar?" sorusuna dürüst tek bir rakamla cevap veren herkese temkinli yaklaşın. Bir ev ne kadar sorusu gibi bu: kaç metrekare, kaç oda, hangi malzeme? Fiyatı belirleyen asıl değişkenleri konuşmak, havada bir sayı söylemekten çok daha işe yarar.
En çok ağırlığı olan birkaç faktör şöyle:
- Özellik sayısı ve karmaşıklığı. Basit bir vitrin uygulamasıyla, canlı konum takibi ve ödeme içeren bir uygulama aynı kulvarda değildir. Her yeni akış, tasarım + geliştirme + test yükü ekler.
- Platform tercihi. İki native uygulama mı yoksa tek cross-platform kod mu — bu, geliştirme eforunu doğrudan etkiler.
- Arka uç (backend) ihtiyacı. Uygulama tek başına çalışan bir araç mı, yoksa kullanıcı hesapları, veritabanı, yönetim paneli ve sunucu tarafında bir sistem mi istiyor? Çoğu ciddi uygulamanın görünmeyen ama en büyük kısmı burasıdır.
- Entegrasyonlar. Sanal POS ile ödeme alma, SMS/bildirim servisleri, kargo, muhasebe ya da mevcut sisteminizle veri alışverişi — her bağlantı ayrı bir iş kalemidir.
- Tasarımın özgünlüğü. Hazır bir şablonla mı ilerlenecek, yoksa markaya özel, sıfırdan arayüz mü tasarlanacak?
Pratik tavsiyemiz, bütçeyi tek kalemde değil, MVP ve sonraki aşamalar olarak düşünmek. Önce çekirdek sürümün maliyetini netleştirirsiniz; büyüme kalemlerini de iş döndükçe, önceliklendirerek eklersiniz. Projenizin kapsamına göre yaklaşık bir çerçeve çıkarmak için fiyatlandırma sayfamıza göz atabilir, sonra da gerçek kapsamı birlikte oturup çıkarabiliriz.
App Store ve Google Play'de yayına çıkmak
Uygulama bittiğinde iş kendiliğinden telefonlara düşmüyor; iki mağazanın da kendi kapısından geçmek gerekiyor. Bu kısım çoğu işletmenin hiç düşünmediği ama ihmal edilince sürprizle biten bir aşama.
İki mağazanın da bir geliştirici hesabı var ve ikisinin de üyelik koşulları farklı. Apple tarafında hesap yıllık bir ücrete bağlı ve bir firma için açılacaksa kurumsal kimlik doğrulaması isteniyor; bu doğrulama kimi zaman birkaç gün sürebiliyor. Google tarafında ise tek seferlik bir kayıt ücreti var. Bu hesapların uygulamanın sahibi adına, sizin mülkiyetinizde açılması çok önemli — uygulamanız, sertifikalarınız ve kullanıcı verileriniz sizin hesabınızda durmalı.
Yükledikten sonra inceleme süreci geliyor. Apple uygulamaları insan eliyle gözden geçirdiği için burada bir gün-birkaç gün beklemek olağan; üstelik gizlilik, içerik ve işlev kurallarına uymayan uygulamalar geri çevrilebiliyor. Android tarafı genelde daha hızlı ilerliyor ama o da kendi politika denetiminden geçiyor.
Uygulamada ilk yayında en çok tökezlenen noktalar hep aynı: eksik gizlilik politikası, uygulamanın hangi veriyi neden topladığını açıklamayan formlar, hesap silme seçeneğinin bulunmaması. Bunları baştan doğru kurduğunuzda süreç pürüzsüz ilerliyor. Biz teslimi yalnızca "kod bitti" noktasında değil, uygulama ilgili mağazalarda canlıya çıkıp telefonunuza inene kadar olan işin tamamı olarak görüyoruz.
Yayın, bitiş değil başlangıç
Bir web sitesi yıllarca el değmeden ayakta durabilir; mobil uygulama öyle değil. Telefon işletim sistemleri yılda en az bir büyük sürüm çıkarıyor ve her yeni iOS ya da Android, eski uygulamalarda bir şeyleri bozabiliyor. Güncellenmeyen bir uygulama bir süre sonra ya düzgün açılmıyor ya da mağaza tarafından listeden düşürülüyor.
Yani bir uygulama, canlı tutulması gereken bir varlık. Yayın sonrası bakım kabaca üç işi kapsıyor: işletim sistemi güncellemelerine uyum, kullanıcıdan ve çökme raporlarından gelen hataların giderilmesi, bir de zamanla eklenen yeni özellikler. Bu yükü baştan kabul etmek, "yaptırdım bitti" sanıp bir yıl sonra sıfırdan başlamak zorunda kalmaktan çok daha ekonomik.
Bu yüzden projenin ilk gününde bakımın nasıl yürüyeceğini de konuşuyoruz. Kimi müşteri bu işi tümüyle bize bırakmayı tercih ediyor, kimi kendi ekibini devreye almak istiyor. Hangisi olursa olsun, ürettiğimiz kodun mülkiyeti baştan sona sizde kaldığı için yarın başka bir ekiple de yola devam edebilirsiniz — kimseye kilitli kalmıyorsunuz.
Sıkça Sorulan Sorular
Mobil uygulama yaptırmak ne kadar sürer?
Kapsamına göre değişir, ama sağlıklı bir çerçeve verelim: iyi tanımlanmış bir MVP için genelde birkaç haftadan birkaç aya uzanan bir bantta konuşuyoruz. Tam donanımlı, çok sayıda entegrasyonu olan bir uygulama doğal olarak daha uzun sürer. Süreyi en çok kısaltan şey, baştan dar ve net bir kapsamla başlamak; en çok uzatan şey ise iş yürürken sürekli yeni özellik eklemek.
Tek uygulamayla hem iPhone hem Android'e çıkabilir miyim?
Evet, cross-platform geliştirme tam olarak bunu sağlıyor. Tek kod tabanıyla her iki mağaza için de uygulama üretilir. Çoğu ticari proje için bu yaklaşım hem maliyeti hem de yayın sonrası bakımı belirgin biçimde azaltıyor; ikisini ayrı ayrı native yazmayı ise yalnızca gerçekten gerektiren özel projelerde öneriyoruz.
Önce web sitesi mi yoksa uygulama mı yapmalıyım?
Çoğu durumda önce mobil uyumlu bir web sitesi daha mantıklı: daha hızlı yayınlanır, Google'dan bulunur, kullanıcı hiçbir şey indirmez. Uygulamaya ise kullanıcının sık geri döndüğü, bildirim/konum/kamera gibi telefon özelliklerine ihtiyaç duyan bir kullanım olduğunda geçmek daha doğru. İkisini birbirinin alternatifi değil, aşamaları olarak düşünmek genelde en sağlıklısı.
Uygulama içinde ödeme alabilir miyim?
Alabilirsiniz. Fiziksel ürün ya da hizmet satışında sanal POS üzerinden kart ile ödeme, havale/EFT gibi yöntemler uygulamaya entegre edilebilir. Yalnız dikkat edilecek bir nokta var: Apple ve Google, uygulama içinde satılan dijital içerik için kendi ödeme sistemlerini zorunlu tutabiliyor. Fiziksel ürün ve hizmette bu kısıt yok; kapsamınıza göre doğru yöntemi birlikte belirliyoruz.
Uygulamanın kaynak kodu bende mi kalıyor?
Evet. Ürettiğimiz kodun ve verilerin mülkiyeti baştan sona sizde olur; bunu yazılı sözleşmeyle güvence altına alıyoruz. Mağaza hesapları da sizin adınıza açılır. Yarın dilerseniz başka bir ekiple devam edebilir, bize bağımlı kalmazsınız — bir uygulamanın en değerli varlığı, üzerinde tam söz sahibi olmanızdır.
Nereden başlamalı?
Mobil uygulama kararı, teknoloji seçmekten önce doğru soruyu sormakla başlıyor: kullanıcım bunu ne sıklıkla, ne için açacak? Bu sorunun cevabı netleştiğinde platform, kapsam, bütçe ve zaman gibi başlıklar kendiliğinden yerine oturuyor. Gerisi, çekirdek bir sürümle sahaya çıkıp gerçek kullanımdan öğrenerek büyütmek.
Aklınızdaki fikri ve kullanıcınızı anlatın, biz de hangi yolun işinize oturduğunu, kabaca nasıl bir yol haritası çıkacağını açıkça konuşalım. Başlamak için bize yazmanız yeterli.
Etiketler
