Mobil Uygulama Nasıl Yapılır? Adım Adım Rehber (2026)

Kısa cevap: Mobil uygulama yapmak tek bir "kodlama" işi değil, süregelen bir üründür. Sağlıklı bir uygulamanın omurgası şu adımlardan geçer: fikri ve pazarı doğrulamak, hedef kitleyi tanımlamak, kapsamı ve minimum uygulanabilir sürümü (MVP) belirlemek, teknik analiz yapıp platform ile yaklaşımı seçmek (native veya cross-platform), UI/UX tasarımını kurmak, geliştirmek, gerçek cihazlarda test etmek, App Store ve Google Play'de yayınlamak ve yayından sonra bakım, güncelleme, analiz ve iterasyonla ürünü canlı tutmak. Bu adımların hangi araçla yapılacağı (native, cross-platform, PWA ya da no-code) bütçenize, performans ihtiyacınıza ve zaman çizelgenize bağlıdır; yanlış yaklaşım seçimi çoğu projenin en pahalı hatasıdır. En kritik zihniyet değişikliği ise şudur: mobil uygulama, yayına aldığınız gün biten değil, başlayan bir üründür. "Uygulamayı yaptırınca kullanıcı kendiliğinden gelir" yanılgısı, en yaygın ve en pahalı tuzaktır; yayın işin sonu değil, ortasıdır. Doğru soru "nasıl kod yazılır" değil, "hangi problemi, kimin için, hangi en küçük sürümle çözeceğim ve bunu nasıl büyüteceğim" sorusudur.

Bu rehber, mobil uygulama fikrini kafasında taşıyan ama nereden başlayacağını bilmeyen işletme sahipleri, girişimciler ve karar vericiler için yazıldı. Amacımız size belirli bir teknolojiyi ya da paketi satmak değil; kararı doğru sıraya koyan, para ve zaman kaybettiren hataları önceden görmenizi sağlayan dürüst bir çerçeve sunmak. Yazının sonunda "hangi butona basmalıyım" değil, "bu projeyi nasıl düşünmeliyim" sorusunun cevabına sahip olacaksınız.

Yazıyı baştan sona bir başvuru kaynağı gibi okuyabilir ya da doğrudan sizi ilgilendiren bölüme geçebilirsiniz. Fikir aşamasındaysanız "türler" ve "8 adım" bölümleri; bütçe planlıyorsanız "maliyet" ve "süre" bölümleri; uygulama mı yoksa mobil site mi tereddüdü yaşıyorsanız "uygulama mı mobil site mi" bölümü en değerlisi olacak. Her bölüm kendi başına anlamlıdır, ama asıl fayda bütünü kavramaktan gelir.

Bir bağlam notu: Türkiye artık mobil-ilk bir pazar. DataReportal'ın 2026 verilerine göre ülkedeki mobil bağlantı sayısı nüfusun yaklaşık yüzde 93'üne, internet erişimi yaklaşık yüzde 88 düzeyine ulaştı; web trafiğinin kaynağa göre yaklaşık yüzde 65'i mobil cihazlardan geliyor. Bu ölçekte bir pazarda mobil deneyim artık lüks değil, işin temeli. Ama bu, "herkesin uygulaması olmalı" anlamına gelmez; doğru kararın önce mobil uyumlu bir web mi yoksa gerçek bir uygulama mı olduğunu bu yazıda ayrıştıracağız.

Son bir uyarı: bu yazıdaki tüm parasal rakamlar, süreler, mağaza komisyonları ve pazar payları doğası gereği oynaktır. Amacımız size sabit bir fiyat listesi vermek değil, karar verirken hangi değişkenlere bakmanız gerektiğini göstermektir. Kesin tutar, süre ve komisyon oranları için her zaman resmi kaynaklara ve size özel bir tekliften çıkan analize güvenin; internette dolaşan "şu kadara yapılır" iddialarına değil.

Mobil uygulama nasıl yapılır? 60 saniyelik özet

Aceleniz varsa özet şudur: iyi bir mobil uygulama, "önce doğru problemi bul, sonra en küçük çözümü yayınla, sonra ölçüp büyüt" mantığıyla yapılır. Teknik kalite şarttır ama tek başına yetmez; yanlış problemi çözen, kusursuz kodlanmış bir uygulama yine de başarısız olur. Bu yüzden süreç kodlamayla değil, doğrulamayla başlar.

Sürecin sekiz halkası vardır: fikir ve pazar doğrulama, kapsam ve MVP, teknik analiz ve platform seçimi, UI/UX tasarım, geliştirme, test/QA, mağaza yayını ve bakım/iterasyon. Bu halkaların hiçbiri atlanamaz; atlanan her adım, ilerleyen aşamada katlanarak büyüyen bir maliyet olarak geri döner. Örneğin tasarımı atlayıp doğrudan koda geçmek, ilerde çok daha pahalı yeniden yazımlara yol açar.

İki cümlelik test: "Belirli bir kitlenin, sık yaşadığı ve mevcut çözümlerin iyi karşılamadığı bir ihtiyacını, telefonun kamerası/konumu/bildirimi gibi yeteneklerini kullanarak çözeceğim" diyebiliyorsanız uygulama mantıklıdır. "Aslında bir web sayfası da işi görür ama uygulama daha havalı durur" diyorsanız, önce mobil uyumlu bir web ile başlamak neredeyse her zaman daha akıllıcadır. Bu ayrımı yazının ilerleyen bölümünde bir karar tablosuyla netleştireceğiz.

Bu özet, yazının geri kalanının haritasıdır. Aşağıda önce mobil uygulamanın neden bir "ürün" olduğunu, sonra uygulama türlerini ve doğru yaklaşımın nasıl seçileceğini ele alacağız. Ardından sekiz adımlık süreci tek tek açacak; maliyet, süre, ekip, güvenlik ve monetizasyon gibi karar başlıklarını sıralayacağız. En sonda ise en pahalı yanılgıyı, yani "yaptırınca kullanıcı gelir" beklentisini verilerle ele alıp, doğru zihniyeti oturtacağız.

Mobil uygulama nedir ve neden bir "ürün"dür?

Mobil uygulama, akıllı telefon ve tablet gibi cihazlarda çalışan, belirli bir amacı yerine getiren yazılımdır. Ama teknik tanımdan daha önemli olan zihinsel tanımdır: bir uygulama, bir kere yapılıp rafa kaldırılan bir "proje" değil, sürekli bakım, güncelleme ve iyileştirme gerektiren bir "üründür". Bu ayrımı en baştan içselleştirmek, sonraki tüm kararları doğru zemine oturtur.

Bir web sitesi de yazılımdır, ama mobil uygulamanın oyun alanı farklıdır. Uygulama işletim sistemine (iOS/Android) daha yakın çalışır; kameraya, konuma, bildirimlere, çevrimdışı depolamaya ve donanım sensörlerine doğrudan erişebilir. Bu güç, beraberinde iki mağazanın kurallarına uyma, iki platformu ayrı ayrı destekleme ve işletim sistemi güncellemelerini takip etme sorumluluğunu getirir. Yani uygulama daha güçlüdür ama daha bakımlıdır.

"Ürün" bakış açısının pratik sonucu şudur: bütçenizi yalnızca ilk geliştirmeye göre değil, uygulamanın yaşam döngüsünün tamamına göre planlarsınız. İşletim sistemleri her yıl güncellenir, cihazlar değişir, kullanıcı beklentileri yükselir; bakımsız bir uygulama birkaç yıl içinde eskir, çöker ve mağazadan düşer. Bu yüzden Alis Dijital olarak her mobil projeyi baştan "fikirden yayına ve sonrasında bakıma" kadar bir bütün olarak kurgularız.

Bu ürün bakışı, beklentileri de doğru ayarlar. Bir web sitesi çoğu zaman bir kere yapılıp uzun süre küçük dokunuşlarla yaşayabilir; mobil uygulama ise iki ayrı işletim sisteminin sürekli değişen kurallarına, cihaz çeşitliliğine ve kullanıcının yükselen beklentisine tabi olduğu için daha canlı bir bakım ritmi ister. Bunu bir dezavantaj değil, ürünün doğası olarak kabul etmek, ilerleyen aylarda hayal kırıklığını önler.

Bir başka pratik sonuç, sahiplik meselesidir. Uygulamanın kaynak kodu, tasarım dosyaları, mağaza hesapları ve sunucu erişimleri sizin varlıklarınızdır; bir ajans ya da freelancer'la çalışsanız bile bunların sizin adınıza ve sizin erişiminizde olması gerekir. Bu ayrıntı, uygulamanız büyüdüğünde ya da geliştirici değiştirmek istediğinizde kritik hale gelir; en baştan netleştirilmesi gereken bir maddedir.

Uygulama mı yoksa özel yazılım kararı mı?

Mobil uygulama, çoğu zaman daha geniş bir "özel yazılım" ihtiyacının bir yüzüdür. Bir işletmenin gerçek ihtiyacı bazen sadece bir mobil arayüz değil; arka planda çalışan bir sipariş, stok, randevu ya da operasyon sistemidir. Bu yüzden "hangi uygulamayı yaptırayım" sorusuna geçmeden önce, "hangi iş problemini çözüyorum" sorusuna dürüstçe cevap vermek gerekir.

Bu noktada hazır bir çözümle mi yoksa sıfırdan özel yazılımla mı ilerleyeceğiniz kritik bir çataldır. Standart bir ihtiyaç için hazır bir platform yeterliyken, size özgü bir iş akışı için özel yazılım kaçınılmaz olur. Bu kararın mantığını hazır site mi özel yazılım mı yazımızda ayrıntılı ele aldık; mobil tarafta da aynı mantık geçerlidir.

Özetle mobil uygulama, mevcut dijital varlığınızın tamamlayıcısıdır, ikamesi değil. Çoğu işletme için doğru sıralama önce sağlam bir dijital altyapı (web, e-ticaret, backend), sonra bu altyapının üstüne oturan bir mobil uygulamadır. Uygulamayı boşlukta değil, bu bütünün parçası olarak tasarlamak, hem maliyeti hem başarı şansını doğrudan etkiler.

