İlk görüşmede en sık duyduğumuz cümle şu: "Yemeksepeti gibi bir şey istiyoruz, kaça olur?" Bu sorunun tek bir cevabı yok, çünkü o cümlenin içinde birbirinden çok farklı üç dört uygulama saklı. Müşterinin sipariş verdiği uygulama, restoranın siparişi gördüğü ekran, kuryenin telefonu ve hepsini yöneten panel. Bunların hangisini istediğinizi konuştuğumuz anda fiyat da şekillenmeye başlıyor.
Bu yazıda mobil uygulama yaptırma maliyetini neyin belirlediğini, sahada karşılaştığımız haliyle anlatıyoruz. Rakam vermiyoruz. Teklifinizi okuyabilmeniz, neyin neden pahalı olduğunu görebilmeniz için yazıyoruz.
Fiyatı asıl belirleyen şey: ekranlar ve roller
Platform ya da teknoloji seçiminden önce şuna bakın: uygulamada kaç farklı kişi var ve her biri neyi görüyor?
Tek rollü bir uygulamada herkes aynı ekranları görür. Bir katalog uygulaması böyledir. Ürünler, kampanyalar, iletişim. Sipariş uygulamasında ise müşteri, işletme, kurye ve yönetici ayrı ekranlar, ayrı yetkiler, ayrı bildirimler ister. Her rol eklendiğinde iş toplanmaz, çarpılır. Çünkü roller birbirine bağlıdır: müşteri siparişi iptal ettiğinde kuryenin ekranında ne olacağını da birinin tasarlaması, kodlaması ve test etmesi gerekir.
Bu yüzden teklif istemeden önce yapabileceğiniz en faydalı şey, kullanıcı tiplerini ve her birinin yapacağı işleri bir sayfaya yazmaktır.
iOS, Android ya da ikisi
iPhone ve Android için uygulama yaptırmak isteyenlerin bir kısmı, iki platformun iki ayrı proje olduğunu düşünüyor. Bugün çoğu iş uygulaması tek kod tabanından iki platforma birden çıkan teknolojilerle yazılıyor ve bu yaklaşım maliyeti belirgin biçimde düşürüyor. Her platform için ayrı (native) kod yazmak, Bluetooth cihazlarla yoğun iletişim, arka planda sürekli çalışan konum takibi ya da ağır grafik işleri gibi özel durumlarda anlam kazanıyor. Çoğu işletme için doğru başlangıç ortak kod tabanıdır.
Ortak kod, iki platformu bedavaya getirmez. Test iki ayrı cihaz ailesinde yapılır, mağaza süreçleri iki kez yürütülür. Yalnızca kendi personelinize dağıtacağınız bir uygulamada şirket telefonlarının hepsi aynı işletim sistemindeyse tek platformla başlamak mantıklıdır.
Mağaza yayını: hesaplanmayan iş kalemi
Teklifte genelde tek satırla geçer ama bu kalem gerçek iş ister.
Apple tarafında geliştirici hesabını kişi adına ya da şirket adına açabilirsiniz. Şirket adına açılacaksa Apple bir D-U-N-S numarası ister ve bu numaranın alınması zaman alabilir. Uygulamanın mağazada şirketinizin adıyla görünmesini istiyorsanız bu işe projenin başında girişin. Google Play'de de kişisel ve kurumsal hesap ayrımı var. Yeni açılan kişisel hesaplarda uygulamayı herkese açmadan önce belirli bir süre kapalı testle yürütme şartı bulunuyor. Kurumsal hesapla açmak bu açıdan işi kolaylaştırıyor.
Sık yapılan bir hata: hesapları ajansın adına açtırmak. Yarın başka bir firmayla çalışmak istediğinizde uygulamanızı devralmak zorlaşır. Hesaplar sizin adınıza olmalı, biz yalnızca yetkili olarak ekleniriz.
Mağaza incelemesinde uygulamaların en sık takıldığı noktalar da bellidir:
- Yalnızca web sitesini çerçeve içinde gösteren uygulamalar, Apple'ın "asgari işlevsellik" kuralına takılır.
- Giriş gerektiren bir uygulamada inceleme ekibine deneme hesabı verilmezse uygulama incelenmeden geri döner.
- Kullanıcı hesap açabiliyorsa, hesabını uygulama içinden silebilmesi de gerekir. Her iki mağaza da bunu istiyor.
- Gizlilik politikası bağlantısı ve konum, kamera gibi izinlerin neden istendiğini anlatan açıklamalar eksik olmamalı.
- Arka planda konum kullanan uygulamalar Google Play'de ayrıca beyan formu doldurur ve gerekçe göstermek zorundadır.
Bunların her biri bir düzeltme turu demektir. Deneyimli bir ekip bu maddeleri baştan kapsamın içine alır.
Ödeme: dijital ürün mü, fiziksel ürün mü?
Uygulamanızda para alınacaksa önce ne sattığınızı netleştirin. Yemek, yedek parça, randevu ya da kargo ile giden bir ürün satıyorsanız kendi sanal POS'unuzla ödeme alabilirsiniz. Uygulama içinde açılan dijital bir içerik, abonelik ya da premium özellik satıyorsanız mağazaların kendi ödeme sistemini kullanmanız ve komisyon ödemeniz gerekir. Bu ayrım iş modelinizi doğrudan etkiler, teklif aşamasında konuşulmalıdır.
Entegrasyonlar
Uygulamanın başka bir sistemle konuştuğu her nokta ayrı bir iş kalemidir:
- e-Fatura ve e-Arşiv. Karşı taraf e-Fatura mükellefiyse e-Fatura, değilse (son tüketici gibi) e-Arşiv fatura kesilir. Bu iş genellikle çalıştığınız özel entegratörün arayüzü üzerinden yapılır. Hangi entegratörü kullandığınızı ilk toplantıda söylemeniz işi hızlandırır.
- Mevcut ERP ya da muhasebe programınız. Programın dışarıya veri veren bir arayüzü yoksa iş uzar, bazen hiç yapılamaz.
- Harita, konum ve rota.
- Anlık bildirim. iOS'ta ve güncel Android sürümlerinde kullanıcıdan izin istenir. İzni reddeden kullanıcıya nasıl ulaşacağınızı da düşünmek gerekir.
- SMS, kargo firmaları, bayi sistemleri.
Hazır ve belgeleri düzgün bir arayüze bağlanmak kısa sürer. Belgeleri eksik ya da test ortamı olmayan bir sisteme bağlanmak ise tahmin edilenden uzun sürer. Bu riski teklifte açıkça yazan firma, size dürüst davranıyordur.
Yönetim paneli ve sunucu
Telefonda görünen kısım işin yarısıdır. Verinin tutulduğu sunucu, kullanıcı hesapları ve sizin ürün, fiyat, kampanya girdiğiniz web paneli ayrı bir geliştirme gerektirir. Teklif yalnızca telefondaki ekranlar üzerinden hesaplandıysa panel çoğu zaman sonradan ayrı bir kalem olarak karşınıza çıkar. Teklifinizde panelin olup olmadığına ve panelde neleri yapabileceğinize mutlaka bakın.
Sahada çalışan ekipler için bir konu daha var: çevrimdışı çalışma. Şantiyede ya da çekmeyen bir depoda kayıt girilecekse veri telefonda saklanır, bağlantı gelince sunucuyla eşitlenir. Aynı kaydı iki kişi değiştirdiğinde hangisinin geçerli olacağı gibi kurallar yazılmalıdır. Bu özellik geliştirme yükünü ciddi artırır, gerçekten gerekiyorsa isteyin.
KVKK: aydınlatma ile açık rıza aynı şey değil
Kişisel veri topluyorsanız kullanıcıyı bilgilendirmek her durumda zorunludur. Buna aydınlatma denir. Açık rıza ise ayrı bir şeydir ve yalnızca kanundaki diğer hukuki sebeplerin karşılamadığı işlemler için alınır, örneğin pazarlama iletileri için. Sık gördüğümüz hata, aydınlatma metni ile açık rızayı tek bir onay kutusuna sıkıştırmak ya da hizmeti kullanmayı açık rızaya bağlamaktır. Bu ekranların doğru kurgulanması küçük ama atlanmaması gereken bir iştir. Metinlerin içeriği için hukuk danışmanınızla çalışmanızı öneririz.
Hangi uygulama hangi seviyede?
Aşağıdaki tablo fiyat değil, göreli karmaşıklık gösterir.
| Uygulama türü | Tipik içerik | Göreli karmaşıklık |
|---|---|---|
| Katalog, tanıtım | Ürün listesi, kampanya, bildirim | Düşük |
| Randevu, rezervasyon | Takvim, hatırlatma, basit panel | Orta |
| Saha ekibi uygulaması | Görev, fotoğraflı rapor, konum, çevrimdışı | Orta ile yüksek arası |
| Sipariş, e-ticaret | Ödeme, sepet, kurye, birden çok rol | Yüksek |
| Çok işletmeli platform | Her işletmeye ayrı panel, raporlar | Çok yüksek |
Tek platformlu basit bir katalog uygulaması ile ödeme ve canlı kurye takibi içeren bir sipariş uygulaması arasında kat kat fark olur.
Sakarya'da kimler için anlamlı?
Her işletmenin uygulamaya ihtiyacı yok. Müşteriniz sizi yılda birkaç kez arıyorsa telefonuna bir uygulama indirmez. Bu durumda iyi bir mobil uyumlu site daha doğru yatırımdır, Sakarya web tasarım sayfamızda bunu anlattık.
Uygulamanın karşılığını aldığını gördüğümüz durumlar şunlar. OSB'lerde üretim yapan firmalarda arıza bildirimi, bakım takibi, depo sayımı gibi iç süreçler. Servis, montaj ve şantiye ekiplerinin işi telefondan alıp fotoğraflı kapatması. Adapazarı'nda aracı platformlara komisyon ödemekten yorulan restoranların kendi siparişini alması; kendi ürünümüz Vero (veroyemek.com) tam bu ihtiyaçtan çıktı. Bir de bayilerinin sipariş ve cari bilgisini tek yerden görmek isteyen dağıtım firmaları.
Uygulama sahadaki veriyi muhasebeye ya da üretime bağlayacaksa iş bir ERP projesine dönüşür. Bu yaklaşımı Sakarya ERP yazılımı sayfasında ayrıca anlattık.
Fiyat teklifini doğru karşılaştırmak için sorulacak sorular
Mobil uygulama yaptırma fiyatları arasında büyük fark görmeniz normal. Farkın bir kısmı kapsamdan, bir kısmı da teklifte yazmayanlardan gelir. Teklifleri yan yana koymadan önce şunları sorun:
- Hangi platformlar kapsamda? Ortak kodla mı, ayrı ayrı mı yazılacak?
- Yönetim paneli dahil mi, panelde neler yapılabilecek?
- Hangi entegrasyonlar kapsamda, hangileri değil?
- Mağaza hesapları kimin adına açılacak, yayın işlemlerini kim yürütecek?
- Kaynak kod ve veri kime ait olacak? Sözleşmede yazıyor mu?
- Sunucu gideri teklifte var mı?
- Yayından sonra hata düzeltmeleri ne kadar süre kapsamda?
- Her yıl gelen iOS ve Android güncellemelerine uyum nasıl ücretlendirilecek?
- Geliştirme sürerken uygulamayı kendi telefonumda deneyebilecek miyim?
Bu soruların cevabı belirsiz kalan bir teklif, kâğıt üzerinde ucuz görünse de proje ilerledikçe pahalılaşır.
Bütçeyi düşürmenin doğru yolları
Test ve güvenlikten kısmak bütçeyi düşürmez, masrafı sonraya erteler. İşe yarayan yollar başka.
İlk sürümü küçük tutun. Yalnızca asıl sorunu çözen özelliklerle yayına çıkan bir ilk sürüm (MVP), size gerçek kullanıcı davranışını gösterir. Toplantıda "mutlaka olsun" denen özelliklerin bir kısmının sonradan hiç kullanılmadığını çok gördük.
İki platform şartsa ortak kodla ilerleyin. Kitlenizin büyük kısmı tek platformdaysa oradan başlayın.
Giriş, ayarlar, listeler gibi standart ekranlarda hazır bileşen kullanın. Özel tasarım emeğini müşterinin her gün gördüğü iki üç ekrana ayırın.
Kapsamı yazılı netleştirin. Proje ortasında eklenen "küçük bir şey" çoğu zaman küçük değildir, çünkü başka ekranlara ve rollere dokunur.
PAYTECH'te süreç
PAYTECH 2018'den beri Erenler'deki ofisinden yazılım geliştiriyor. Vero, inşaat ERP'si Bricker, ortak kasa ve finans uygulaması Ortakasa ve gayrimenkul için 3B tanıtım çözümü PAYWORLD kendi geliştirdiğimiz ürünler.
İşe bir keşif toplantısıyla başlıyoruz. Ofisimize Adapazarı, Serdivan, Sapanca, Hendek ya da Akyazı'dan kısa sürede ulaşılıyor. Yüz yüze oturup ekranları kâğıda çizmek, e-posta ile haftalarca yazışmaktan daha hızlı netlik veriyor. Ardından ekran listesi, roller, entegrasyonlar ve bakım koşulları yazılı teklife dönüşüyor. Geliştirme sırasında ara sürümleri kendi telefonunuzda deniyorsunuz.
Hizmetin ayrıntıları için Sakarya'da mobil uygulama geliştirme sayfasına, teknik kapsam için mobil uygulama hizmetimize bakabilirsiniz.
Sık sorulan sorular
Teklif almadan önce ne hazırlamalıyım?
Uygulamanın çözeceği ana sorunu, kullanıcı tiplerini ve her birinin yapacağı işleri yazmanız yeterli. Beğendiğiniz ya da beğenmediğiniz uygulamaların ekran görüntülerini getirirseniz konuşma hızlanır.
Web sitemi uygulamaya dönüştürmek daha ucuz olmaz mı?
Siteyi bir çerçeve içinde gösteren uygulamalar Apple incelemesinden genellikle geçmez. Geçse bile kullanıcıya siteden fazlasını vermez. Uygulamanın telefona özgü bir işi olmalı: bildirim, kamera, konum ya da çevrimdışı kullanım gibi.
Uygulama yayınlandıktan sonra gider devam eder mi?
Evet. Sunucu gideri, mağaza üyelikleri ve bakım süreklidir. Apple ve Google her yıl yeni sürüm çıkarır, uygulamanın bunlara uyumlu tutulması gerekir.
Kaynak kod bana mı ait olur?
Olması gerekir ve sözleşmede yazmalıdır. Kaynak kodun, mağaza hesaplarının ve verinin kimde kalacağını teklif aşamasında sorun.
Adapazarı'nda mobil uygulama yaptırmak için ofise gelmek şart mı?
Şart değil, görüşmeleri çevrim içi de yapıyoruz. Yine de yakındaysanız ilk toplantıyı ofisimizde yapmanızı öneririz.
Aklınızdaki uygulamayı birkaç cümleyle anlatın, kapsamı belli bir teklif hazırlayalım. Teklif almak için iletişim sayfamızdan yazabilir, 0532 309 89 54 numarasını arayabilir ya da info@paytechyazilim.com adresine e-posta gönderebilirsiniz.