Bu çerçeve, "önce ne yapmalıyım" sorusuna da yön verir. Eğer henüz sağlam bir web varlığınız, düzenli bir veri akışınız ya da net bir satış süreciniz yoksa, uygulama bu eksiklikleri kapatmaz; üstüne bir katman daha ekleyip karmaşıklığı artırır. Doğru sıralama, önce temeli sağlamlaştırmak, sonra o temelin üstüne mobil deneyimi kurmaktır. Bu yüzden ilk toplantıda çoğu zaman "hemen uygulamaya başlayalım" demeyiz; önce hangi katmanın gerçekten eksik olduğunu birlikte tespit ederiz.

Uygulama türleri: native, cross-platform, hybrid, PWA ve no-code

Mobil uygulama tek bir teknolojiyle yapılmaz; beş temel yaklaşım vardır ve doğru olanı seçmek projenin en belirleyici kararlarından biridir. Bu yaklaşımlar farklı maliyet, performans ve esneklik dengeleri sunar; "en iyisi" diye tek bir cevap yoktur, yalnızca sizin ihtiyacınıza "en uygunu" vardır.

Native uygulama, her platform için o platformun kendi diliyle (iOS için Swift, Android için Kotlin) ayrı ayrı yazılır. En yüksek performansı ve donanıma tam erişimi verir; ama iki ayrı kod tabanı demek olduğu için en yüksek maliyet ve süreyi de beraberinde getirir. Cross-platform yaklaşım (Flutter, React Native) ise tek kod tabanından iki platforma birden çıkış yapmayı sağlar; çoğu KOBİ iş uygulaması için performansı fazlasıyla yeterli olan, maliyet ve süre avantajı sunan dengeli bir yoldur.

Hybrid uygulamalar (WebView, Ionic) bir web uygulamasını uygulama kabuğuna sarar; en ucuz yollardan biridir ama native his ve akıcılık genellikle zayıf kalır, bu yüzden basit içerik ya da iç kullanım araçları için uygundur. PWA (Progressive Web App) ise tarayıcıdan çalışan ama uygulama gibi davranan bir web deneyimidir; mağaza gerektirmez, arama motorlarından indekslenir ve kurulum sürtünmesi yoktur, ama native erişimi sınırlıdır. No-code/low-code platformları (FlutterFlow, Bubble, Glide) ise kod yazmadan görsel araçlarla uygulama kurmayı sağlar; en hızlı ve ucuz yol olsalar da özelleştirme, ölçek ve platform bağımlılığı konusunda sınırları vardır.

Hangi tür kime uygun?

Türü seçerken sihirli formül değil, üç soru işe yarar: uygulamanın performans ihtiyacı ne kadar yüksek, bütçe ne kadar esnek ve zaman çizelgesi ne kadar sıkışık. Kamera-yoğun, oyun ya da artırılmış gerçeklik gibi işler native'e yaklaşırken; standart iş uygulamaları cross-platform tarafında rahatça çözülür.

Önemli bir uyarı: tür seçimi, geri dönüşü pahalı bir karardır. Bir yaklaşımla epey yol aldıktan sonra başka bir yaklaşıma geçmek çoğu zaman baştan yazmak demektir. Yine de bazı geçişler mantıklıdır; örneğin fikri no-code bir MVP ile hızlıca doğrulayıp, talep netleşince cross-platform bir sürüme geçmek meşru ve sık kullanılan bir stratejidir. Kilit ilke, bugünkü kararı gelecekteki büyümeyi düşünerek vermektir.

PWA tarafında bir ince ayrım daha var: iOS'ta bildirimler ancak kullanıcı uygulamayı "Ana Ekrana Ekle" ile eklediğinde ve belirli sürümlerden itibaren çalışır; arka plan işlemleri de sınırlıdır. Bu yüzden bildirimi ve çevrimdışı gücü işin kalbine koyan projeler için PWA tek başına yetmeyebilir. Mobil uyumlu web ile PWA arasındaki farkı ve responsive tasarımın temellerini mobil uyumlu web tasarım rehberi yazımızda bulabilirsiniz.

No-code tarafında da benzer bir denge var. Bu araçlar bir fikri günler içinde ayakta bir prototipe çevirmek için harikadır; yatırımcıya göstermek, iç ekipte kullanmak ya da talebi ölçmek için hızlı bir yol sunarlar. Ancak kullanıcı sayınız arttıkça, çok özel bir özellik gerektiğinde ya da platformun izin verdiği sınırlara dayandığınızda duvara toslarsınız. En büyük risk platform kilididir: verinizi ve mantığınızı o platformdan çıkarıp gerçek bir kod tabanına taşımak, çoğu zaman baştan yazmak kadar emek ister.

Bu yüzden pratik bir kural şudur: no-code'u bir "varış noktası" değil, bir "başlangıç rampası" olarak kullanın. Fikri doğrulayana, ilk gerçek kullanıcıları görene ve gerçekten neye ihtiyaç duyduğunuzu öğrenene kadar no-code fazlasıyla iş görür. Talep netleştiğinde ve ölçek büyüdüğünde, öğrendiklerinizle cross-platform ya da native bir sürüme geçmek çok daha bilinçli bir yatırım olur; çünkü artık neyi neden yaptığınızı biliyorsunuzdur.

Native mi cross-platform mı? Dengeli bir karşılaştırma

Bu, mobil projelerde en çok tartışılan sorudur ve cevabı bir teknoloji dini değil, sizin ekip ve gereksinim gerçekliğinizdir. 2026'da iki cross-platform çatının native'e göre performans açığı büyük ölçüde kapandı; çoğu uygulama için performans artık ayırt edici bir faktör olmaktan çıktı. Bu, analist ve pratisyen çevrelerinde yaygın bir görüş olsa da her senaryo için mutlak bir gerçek değildir.

Native'in gerçekten şart olduğu durumlar bellidir: yüksek kare hızı gerektiren oyunlar, 3D ve artırılmış gerçeklik, sensörlerden gerçek zamanlı yoğun veri işleyen uygulamalar ve en düşük gecikmenin kritik olduğu senaryolar. Buralarda platformun kendi diliyle yazmak, hem performansı hem de en yeni donanım özelliklerine erişimi maksimuma çıkarır. Bu tür projelerde native'in ek maliyeti, elde edilen kalite farkıyla haklı çıkar.

Cross-platform ise çoğu KOBİ ve kurumsal iş uygulaması için mantıklıdır: e-ticaret, rezervasyon, sadakat programı, ürün kataloğu, saha ekibi araçları ve iç operasyon uygulamaları bu kategoriye girer. Tek kod tabanından iki platforma çıkmak, hem ilk maliyeti hem de sonraki bakım yükünü ciddi biçimde azaltır. Karar verirken teknolojinin "havalılığına" değil, iş ihtiyacına ve ekibinizin uzmanlığına bakmak gerekir.

Flutter mı React Native mı?

Cross-platform tarafına karar verdiyseniz, önünüze genelde iki olgun seçenek çıkar: Flutter ve React Native. İkisi de üretim ölçeğinde kanıtlanmış, geniş toplulukları olan sağlam çatılardır; aralarındaki seçim çoğu zaman "hangisi daha iyi" değil, "ekibiniz hangisinde güçlü ve projeniz hangisine daha uygun" sorusudur.

Flutter, Google'ın Dart diline dayanır ve kendi render motorunu (Impeller) kullanarak arayüzü doğrudan çizer; bu, iki platformda piksel düzeyinde tutarlı bir görünüm sağlar. Cross-platform pazarında kaynağa göre yaklaşık yüzde 46 gibi güçlü bir paya sahip olduğu belirtilir, ancak bu oranlar dönemsel ve oynaktır. React Native ise JavaScript/TypeScript kullanır; bu da onu dünyanın en geniş geliştirici havuzuna açar. Yeni Mimari (Fabric, JSI) ile performansı ve gerçek native bileşen kullanımı belirgin biçimde iyileşti; pazar payı kaynağa göre yaklaşık yüzde 35-38 aralığında gösterilir.

Karar kriteri şudur: eğer ekibinizde ya da partnerinizde güçlü bir JavaScript/web tecrübesi varsa, React Native ile yetenek bulmak ve mevcut bilgiyi yeniden kullanmak daha kolaydır. Piksel düzeyinde tutarlı, markaya özel ve animasyon-yoğun bir arayüz hedefliyorsanız Flutter'ın kendi render yaklaşımı avantaj sağlar. Her iki durumda da doğru cevap, teknolojinin modasına değil, ekibin uzmanlığına ve projenin gereksinimine göre çıkar; bu değerlendirmeyi bir ajansla birlikte yapmak, sonradan geri dönülmesi zor bir hatayı en baştan önler.

Teknoloji seçimini kim yapmalı?

Teknoloji kararını, uygulamayı yaptıracak işletme değil, ürünü inşa edecek ekip vermelidir; ama işletmenin bu kararı anlaması ve sorgulaması gerekir. Sağlıklı bir ilişki, ajansın "şu teknolojiyi şu nedenle öneriyoruz" diye gerekçesini açık açık anlattığı, işletmenin de bu gerekçeyi anlayıp onayladığı ilişkidir. "Biz hallederiz, siz karışmayın" tavrı, sonradan sahiplik ve devir sorunlarına yol açar.

Dikkat edilmesi gereken bir kırmızı bayrak, ekibin yalnızca tek bir teknolojiyi bildiği için onu her projeye dayatmasıdır. İyi bir partner, projeye göre değişen bir bakış sunar; kimi işte native'i, kimi işte cross-platform'u, kimi işte önce mobil web'i önerir. Teknoloji seçimi bir sadakat meselesi değil, bir uygunluk meselesidir; ekibinizin bu esnekliği gösterip göstermediği, çalışacağınız tarafın olgunluğunu gösterir.

Mobil uygulama geliştirme süreci: 8 adım

Sağlıklı bir mobil uygulama, birbirini takip eden sekiz adımdan geçer. Bu adımlar rehberin omurgasıdır; her birini atlamak değil, üstünden hızlı geçmek bile ilerde katlanan bir maliyet doğurur. Aşağıda önce tüm süreci sıralı bir liste olarak veriyoruz, ardından her adımı ayrı ayrı açıyoruz.

1. Fikir ve pazar/rakip doğrulama: Problemi, hedef kitleyi ve mevcut çözümleri netleştirin. Yanlış problemi çözen bir uygulama, teknik olarak kusursuz olsa bile başarısız olur.
2. Özellik listesi ve kapsam (MVP): Tüm fikirleri toplayın, sonra acımasızca eleyin. Kapsam şişmesi, bütçe ve süreyi patlatan bir numaralı nedendir.
3. Gereksinim ve teknik analiz: Platform, yaklaşım, backend ve entegrasyonlara karar verin. Bu kararların sonradan değişmesi en pahalı değişikliktir.
4. UI/UX tasarım: Wireframe'den prototipe, oradan tasarım sistemine ilerleyin. Kod yazılmadan önce yapılan düzeltmeler en ucuz düzeltmelerdir.
5. Geliştirme: Ön yüz, backend/API ve veritabanını kurun; sürüm kontrolü ve kod inceleme disiplinini oturtun.
6. Test ve QA: Gerçek cihaz matrisinde, kenar durumlarda ve güvenlik açısından test edin; beta kullanıcılarla deneyin. "Sadece emülatörde çalıştı" bir test değildir.
7. Mağaza yayını: Developer hesabı açın, mağaza kurallarına ve inceleme sürecine hazırlanın, gizlilik/izin beyanlarını ve mağaza tanıtımını (ASO) tamamlayın.
8. Bakım, güncelleme ve iterasyon: Uygulama artık canlı. Analitiği izleyin, hataları giderin, işletim sistemi güncellemelerine uyum sağlayın ve geri bildirimle geliştirin.

Adım 1: Fikir, pazar ve rakip doğrulama

Her şey doğru problemi seçmekle başlar. Bir uygulama fikri, ne kadar heyecan verici olursa olsun, gerçek bir ihtiyaca dayanmıyorsa başarısızlığa mahkûmdur. Bu yüzden ilk adım kod değil, araştırmadır: kimin, hangi durumda, hangi acıyı yaşadığını ve bu acıyı şu an nasıl çözdüğünü anlamak.

Pazar doğrulaması üç sorunun cevabıdır. Birincisi, bu problemi yaşayan yeterince büyük bir kitle var mı? İkincisi, mevcut çözümler (rakip uygulamalar, web siteleri, hatta Excel ya da telefonla arama gibi "çözüm olmayan çözümler") bu ihtiyacı ne kadar iyi karşılıyor? Üçüncüsü, sizin yaklaşımınız gerçekten daha iyi bir cevap mı, yoksa sadece "bir tane daha" mı? Bu sorulara dürüst cevap vermeden yazılan hiçbir kod, kaybedilen parayı geri getirmez.

Rakip analizi, kopyalamak için değil, boşlukları görmek için yapılır. Rakip uygulamaların mağaza yorumlarını okumak, kullanıcıların en çok neye kızdığını ve neyi övdüğünü doğrudan gösterir; bu, en ucuz pazar araştırmasıdır. Hedef kitlenizi net bir profil olarak tanımlayın: yaşı, cihazı, teknik alışkanlığı, uygulamayı hangi bağlamda kullanacağı. Yanlış problemi çözen bir uygulama, teknik olarak kusursuz olsa da başarısız olur; bu adım, o başarısızlığı en baştan önleme fırsatınızdır.

Fikri ölçülebilir hedeflere bağlayın

İyi bir doğrulama, "insanlar bunu sever" gibi belirsiz bir umutla değil, ölçülebilir varsayımlarla çalışır. "Kullanıcılar randevu almak için ayda ortalama üç kez uygulamayı açacak" ya da "ilk üç ayda şu segmentten şu kadar kayıt bekliyoruz" gibi test edilebilir hedefler koyun. Bu hedefler, ileride MVP'nin başarılı olup olmadığını objektif ölçmenizi sağlar.

Bu aşamada bir uzmanla oturup fikri bir iş modeline oturtmak, sonraki tüm adımların yönünü belirler. Alis Dijital olarak projelerin başında yaptığımız ücretsiz analiz, tam da bu doğrulamayı yapılandırmak içindir; fikri teknik ve ticari gerçeklikle buluşturur, çözülmeye değer olup olmadığını birlikte netleştiririz.

Doğrulama araçları: koda geçmeden test edin

Fikri kod yazmadan test etmenin ucuz yolları vardır ve bunları kullanmamak büyük bir israftır. Basit bir açılış sayfası (landing page) kurup gerçek ilgiyi ölçmek, potansiyel kullanıcılarla birebir görüşmeler yapmak, küçük bir anket ya da tıklanabilir bir prototip paylaşmak; bunların hepsi, aylar sürecek bir geliştirmeden önce fikri sınamanın yollarıdır. Amaç, "insanlar sever mi" tahminini "insanlar gerçekten ilgileniyor mu" kanıtına çevirmektir.

Bu araçların ortak mantığı, en pahalı doğrulamayı (kod) en sona bırakmaktır. Bir açılış sayfasına gelen ziyaretçilerin kaçının "bana haber ver" dediği, bir prototipte kullanıcıların nerede takıldığı ya da görüşmelerde hangi cümlenin tekrar ettiği; bunların hepsi, henüz geri dönülmez bir yatırım yapmadan öğrendiğiniz derslerdir. İyi bir doğrulama fazı, çoğu zaman ilk fikri olduğu gibi değil, keskinleştirilmiş ve düzeltilmiş haliyle geliştirmeye taşır.

Adım 2: Özellik listesi ve kapsam (MVP)

Fikir doğrulandıktan sonra sıra, "bu uygulama tam olarak ne yapacak" sorusuna gelir. Bu aşamada doğal bir refleks, aklınıza gelen her özelliği listeye eklemektir. Oysa bir uygulamayı çökerten en yaygın neden eksik özellik değil, fazla özelliktir. Kapsam şişmesi, bütçe ve süreyi patlatan bir numaralı nedendir.

Doğru yaklaşım, tüm özellikleri toplayıp üç kutuya ayırmaktır: "olmazsa olmaz", "olsa iyi olur" ve "sonra bakarız". Uygulamanın çekirdek değerini oluşturan, onsuz ürünün anlamsız kaldığı özellikler ilk kutuya girer; ilk sürümde yalnızca bu kutuyu geliştirirsiniz. Diğer iki kutu, ürün gerçek kullanıcılarla test edildikten sonra, verilere dayanarak sıraya alınır.

Bu disiplin, projeyi hem daha ucuz hem daha başarılı yapar. Az sayıda özelliği iyi yapmak, çok sayıda özelliği vasat yapmaktan her zaman daha değerlidir. Kapsamı yazılı bir belge haline getirmek de kritik: "ne yapacağız" kadar "ne yapmayacağız" da net yazılmalı ki, geliştirme sırasında sürekli genişleyen bir hedefle uğraşmayasınız.

Kapsam şişmesinin en sinsi biçimi, geliştirme sırasında masumca eklenen "küçük" isteklerdir. "Bir de şuraya bir buton koyalım", "bir de şu ekranı ekleyelim" gibi tek tek zararsız görünen talepler, toplandığında takvimi ve bütçeyi sessizce ikiye katlar. Bu yüzden her yeni istek, "bu MVP'nin çekirdek değerine hizmet ediyor mu, yoksa sonraki sürüme mi" sorusundan geçmelidir. Kapsam değişiklikleri yasak değildir; ama bilinçli, kayıt altında ve etkisi hesaplanarak yapılmalıdır.

MVP nedir ve nasıl çıkarılır?

MVP (Minimum Viable Product / Minimum Uygulanabilir Ürün), uygulamanın çekirdek değerini kanıtlayan en küçük sürümüdür. Tipik olarak üç-beş temel özellikten oluşur; amacı "eksik bir ürün çıkarmak" değil, "odaklı bir ürünle erken geri bildirim almak ve riski düşürmektir". MVP eksik değildir; gereksiz olan her şeyden arındırılmış, odaklı bir üründür.

"Her şeyi ilk sürümde çıkaralım" tuzağı, çoğu projeyi daha yayınlanmadan tüketir. Aylarca süren, hiç kullanıcı görmemiş, devasa bir ilk sürüm; hem çok pahalıdır hem de yanlış varsayımlar üzerine kurulma riski taşır. MVP mantığı bunun tam tersidir: önce çekirdeği yayınla, gerçek kullanıcıdan öğren, sonra öğrendiğinle büyüt.

1. Çekirdek değeri tek cümlede yazın: "Bu uygulama, kullanıcının [şunu] yapmasını sağlar." Bu cümleye hizmet etmeyen her özellik adaydır, çekirdek değildir.
2. Özellikleri üç kutuya ayırın: olmazsa olmaz, olsa iyi, sonra. Yalnızca ilk kutuyu MVP'ye alın.
3. İlk kutuyu 3-5 özelliğe indirin: Daha fazlası varsa, hangisinin gerçekten çekirdek olduğunu tekrar sorgulayın.
4. Yayınlayın ve ölçün: Gerçek kullanım verisiyle hangi varsayımın doğru, hangisinin yanlış olduğunu görün.
5. İterasyonla büyütün: Verinin işaret ettiği özellikleri sıradaki sürümlere ekleyin; "olsa iyi" kutusu artık tahmine değil kanıta dayanır.

Süre beklentisi de MVP mantığına göre değişir ve oynaktır: basit bir MVP tipik olarak birkaç ay (yaklaşık 1-3 ay) sürerken, daha karmaşık bir ürün 12-20 haftayı ya da daha fazlasını bulabilir; yayından sonra da genellikle en az birkaç aylık bir iterasyon dönemi planlanır. Bu rakamlar projeye göre büyük ölçüde değişir; net bir takvim için kapsamın çıkarılması şarttır.

Adım 3: Gereksinim analizi, platform ve teknik mimari

MVP kapsamı belli olduğunda, "bunu teknik olarak nasıl kuracağız" sorusuna geçilir. Bu adım, sonradan değişmesi en pahalı olan kararların verildiği yerdir; bu yüzden aceleye getirilmemesi gerekir. Platform seçimi, yaklaşım (native/cross-platform), backend mimarisi ve entegrasyonlar bu aşamada netleşir.

Platform sorusu, "iOS mu, Android mi, ikisi de mi" sorusudur. Hedef kitlenizin ağırlıklı olarak hangi cihazı kullandığı, bütçeniz ve zaman çizelgeniz bu kararı belirler. Cross-platform bir yaklaşım seçtiyseniz zaten iki platforma birden çıkarsınız; native'de ise hangi platformla başlayacağınız stratejik bir tercihtir. Yanlış platform önceliği, hedef kitlenizin bir bölümünü baştan dışarıda bırakabilir.

Backend, uygulamanın görünmeyen ama en kritik yarısıdır. Kullanıcı verileri, kimlik doğrulama, iş mantığı ve entegrasyonların çoğu sunucu tarafında yaşar. Ödeme altyapısı, harita, bildirim servisi, üçüncü parti API'ler, ERP ya da kargo entegrasyonları gibi bağlantılar bu aşamada planlanır; çünkü her entegrasyon hem maliyeti hem de karmaşıklığı artırır. İçerik yönetiminin nasıl kurgulanacağı da burada belirlenir; bir içerik yönetim katmanına ihtiyaç varsa, doğru seçimi hangi CMS seçilmeli yazımızdaki mantıkla değerlendirebilirsiniz.

Teknik borç ve ölçeklenebilirlik

Bu adımda verilen kararlar, uygulamanın gelecekteki büyüme tavanını belirler. Bugün 100 kullanıcı için doğru olan bir mimari, 100 bin kullanıcıda çökebilir. İyi bir teknik analiz, sadece MVP'yi değil, olası büyümeyi de hesaba katar; ama aynı zamanda "henüz ihtiyaç olmayan ölçek için erken yatırım yapma" tuzağına da düşmez. Denge, tecrübeli bir ekiple kurulur.

Özel yazılım tarafında bu kararların maliyete etkisi doğrudandır; hangi faktörlerin bütçeyi nasıl şekillendirdiğini özel yazılım maliyeti neye göre belirlenir yazımızda ayrıntılandırdık. Mobil projelerde de aynı mantık geçerli: karmaşıklık, entegrasyon sayısı ve özgünlük arttıkça maliyet ve süre artar.

Bu aşamada üretilen en değerli çıktı, yazılı bir teknik gereksinim belgesidir. Hangi ekranların olacağı, her ekranın ne yaptığı, verinin nasıl aktığı, hangi sistemlerle entegre olunacağı ve teknik kısıtların neler olduğu; bunların hepsi kayıt altına alınır. Bu belge, hem geliştirme sırasında ortak bir referans hem de tarafların "neyi anladık" konusunda hizalandığı bir sözleşme işlevi görür. Belgesiz başlayan projeler, ilerleyen aşamada "ben bunu böyle anlamamıştım" tartışmalarında boğulur.

Adım 4: UI/UX tasarım

Kullanıcı, uygulamanızın kodunu değil, arayüzünü görür. Bu yüzden UI (arayüz) ve UX (kullanıcı deneyimi) tasarımı, projenin başarısını doğrudan belirleyen bir adımdır. En güçlü backend bile, kullanıcının kaybolduğu, yavaş ve sezgisiz bir arayüzün ardında değersizleşir.

Tasarım süreci genellikle üç katmanda ilerler. Önce düşük detaylı taslaklar (wireframe) çizilir; bunlar ekranların iskeletini ve akışını gösterir. Sonra tıklanabilir prototipler hazırlanır; kullanıcı, henüz tek satır kod yazılmadan uygulamanın nasıl "hissettireceğini" deneyimler. En sonunda görsel tasarım ve bir tasarım sistemi (renk, tipografi, bileşenler) kurulur. Bu sırayı takip etmenin en büyük faydası şudur: bir sorunu prototip aşamasında düzeltmek, kod yazıldıktan sonra düzeltmekten kat kat ucuzdur.

İyi mobil UX'in kuralları evrenseldir: az sayıda net eylem, parmakla kolay erişilebilen dokunma alanları, hızlı yüklenen ekranlar ve kullanıcıyı asla "şimdi ne yapacağım" diye düşündürmeyen bir akış. UI/UX'in ne olduğunu ve nasıl kurgulandığını UI/UX tasarım nedir, nasıl yapılır yazımızda temelden ele aldık; iyi tasarımın ilkelerini ise iyi web tasarımı nasıl olmalı yazısında bulabilirsiniz.

Erişilebilirliği baştan tasarlayın

Erişilebilirlik, sonradan eklenen bir özellik değil, baştan kurulan bir yaklaşımdır. Yeterli kontrast, ölçeklenebilir yazı tipi, ekran okuyucu uyumu ve dokunma hedeflerinin uygun boyutu, hem engelli kullanıcılar için şart hem de herkes için daha iyi bir deneyim üretir. Bu ilkeleri en baştan gözetmek, sonradan kapsamlı bir yeniden tasarımdan çok daha ucuzdur.

Erişilebilirliğin ne anlama geldiğini ve nasıl sağlandığını web erişilebilirliği nedir, nasıl sağlanır yazımızda ele aldık; oradaki ilkelerin çoğu mobil uygulamalar için de geçerlidir. Tasarım ve geliştirmeyi tek çatı altında yürütmek isteyen işletmeler için web ve mobil UI/UX tasarım hizmetimiz tam da bu süreci uçtan uca kurgular.

Platform tutarlılığı da mobil tasarımın sık atlanan bir boyutudur. iOS ve Android'in kendi tasarım gelenekleri, alışılmış hareketleri ve bileşen davranışları vardır; kullanıcı, kullandığı platformda "evinde" hissetmek ister. Bir platformun kalıbını diğerine zorla taşımak, teknik olarak çalışsa bile kullanıcıya yabancı ve hantal gelir. İyi bir cross-platform tasarım, tek bir marka kimliğini korurken her platformun beklentisine saygı gösterir.

Son olarak, tasarımı gerçek içerikle test etmek kritik. Boş bir şablonda kusursuz görünen bir ekran, uzun ürün adları, eksik görseller ya da beklenmedik uzunluktaki metinlerle dolduğunda bozulabilir. Tasarımı "en iyi senaryoda" değil, "gerçek ve dağınık veriyle" denemek; yayından sonra ortaya çıkacak birçok görsel sorunu önceden yakalar. İyi tasarım, ideal durumu değil, gerçek durumu güzel gösterendir.

Adım 5: Geliştirme

Geliştirme, tasarımın çalışan bir ürüne dönüştüğü adımdır. Burada üç ana katman aynı anda örülür: kullanıcının gördüğü ön yüz (frontend), iş mantığını ve veriyi taşıyan arka yüz (backend/API) ve verinin saklandığı veritabanı. İyi bir geliştirme, bu üç katmanı birbirine sağlam ve güvenli biçimde bağlar.

Profesyonel bir geliştirme sürecini amatör bir denemeden ayıran şey, disiplindir. Sürüm kontrolü (versiyon yönetimi) her değişikliği izlenebilir kılar; kod inceleme (code review) her satırın en az iki göz tarafından kontrol edilmesini sağlar; otomatik testler, bir yerdeki değişikliğin başka bir yeri bozmadığını doğrular. Bu pratikler yavaşlatan bürokrasi değil, ilerde saatlerce hata ayıklamaktan kurtaran yatırımlardır.

Geliştirme genellikle küçük parçalara bölünerek, iki-üç haftalık döngüler halinde ilerler. Her döngü sonunda çalışan bir parça ortaya çıkar; bu, hem ilerlemeyi görünür kılar hem de yön değiştirmeyi ucuzlatır. "Aylarca hiçbir şey görmeden bekleyip sonunda dev bir teslimat almak" yerine, adım adım büyüyen ve sık gösterilen bir ürünle çalışmak, hem şeffaflık hem de risk yönetimi açısından çok daha sağlıklıdır.

Bu döngüsel yaklaşımın işletme için en büyük faydası, kontrolün sizde kalmasıdır. Her döngüde çalışan bir parça gördüğünüz için, projenin doğru yönde ilerleyip ilerlemediğini erkenden anlarsınız; bir şey yanlış gidiyorsa, aylar değil günler kaybedersiniz. Bu şeffaflık, ajans ile işletme arasındaki güveni de besler; sürprizlerin değil, sürekli ve görünür ilerlemenin olduğu bir çalışma ilişkisi kurar.

Kodun görünmeyen yarısı: dokümantasyon ve devir

İyi geliştirme, sadece çalışan kod değil, devredilebilir kod üretir. Kodun nasıl kurulduğu, hangi kararların neden verildiği ve sistemin nasıl çalıştığı belgelenmelidir. Aksi halde uygulamanın bakımı, onu yazan tek bir kişiye bağımlı hale gelir; o kişi ayrıldığında ürün "yetim" kalır. Bu, özellikle freelance modelinde sık yaşanan bir risktir.

Alis Dijital olarak özel yazılım ve mobil geliştirme projelerinde, kodun ve sistemin sizin varlığınız olduğu ilkesiyle çalışırız; belgelenmiş, devredilebilir ve büyümeye açık bir ürün teslim etmek, "çalışan bir demo" teslim etmekten çok daha değerlidir. Geliştirme sürecimizin kapsamını özel yazılım ve web geliştirme hizmetimiz sayfasında bulabilirsiniz.

Mobil uygulama için backend nasıl kurulur?

Kullanıcının gördüğü ekranlar buzdağının görünen kısmıdır; suyun altındaki backend, uygulamanın gerçek işini yapar. Kullanıcı hesapları, oturum yönetimi, verilerin saklanması, iş kurallarının işletilmesi, bildirim gönderimi ve diğer sistemlerle konuşma; bunların hepsi sunucu tarafında yaşar. Bir uygulamanın performansı, güvenliği ve ölçeklenebilirliği çoğu zaman backend kararlarında belirlenir.

Backend kurmanın üç ana yolu vardır. Birincisi tamamen özel bir sunucu altyapısı kurmaktır; en fazla kontrolü verir ama en fazla emek ve uzmanlık ister. İkincisi bulut sağlayıcılarının yönetilen servislerini kullanmaktır; sunucu bakımının bir kısmını sağlayıcıya devredersiniz. Üçüncüsü ise BaaS (Backend-as-a-Service) çözümleridir; kimlik doğrulama, veritabanı ve bildirim gibi hazır yapı taşlarını kullanarak backend geliştirmeyi hızlandırırsınız. Doğru seçim, projenin karmaşıklığına, özel ihtiyaçlarına ve büyüme beklentisine bağlıdır.

KOBİ ölçeğindeki çoğu uygulama için, hazır yapı taşlarını kullanan yönetilen bir yaklaşım hem hızlı hem ekonomiktir; her şeyi sıfırdan kurmak yerine, kanıtlanmış bileşenlerin üstüne kendi iş mantığınızı inşa edersiniz. Çok özel bir iş akışı, yüksek gizlilik gereksinimi ya da olağandışı bir ölçek söz konusuysa özel bir backend gerekebilir. Bu kararı erken vermek önemlidir; çünkü backend mimarisini sonradan değiştirmek, uygulamanın en pahalı yeniden yazımlarından biridir.

API tasarımı ve entegrasyonlar

Uygulamanın ön yüzü ile backend'i, API adı verilen bir arayüz üzerinden konuşur. İyi tasarlanmış bir API tutarlı, güvenli ve versiyonlanabilir olmalıdır; çünkü uygulamanız güncellenirken eski sürümler bir süre daha çalışmaya devam eder. Kötü tasarlanmış bir API, her yeni özellikte kırılan ve sürekli yamayla ayakta tutulan bir sisteme dönüşür.

Entegrasyonlar, backend'in dış dünyayla köprüsüdür. Ödeme altyapısı, harita ve konum servisleri, SMS/e-posta gönderimi, kargo firmaları, muhasebe/ERP sistemleri ve üçüncü parti API'ler bu köprülerle bağlanır. Her entegrasyon bir değer katar ama aynı zamanda bir bağımlılık ve bakım yükü ekler; bu yüzden "gerçekten gerekli mi" sorusunu her entegrasyon için sormak, sistemi sade ve sağlam tutar.

Adım 6: Test ve kalite güvence (QA)

Test, "çalışıyor mu" sorusunu değil, "hangi durumlarda çalışmıyor" sorusunu sorar. Bir uygulamanın ilk izlenimi, çoğu zaman geri dönülemezdir; çöken ya da hatalı bir uygulamayı silen kullanıcı, kolay kolay geri gelmez. Bu yüzden QA, yayından önceki son savunma hattıdır ve asla kısılmaması gereken bir adımdır.

En yaygın hata, uygulamayı yalnızca emülatörde (bilgisayardaki sanal cihazda) test etmektir. Oysa gerçek dünya çok daha çeşitlidir: farklı ekran boyutları, farklı işletim sistemi sürümleri, düşük bellek, zayıf internet, izin reddedilen senaryolar. Bu yüzden gerçek bir cihaz matrisinde, yani farklı marka ve sürümdeki gerçek telefonlarda test etmek şarttır. "Sadece emülatörde çalıştı" bir kalite güvencesi değildir.

İyi bir test planı birkaç katmanı kapsar: işlevsel testler (özellikler doğru çalışıyor mu), kenar durumları (beklenmedik girdilerde ne oluyor), performans (yavaş ağda, düşük bellekte), güvenlik (veriler korunuyor mu) ve gerçek kullanıcı testi (beta grubu). Beta test, özellikle değerlidir; küçük ve gerçek bir kullanıcı grubunun uygulamayı denemesi, laboratuvarda görülemeyen sorunları ortaya çıkarır ve yayından önce düzeltme fırsatı verir.

Otomatik test mi, manuel test mi?

İki test türü birbirinin rakibi değil, tamamlayıcısıdır. Otomatik testler, aynı senaryoyu her değişiklikte yorulmadan tekrar çalıştırır; bir yerde yaptığınız düzeltmenin başka bir yeri bozmadığını hızla doğrular. Bu, özellikle uygulama büyüdükçe paha biçilmez hale gelir; elle her seferinde her şeyi kontrol etmek pratikte imkânsızdır. Manuel test ise otomatiğin yakalayamadığını yakalar: "bu ekran gerçekten kullanışlı hissettiriyor mu", "akış sezgisel mi" gibi insan yargısı gerektiren sorular.

Doğru denge, tekrarlayan ve kritik kontrolleri otomatikleştirmek, deneyim ve his gerektiren kısımları ise gerçek insanlarla test etmektir. Küçük projelerde ağırlık manuel tarafta olabilir; ama uygulama büyüdükçe otomatik test kapsamını genişletmek, hem kaliteyi korur hem de her yeni sürümün maliyetini düşürür. Test disiplinini "sonra ekleriz" diye ertelemek, en sık ödenen gizli maliyetlerden biridir.

Adım 7: App Store ve Google Play'de yayınlama

Uygulama hazır olduğunda, kullanıcıya ulaşmanın kapısı mağazalardır. Yayın süreci teknik bir yükleme işleminden ibaret değildir; her iki mağazanın da kendi kuralları, inceleme süreçleri ve beyanları vardır. Bu kurallara hazırlıksız yakalanmak, yayını haftalarca geciktirebilir.

Önce bir geliştirici (developer) hesabı gerekir. Apple tarafında bu genellikle yıllık bir üyelik, Google Play tarafında ise tek seferlik bir kayıt ücreti şeklindedir; güncel tutarlar zaman içinde değişebildiği için kesin rakamı developer.apple.com ve Google Play Console'un resmi sayfalarından teyit etmek gerekir. Bu hesaplar, uygulamanızı yönetmek, sürüm göndermek ve mağaza analitiğini görmek için gerekli olan kontrol panelleridir.

İki mağazanın kültürü farklıdır. Apple'ın inceleme süreci insan-incelemeli ve görece katıdır; gizlilik, ödeme akışları ve izin kullanımı konusunda titizdir. Google Play daha otomatik bir süreç yürütür, ama politika ihlalleri sonradan da tespit edilip uygulamanın kaldırılmasına yol açabilir. En sık ret nedenleri bellidir: eksik ya da tutarsız gizlilik beyanı, gerekçesiz istenen izinler, çökmeler ve mağaza tanıtımının uygulamanın gerçek işleviyle uyuşmaması.

Ret, sürecin doğal bir parçası olabilir ve panik gerektirmez; önemli olan, retten sonra ne yapıldığıdır. İnceleme ekibi genellikle hangi kuralın ihlal edildiğini belirtir; bu geri bildirimi ciddiye alıp düzeltmek ve tekrar göndermek çoğu durumda yeterlidir. Yayın takvimini planlarken, en az bir-iki inceleme turu ve olası düzeltmeler için tampon süre bırakmak akıllıcadır. "Yarın yayına alırız" varsayımıyla verilen sözler, mağaza sürecinin gerçekliğiyle sık sık çelişir.

Gizlilik, izinler ve KVKK uyumu

Her iki mağaza da artık veri toplama konusunda şeffaflık ister. Apple tarafında Gizlilik Etiketleri (Privacy Labels) ve uygulamalar arası takip için izin isteyen App Tracking Transparency; Google tarafında ise Play Console'un Data Safety bölümü, hangi veriyi neden topladığınızı beyan etmenizi zorunlu kılar. Bu beyanlar, uygulamanın gerçek davranışıyla birebir tutarlı olmalıdır; tutarsızlık hem ret hem de sonradan kaldırma riski doğurur.

Türkiye'de bu tabloya KVKK eklenir. Kişisel veri işleyen bir uygulama, açık ve anlaşılır bir aydınlatma metni sunmalı, gereken yerlerde açık rıza almalı ve topladığı veriyi bir envanterle takip etmelidir. İzin ilkesi minimumdur: yalnızca gerçekten gereken izinleri, gerekçesiyle birlikte isteyin. Bu genel bir bilgidir, hukuki tavsiye değildir; kendi durumunuz için bir danışmandan destek almanız gerekir.

ASO: uygulamanın arama motoru optimizasyonu

Bir uygulamayı yayınlamak, onun bulunacağı anlamına gelmez. App Store Optimization (ASO), uygulamanızın mağaza içi aramada üst sıralarda çıkması için başlık, alt başlık, anahtar kelimeler, ikon, ekran görüntüleri, tanıtım videosu ve yorumların optimize edilmesidir. ASO, uygulamanın SEO'sudur; iyi yapılırsa, reklam harcamadan organik indirme getirir.

Mağaza tanıtımının (store listing) kalitesi, indirme oranını doğrudan etkiler. İlk ekran görüntüsü ve kısa açıklama, çoğu kullanıcının indirme kararını verdiği yerdir; bu yüzden uygulamanın çekirdek değerini ilk saniyede anlatmalıdır. Web tarafında SEO ne kadar önemliyse, mobilde ASO da o kadar önemlidir; ikisi birlikte, bulunabilir bir dijital varlık kurar.

ASO'nun sık atlanan bir boyutu da yorumlar ve puanlardır. Yüksek bir ortalama puan ve güncel, olumlu yorumlar; hem mağaza sıralamasını hem de indirme kararını doğrudan etkiler. Bu yüzden uygulamanın içine, doğru anda ve zorlamadan yorum isteyen bir akış kurmak; olumsuz geri bildirimi ise mağazaya taşınmadan önce içeride yakalayıp çözmek değerlidir. Yorum yönetimi, teknik değil ama ticari olarak yayının en önemli parçalarından biridir.

Mağaza komisyonu: net gelirinizi etkileyen ayrım

Mağaza komisyonu, çok yanlış anlaşılan bir konudur. Apple ve Google, uygulama içinden satılan dijital ürünler ve aboneliklerden bir komisyon alır; oranlar bölgeye, programa ve dönemsel düzenlemelere göre değişir (küçük işletme programları düşük oran sunabilir; bazı bölgelerde oranlar güncellenmektedir). Kesin bir yüzde vermek yerine, güncel durumu her iki mağazanın resmi geliştirici sayfalarından teyit etmenizi öneririz.

Kritik ayrım şudur: bu komisyon çoğunlukla dijital mal ve aboneliklere uygulanır. Fiziksel bir ürün ya da uygulama dışında verilen bir hizmet satan uygulamalar (örneğin bir e-ticaret ya da rezervasyon uygulaması), kendi ödeme akışını kullandığında çoğu durumda bu mağaza komisyonuna tabi olmaz. Bu ayrımı en baştan doğru anlamak, gelir modelinizi ve fiyatlandırmanızı sağlıklı kurmanız için şarttır.

Adım 8: Bakım, güncelleme, analitik ve iterasyon

Yayın, bir bitiş çizgisi değil, yeni bir başlangıçtır. Uygulama artık canlı ve bakımsız bırakıldığı anda çürümeye başlar. İşletim sistemleri güncellenir, cihazlar değişir, kütüphaneler eskir, güvenlik açıkları keşfedilir; düzenli bakım almayan bir uygulama birkaç yıl içinde çöker ve nihayetinde mağazadan düşer.

Bakımın ilk katmanı teknik süreklilikdir: işletim sistemi güncellemelerine uyum, hata düzeltmeleri, güvenlik yamaları ve performans iyileştirmeleri. İkinci katman ürünsel gelişimdir: analitik verilerini izleyip kullanıcıların nerede takıldığını, hangi özelliği kullanmadığını, nerede uygulamayı terk ettiğini görmek ve buna göre iyileştirmek. Bu iki katman birlikte, uygulamayı zamanla daha iyi ve daha değerli hale getirir.

Bakımın çoğu zaman görmezden gelinen bir yükü, işletim sistemi takvimleridir. Apple ve Google her yıl yeni sürümler çıkarır; bazen bir güncelleme, daha önce sorunsuz çalışan bir özelliği bozabilir ya da yeni bir kural getirir. Bu takvimleri takip etmeyen bir uygulama, kullanıcı hiçbir şey yapmadan bir sabah çalışmayı bırakabilir. Düzenli bakım, işte tam da bu tür sessiz kırılmaları önceden yakalayıp önlemek içindir.

İterasyon, MVP mantığının doğal devamıdır. İlk sürümü yayınladınız, veriyi topladınız; şimdi "olsa iyi" kutusundaki özellikleri tahminle değil, kanıtla sıraya alıyorsunuz. Bu döngü hiç bitmez: yayınla, ölç, öğren, geliştir. Başarılı uygulamaları başarısızlardan ayıran en büyük fark, çoğu zaman ilk sürümün mükemmelliği değil, bu iterasyon döngüsünün disiplinli işletilmesidir.

Hangi metrikleri izlemeli?

Analitik, "kaç indirme aldık" gibi gösterişli ama yüzeysel sayıların ötesine geçmelidir. Asıl değerli metrikler davranışsaldır: kullanıcılar ilk açılışta uygulamayı gerçekten kuruyor mu (aktivasyon), belirli bir süre sonra geri dönüyor mu (elde tutma), hangi ekranda takılıp çıkıyor, çekirdek eylemi kaç kez gerçekleştiriyor. Bu sorular, uygulamanın sağlığını indirme sayısından çok daha dürüst anlatır.

Metrik seçerken tuzak, ölçebildiğiniz her şeyi ölçüp veride boğulmaktır. Birkaç kritik metriğe odaklanmak; örneğin aktivasyon oranı, 7 ve 30 günlük elde tutma, çekirdek eylemin sıklığı ve çökme oranı; çoğu KOBİ uygulaması için karar vermeye yeter. Önemli olan sayıyı toplamak değil, o sayıya bakıp bir sonraki sürümde ne yapacağınıza karar vermektir. Ölçülmeyen bir uygulama, körlemesine yürütülen bir üründür.

Mobil uygulama maliyeti neye göre değişir?

En sık sorulan soru budur ve en dürüst cevap şudur: net bir rakam, ancak kapsam çıkarıldıktan sonra verilebilir. Aynı "uygulama" kelimesi, birkaç ekranlık basit bir katalogdan, onlarca entegrasyonu olan karmaşık bir platforma kadar çok geniş bir aralığı kapsar. Bu yüzden internetteki "uygulama şu kadara yapılır" ifadeleri neredeyse her zaman yanıltıcıdır.

Maliyeti belirleyen faktörler bellidir. En büyük belirleyici, özellik sayısı ve karmaşıklıktır; her yeni özellik hem geliştirme hem test yükü ekler. Ardından platform sayısı (yalnız iOS mu, yoksa iOS ve Android mi), native mi cross-platform mı olduğu, arayüzün ne kadar özgün ve özel tasarlandığı, backend ve entegrasyonların derinliği (ödeme, harita, bildirim, üçüncü parti API, ERP, kargo) ve son olarak ekip modeli (yurt içi/dışı, freelance/ajans/kurum içi) gelir.

Toplam sahip olma maliyeti (TCO) düşünün

En sık yapılan bütçe hatası, yalnızca ilk geliştirme bedeline bakmaktır. Oysa bir uygulamanın gerçek maliyeti, toplam sahip olma maliyetidir (TCO): ilk geliştirme + mağaza ücretleri + sunucu/backend giderleri + bakım ve güncelleme + pazarlama. Bu kalemlerden herhangi birini planlamamak, projenin ilerleyen aylarında beklenmedik bir yükle karşılaşmanıza yol açar.

Bakım kalemi özellikle küçümsenir. Yıllık bakım maliyeti projeye göre büyük ölçüde değişir; genel kural, ilk geliştirmenin belirli bir oranı kadar sürekli bir gider planlamaktır, ama kesin bir yüzde vermek yanıltıcı olur. Sunucu maliyetleri kullanıcı sayısıyla ölçeklenir; pazarlama ise "uygulama yaptırınca kullanıcı gelmez" gerçeği gereği, çoğu zaman geliştirme kadar önemli bir bütçe kalemidir.

Doğru maliyet planlaması, tahminle değil, kapsamla başlar. Alis Dijital olarak projelere şeffaf bir analizle başlar, TCO'nun tüm kalemlerini baştan konuşuruz; sürpriz maliyet değil, öngörülebilir bir bütçe hedefleriz. Kendi projenizin kapsamını ve yaklaşık maliyet aralığını netleştirmek için analiz sayfamızdan bir görüşme başlatabilirsiniz.

Ucuz teklif neden pahalıya patlar?

Teklifleri yan yana koyduğunuzda en düşük rakam çekici görünür; ama yazılımda en ucuz teklif çoğu zaman en pahalı seçimdir. Düşük fiyat genellikle kısılan bir yerden gelir: atlanan tasarım, yetersiz test, belgelenmemiş kod ya da bakım sözünün olmaması. Bu kısıntılar ilk anda görünmez; birkaç ay sonra çöken uygulama, devredilemeyen kod ve baştan yazma gereği olarak faturayı katlanmış şekilde geri getirir.

Doğru karşılaştırma, sadece rakama değil, o rakamın neyi kapsadığına bakar. Tasarım dahil mi, test dahil mi, kaynak kodu size mi ait, yayın sonrası bakım nasıl, kim hangi sorumluluğu üstleniyor? Bu soruların cevabı netleşmeden verilen bir "evet, ucuza yaparım" sözü, çoğu zaman yarım kalan bir projeye giden en hızlı yoldur. Sağlıklı bir teklif, kapsamı, sorumlulukları ve sahipliği açıkça yazar.

Mobil uygulama ne kadar sürede yapılır?

Süre de maliyet gibi kapsama bağlıdır ve tek bir rakamla ifade edilemez. Yine de kaba bir çerçeve vermek mümkün: basit bir MVP genellikle birkaç ay (yaklaşık 1-3 ay ya da 6-12 hafta), orta karmaşıklıkta bir uygulama yaklaşık 8-12 hafta, karmaşık bir ürün ise 12-20 hafta veya daha fazlasını alır. Bu aralıklar oynaktır; entegrasyon sayısı, tasarım özgünlüğü ve ekip büyüklüğü süreyi ciddi biçimde değiştirir.

Süreyi belirleyen görünmez faktör, karar hızıdır. Geliştirme takvimini en çok uzatan şey teknik zorluk değil, çoğu zaman geç verilen ya da sürekli değişen kararlardır. Kapsamı net tanımlanmış, karar mekanizması hızlı işleyen bir proje; aynı teknik zorluğa sahip ama sürekli yön değiştiren bir projeden çok daha çabuk biter.

2026'da AI-destekli geliştirme araçları, kodlama fazını belirgin biçimde hızlandırdı; tekrarlı kod yazımı, test üretimi ve hata ayıklama daha çabuk yapılabiliyor. Ancak bu, "AI ile bir haftada uygulama" gibi pazarlama abartılarını gerçek kılmaz. AI kodlamayı hızlandırır ama doğrulama, tasarım, test, mağaza yayını ve iterasyon gibi adımları ortadan kaldırmaz; sürecin tamamı hâlâ disiplin ve zaman ister.

AI destekli mobil geliştirme (2026): ne değişti, ne değişmedi?

Yapay zekâ, yazılım geliştirmenin gündelik pratiğini gerçekten değiştirdi; ama neyi değiştirdiğini ve neyi değiştirmediğini ayırmak, doğru beklenti kurmanın anahtarı. AI'yı "uygulamayı benim yerime yapan sihir" olarak görmek, hem para hem zaman kaybettiren bir yanılgıdır. Doğru okuma, AI'yı iyi bir ekibi daha hızlı ve daha az hatayla çalıştıran bir güç çarpanı olarak görmektir.

Değişen taraf net: tekrarlı ve öngörülebilir işler hızlandı. Standart ekran iskeletleri, veri modelleri, test senaryoları, dokümantasyon taslakları ve rutin hata ayıklama, AI destekli araçlarla çok daha çabuk üretilebiliyor. Bu, geliştiricinin zamanını daha değerli işlere ayırmasını sağlar; kod yazmaktan çok, doğru şeyi kurgulamaya odaklanır. Kodlama fazının bu hızlanması, iyi yönetildiğinde toplam süreyi ve maliyeti bir miktar aşağı çeker.

Değişmeyen taraf ise sürecin kalbi. Doğru problemi seçmek, kapsamı doğru çıkarmak, kullanıcıyı anlamak, mimariyi doğru kurmak, gerçek cihazlarda test etmek, mağaza kurallarına uymak ve yayından sonra veriyle iyileştirmek; bunların hiçbiri AI ile "atlanabilir" adımlar değildir. AI'nın ürettiği kodun bile mutlaka bir uzman tarafından gözden geçirilmesi gerekir; çünkü hızlı üretilen hatalı kod, hızlı üretilen bir teknik borçtur.

Pratik sonuç şudur: AI, iyi bir ekibi daha verimli yapar ama kötü bir süreci düzeltmez. "AI kullanıyoruz, o yüzden ucuza ve bir haftada yaparız" söylemine temkinli yaklaşın; ciddi bir uygulama, AI ile bile doğrulama, tasarım, test ve iterasyon disiplinini gerektirir. Alis Dijital olarak bu araçları süreci hızlandırmak için kullanırız, ama kalite ve sahiplik ilkelerinden ödün vermeden.

Kimlerle çalışmalı? Ekip rolleri ve çalışma modeli

Bir mobil uygulama, tek bir "programcının" işi değildir; farklı uzmanlıkların bir araya geldiği bir ekip işidir. Küçük projelerde bir kişi birden fazla rolü üstlenebilir, ama rollerin kendisi her projede vardır. Bu rolleri tanımak, kiminle çalışacağınıza doğru karar vermenizi sağlar.

Freelance, ajans veya kurum içi?

Bu ekibi kurmanın üç yolu vardır ve her birinin dengesi farklıdır. Freelance model ucuz ve esnektir; ama birden fazla freelancer'ı koordine etmek, süreklilik sağlamak ve devir riskini yönetmek işletmenin sırtına biner. Bir freelancer ayrıldığında ürün ortada kalabilir; bu, bakım aşamasında en sık yaşanan sıkıntılardan biridir.

Ajans modeli, uçtan uca hizmet ve tek muhatap sunar. Tasarımdan geliştirmeye, testten yayına ve bakıma kadar tüm süreci tek bir sorumlu taraf yürütür; bu, koordinasyon yükünü ve süreklilik riskini büyük ölçüde ortadan kaldırır. Karşılığında freelance'a göre daha yüksek bir maliyeti vardır, ama operasyonel yük ve risk açısından çoğu KOBİ için en düşük toplam maliyetli seçenek genellikle budur.

Kurum içi (in-house) ekip, tam kontrol ve derin ürün sahipliği sağlar; sürekli gelişen, kalbinde yazılım olan ürünler için idealdir. Ama işe alım, maaş, ekipman ve süreklilik gibi sabit bir yük getirir; tek bir uygulama için bu yükü taşımak çoğu işletme için mantıklı değildir. Alis Dijital olarak ajans modelinde, tek muhatapla fikirden yayına ve bakıma kadar tüm süreci yürütür; işletmenizin operasyonel yükünü minimumda tutarız.

Model seçiminde gözden kaçan bir kriter de süreklilik ve devirdir. Bir uygulama yıllarca yaşayacaksa, onu yapan tarafın da o süre boyunca ulaşılabilir ve sorumlu olması gerekir. Freelance modelde bu süreklilik en kırılgan halindedir; kişi meşgul olduğunda ya da işi bıraktığında ürününüz askıda kalabilir. Ajans modelinde ise sorumluluk bir kişiye değil, bir kuruma aittir; bu, uzun ömürlü ürünler için önemli bir güvencedir.

Uygulama mı, mobil site/PWA mı?

Belki de bu yazının en para tasarrufu sağlayan sorusu budur. Her işletmenin uygulamaya ihtiyacı yoktur; birçok ihtiyaç, mobil uyumlu bir web sitesi ya da bir PWA ile daha ucuz, daha hızlı ve daha geniş erişimle çözülür. Yanlış tarafı seçmek, hem para hem zaman kaybettirir.

Karar, ihtiyacın doğasına bakar. Uygulama, cihazın native özelliklerini (kamera, konum, çevrimdışı çalışma, bildirim) yoğun kullanan, sık tekrar eden ve en yüksek performansı gerektiren senaryolarda üstündür. Mobil site/PWA ise içerik, erişim ve SEO'nun öncelikli olduğu, geniş kitleye hızlı ve sürtünmesiz ulaşmak gereken durumlarda daha akıllıcadır; kullanıcı bir şey indirmeden, doğrudan tarayıcıdan erişir.

Çoğu KOBİ için doğru sıralama nettir: önce mobil uyumlu, hızlı ve iyi tasarlanmış bir web sitesi; talep ve kullanım doğrulandıktan sonra, sadakat ve sık kullanım gerçekten oluştuğunda bir uygulama. Uygulama, mevcut dijital varlığın tamamlayıcısıdır, ikamesi değil. Mobil uyumlu bir web ile başlamak isteyenler için web sitesi nasıl yapılır ve kurumsal bir varlık kuranlar için kurumsal web sitesi nasıl olmalı yazılarımız yol gösterir.

Kayseri ve çevresindeki işletmeler için, önce sağlam bir web varlığı kurup ardından mobil tarafa geçmek çoğu zaman en verimli yoldur; yerel bir başlangıç için Kayseri web tasarım hizmetimiz bu ilk adımı kurgular. Uygulama kararını da bu bütünün içinde, aceleye getirmeden vermek en sağlıklısıdır.

Kaba bir karar kuralı şöyle özetlenebilir: eğer kullanıcı sizinle ayda birkaç kez ya da daha seyrek etkileşiyorsa ve ihtiyacı içerik/bilgi ağırlıklıysa, mobil uyumlu web neredeyse her zaman doğru başlangıçtır. Eğer kullanıcı sizinle haftada birden fazla, tekrar eden bir alışkanlıkla etkileşiyor ve bu etkileşim bildirim, konum ya da çevrimdışı gibi native yeteneklerden gerçekten fayda görüyorsa, uygulama yatırımı anlam kazanır. Bu iki uç arasında kalan durumlarda, PWA çoğu zaman iyi bir orta yoldur.

Bir başka pratik ölçüt sadakattir. Uygulama, henüz sizi tanımayan bir yabancıyı ikna etmek için değil, sizi zaten seven bir müşteriyi elde tutmak için güçlüdür; çünkü bir uygulamayı indirmek, bir web sayfasını açmaktan çok daha büyük bir taahhüttür. Bu yüzden birçok işletme için doğru sıralama, önce web ile kitle kurmak, sonra o kitlenin en sadık kısmına özel bir uygulama sunmaktır. Uygulamayı bir edinim aracı değil, bir elde tutma aracı olarak konumlamak, yatırımın geri dönüşünü belirler.

Mobil uygulamadan nasıl para kazanılır?

Bir uygulamanın gelir modeli, daha tasarım aşamasında düşünülmesi gereken bir karardır; sonradan eklenen bir yama değildir. Farklı monetizasyon yolları, farklı uygulama türlerine ve kitlelere uyar. Yanlış modeli seçmek, iyi bir ürünü bile ticari olarak başarısız kılabilir.

Temel modeller şunlardır: ücretli indirme (Türkiye'de görece zor), uygulama içi satın alma ve abonelik (içerik ve SaaS için güçlü), reklam (yüksek trafikli ücretsiz uygulamalar için), freemium (çoğu tüketici uygulamasının temeli) ve e-ticaret/hizmet aracı modeli. Bu sonuncusu, KOBİ'ler için genellikle en anlamlı olanıdır: uygulama doğrudan bir gelir ürünü değil, satışı, siparişi, sadakati ve elde tutmayı güçlendiren bir operasyon aracıdır.

Önemli bir maliyet notu: dijital mal ve aboneliklerde mağaza komisyonu net geliri etkiler; bu komisyon oranları oynaktır ve resmi kaynaktan teyit edilmelidir. Ancak daha önce belirttiğimiz gibi, fiziksel ürün ya da uygulama dışı hizmet satan uygulamalar kendi ödeme akışını kullandığında çoğu durumda bu komisyona tabi olmaz; e-ticaret odaklı bir uygulama için bu, gelir modelini doğrudan iyileştiren bir ayrımdır.

E-ticaret ya da hizmet satan bir işletmeyseniz, uygulama gelir modelinizi mevcut satış kanallarınızla bütünleşik kurgulamak kritik. Bu bütünü doğru planlamak için e-ticaret danışmanlığı hizmetimiz, uygulamayı bir "ekstra kanal" değil, satış ve elde tutma sisteminizin parçası olarak konumlar.

Gelir modelini seçerken sık yapılan bir hata, kitleye uymayan bir modeli zorlamaktır. Ücretsiz bir alternatifin bol olduğu bir alanda ücretli indirme dayatmak ya da düşük trafikli bir uygulamayı reklamla döndürmeye çalışmak, iyi bir ürünü bile ticari olarak tıkar. Doğru soru "hangi model en çok kazandırır" değil, "benim kitlem hangi modelle ödeme yapmaya hazır" sorusudur. Model, ürüne ve kullanıcıya uymalı; tersi değil.

KOBİ tarafında en sağlıklı çerçeve, uygulamayı doğrudan bir gelir kaynağı olarak değil, mevcut geliri büyüten bir kaldıraç olarak görmektir. Uygulama üzerinden gelen tekrar siparişler, sadakat programının ürettiği ek satış ve azalan müşteri kaybı; bunlar "uygulama ne kadar kazandırdı" sorusunun asıl cevabıdır. Bu değeri ölçmek için uygulamayı en baştan satış ve CRM süreçlerinizle konuşacak şekilde kurgulamak gerekir.

Güvenlik ve KVKK: uygulamanın görünmeyen omurgası

Güvenlik, kullanıcının görmediği ama en çok güvendiği katmandır. Bir uygulamanın veri sızdırması, hem kullanıcı güvenini bir anda yok eder hem de KVKK kapsamında ciddi yasal sonuçlar doğurur. Bu yüzden güvenlik, geliştirmenin sonuna eklenen bir kontrol değil, baştan tasarlanan bir yaklaşımdır.

Teknik güvenliğin temelleri bellidir. Veriler hem aktarım sırasında (TLS ile şifreli iletişim) hem de durağan halde (şifreli depolama) korunmalıdır. API'ler güvenli olmalı: sağlam kimlik doğrulama, istek sınırlama (rate-limit), girdi doğrulama ve kritik kontrollerin sunucu tarafında yapılması. İstemciye asla güvenmemek, güvenli yazılımın altın kuralıdır. Bu ilkelerin web tarafındaki karşılığını web sitesi güvenliği nedir, nasıl sağlanır yazımızda ele aldık; mobil için de mantık aynıdır.

KVKK katmanı ise Türkiye'de yasal bir zorunluluktur. Uygulama, hangi veriyi neden topladığını açık bir aydınlatma metniyle anlatmalı, gereken yerde açık rıza almalı ve topladığı veriyi bir envanterle takip etmelidir. İzin ilkesi minimumdur; yalnızca gerçekten gereken izinleri isteyin ve her izni gerekçelendirin. En kritik nokta, uygulamanın mağaza gizlilik beyanlarıyla (Apple Privacy Labels, Google Data Safety) birebir tutarlı olmasıdır. Bu genel bir bilgidir, hukuki tavsiye değildir.

Güvenliği baştan tasarlamak neden ucuzdur?

Güvenlik, tıpkı erişilebilirlik gibi, sonradan yamalanınca en pahalı, baştan tasarlanınca en ucuz olan katmandır. Kimlik doğrulamayı, veri şifrelemeyi ve izin mimarisini geliştirme başlarken kurgulamak, uygulamanın doğal bir parçası olur; her şey bittikten sonra "şimdi güvenliği ekleyelim" demek ise çoğu zaman sistemin bel kemiğini yeniden düzenlemek anlamına gelir. Güvenli tasarım, ek bir özellik değil, sağlam yazılımın temel niteliğidir.

Pratik bir ilke, en az ayrıcalık kuralıdır: her bileşen, yalnızca işini yapmak için gereken en az yetkiye sahip olmalı. Uygulama gereksiz izin istememeli, backend gereksiz veriyi tutmamalı, bir kullanıcı başkasının verisine erişememelidir. Bu ilke basit görünür ama ihlali, en sık yaşanan veri sızıntılarının kökünde yatar. Güvenlik bir ürün değil, baştan sona tüm kararlara sinen bir disiplindir.

Mobil uygulama yaparken en sık yapılan hatalar

Başarısız uygulamaların çoğu, aynı birkaç hatanın etrafında döner. Bu hataları önceden bilmek, onları önlemenin en ucuz yoludur; çünkü her biri, süreç ilerledikçe düzeltmesi katlanarak pahalılaşan tuzaklardır. Aşağıda en sık görülenleri ve neden tehlikeli olduklarını topladık.

Bu hataların ortak paydası şudur: hepsi, mobil uygulamayı bir "proje" gibi görmekten kaynaklanır. Bir kere yap, teslim al, bitir mantığı; MVP'yi de, testi de, bakımı da, pazarlamayı da gereksiz görür. Oysa uygulama bir üründür ve ürünler yaşar, gelişir ve bakım ister. Bu zihniyet değişikliği, listelediğimiz hataların çoğunu tek başına önler.

İki hata daha, listeye eklenecek kadar sık görülür. Birincisi, en ucuz teklifi seçmektir; ilk bakışta tasarruf gibi görünen bu tercih, çoğu zaman yarım kalan, belgelenmemiş ve devredilemez bir kodla sonuçlanıp toplamda çok daha pahalıya patlar. İkincisi, geri bildirim döngüsünü kurmamaktır; kullanıcıların ne düşündüğünü dinleyecek bir kanal (mağaza yorumları, uygulama içi geri bildirim, destek hattı) olmadan, ürünü neyin iyileştireceğini asla öğrenemezsiniz.

Bu hataların hiçbiri teknik değildir; hepsi karar ve yaklaşım hatasıdır. İyi haber şu ki, önceden bilindiklerinde hepsi önlenebilir. Doğru başlangıç, doğru kapsam, doğru ekip ve doğru zihniyetle kurulan bir proje; bu tuzakların çoğunu daha ilk toplantıda devre dışı bırakır. Bu yüzden en değerli yatırım, ilk satır kod yazılmadan önce yapılan doğru planlamadır.

"Uygulama yaptırınca kullanıcı gelir mi?" Elde tutma gerçeği

En pahalı yanılgı budur ve verilerle çürütmek gerekir. "Uygulamayı mağazaya koyunca insanlar bulur, indirir ve kullanır" varsayımı, hemen hemen her başarısız uygulamanın altında yatar. Gerçek çok daha serttir: yayın, kullanıcı yolculuğunun sonu değil, ortasıdır.

Sektör verileri açık bir tablo çizer (bu oranlar kaynağa ve segmente göre değişir): yüklemelerin yaklaşık yüzde 46-48'i ilk 30 gün içinde silinir. Gün-1 elde tutma oranı ortalama yaklaşık yüzde 21-24 civarındadır; yani indirenlerin çoğu ertesi gün bile geri dönmez. Gün-30 elde tutma ise ortalama yaklaşık yüzde 3'e kadar düşebilir. Kullanıcıların kabaca dörtte biri, uygulamayı tek kullanımdan sonra bir daha açmaz. Bu tablo, "yaptırınca gelirler" varsayımının neden çöktüğünü net gösterir.

Doğru zihniyet şudur: uygulama yayınlandığında asıl iş başlar. Edinim (kullanıcıyı getirmek), elde tutma (geri getirmek) ve iterasyon (ürünü iyileştirmek) üçlüsü, en az geliştirme kadar önemlidir. ASO, pazarlama, bildirim stratejisi ve sürekli iyileştirme olmadan, en iyi kodlanmış uygulama bile sessizce kaybolur. Bütçenizi ve zihinsel enerjinizi yalnızca "yapmaya" değil, "yaşatmaya" da ayırmanız gerekir.

Elde tutmayı artıran temel kaldıraçlar

Elde tutmayı yükseltmenin sihirli bir formülü yoktur, ama kanıtlanmış kaldıraçları vardır. İlk kullanımda değeri hızlı göstermek (kullanıcı ilk açılışta "aha" anını yaşamalı), anlamlı bildirimlerle geri getirmek (spam değil, gerçekten faydalı hatırlatmalar), sürekli küçük iyileştirmeler ve kullanıcı geri bildirimini ciddiye almak. Bunların hepsi, bakım ve iterasyon adımının parçasıdır.

Bu yüzden Alis Dijital olarak bir uygulamayı teslim edip çekilmek yerine, yayından sonraki dönemi baştan planın parçası olarak konumlarız. Ürünü ölçer, veriye göre iyileştirir ve elde tutma kaldıraçlarını sürece yerleştiririz; çünkü asıl değer, indirilen değil, kullanılmaya devam eden bir uygulamadadır.

Bu verilerin bir başka dersi de beklenti yönetimidir. Elde tutma oranlarının doğası gereği düşük olması, sizin uygulamanızın başarısız olduğu anlamına gelmez; sektörün gerçeğidir. Önemli olan mutlak rakamlar değil, kendi eğrinizi zaman içinde iyileştirebilmenizdir. Bir sürümde Gün-30 elde tutmayı bir puan yükseltmek bile, uzun vadede birikerek büyük bir fark yaratır. Bu yüzden hedef "kusursuz bir ilk sürüm" değil, "sürekli iyileşen bir eğri" olmalıdır.

Edinim tarafında da gerçekçi olmak gerekir. Organik indirmeler tek başına nadiren yeterlidir; ASO, sosyal medya, mevcut müşteri tabanına duyuru ve gerektiğinde ücretli tanıtım, uygulamanın görünür olması için birlikte çalışır. En sağlıklı yaklaşım, pazarlama bütçesini geliştirme bütçesinin bir devamı olarak, en baştan planlamaktır. Yayın gününde "artık pazarlamayı düşünürüz" demek, çoğu uygulamanın sessizce kaybolduğu andır.

Türkiye'de mobil-ilk çağ ve KOBİ için anlamı

Türkiye, mobil kullanımın çok yüksek olduğu bir pazar. DataReportal'ın 2026 verilerine göre mobil bağlantı sayısı nüfusun yaklaşık yüzde 93'üne ulaşıyor, internet erişimi yaklaşık yüzde 88 düzeyinde ve web trafiğinin kaynağa göre yaklaşık yüzde 65'i mobil cihazlardan geliyor. Bu, artık "mobil de düşünelim" değil, "mobil-ilk düşünelim" çağı anlamına gelir.

Ama bu tablo, "her KOBİ'nin uygulaması olmalı" sonucuna götürmez. Doğru okuma şudur: her işletmenin mobilde kusursuz bir deneyim sunması şart; bu deneyimin bir uygulama mı yoksa mobil uyumlu bir web/PWA mi olacağı ise ihtiyaca göre değişir. Çoğu KOBİ için doğru başlangıç, önce mobilde mükemmel çalışan bir web varlığı, ardından talep doğrulandığında bir uygulamadır.

KOBİ için mobil uygulamanın gerçek değeri, çoğu zaman doğrudan gelir değil; operasyon, sadakat ve elde tutmadır. Sipariş kolaylığı, sadakat programı, randevu/rezervasyon, hızlı bildirim ve tekrar satış; işte uygulamanın KOBİ'ye kattığı asıl güç budur. Uygulamayı bir "prestij projesi" değil, satışı ve müşteri ilişkisini güçlendiren bir araç olarak kurgulamak, yatırımın geri dönüşünü belirler.

Alis Dijital ile fikirden yayına ve sonrasına

Alis Dijital, Kayseri merkezli bir özel yazılım ve mobil uygulama geliştirme ajansıdır; işletmeleri fikirden yayına ve sonrasındaki bakıma kadar tüm süreçte yürütür. Yaklaşımımız bir teknolojiyi dayatmak değil; doğru problemi, doğru kitle için, doğru yaklaşımla (native, cross-platform ya da önce mobil web) birlikte seçmek ve MVP'den ölçeğe kadar götürmektir.

Bir uygulama fikriniz varsa ama nereden başlayacağınızı bilmiyorsanız, en sağlıklı ilk adım küçük ve ücretsiz bir analizdir. Fikri doğrular, kapsamı ve MVP'yi çıkarır, yaklaşık maliyet ve süre aralığını netleştiririz; ardından yol haritasını birlikte kurarız. Sürecin tüm kapsamını özel yazılım ve mobil geliştirme hizmetimiz sayfasında görebilirsiniz.

Projenizi konuşmaya hazırsanız, ücretsiz analiz ile başlayın. Size doğru cevabı satmak değil, doğru soruları sorduran dürüst bir çerçeve sunmak istiyoruz; çünkü iyi bir mobil uygulama, doğru kararla başlar ve bakımla yaşar. Fikirden yayına ve sonrasına kadar, işletmenizin dijital gücünü birlikte kurgulayalım.