Bir mobil uygulama projesi için ekip seçmek, çoğu zaman yazılım dilinden daha kritik bir karardır. Çünkü iyi bir fikir; yanlış kapsam, zayıf mimari, eksik test veya yetersiz bakım yüzünden pazara çıkmadan bütçe tüketebilir.
Özellikle mobil uygulama geliştirme projesi planlayan bir işletme için doğru şirket seçimi, sadece “uygulamayı kim kodlayacak?” sorusu değildir. Asıl soru şudur: Bu ekip fikri anlayabiliyor mu, teknik riski yönetebiliyor mu, uygulamayı mağazaya çıkarıp sonrasında ayakta tutabiliyor mu?
Türkiye’de mobil kullanımın iş kararlarındaki etkisi de bunu daha önemli hale getiriyor. DataReportal’ın Digital 2026 Turkey raporuna göre Türkiye’de 2025 sonu itibarıyla 81,9 milyon aktif hücresel mobil bağlantı bulunuyor ve bu rakam toplam nüfusun %93,3’üne denk geliyor. Bu veri, mobil uygulamanın artık sadece büyük markalar için değil; saha ekipleri, bayi ağları, e-ticaret şirketleri, eğitim kurumları, sağlık platformları ve topluluk yönetimi yapan yapılar için de ciddi bir kanal olduğunu gösteriyor. Kaynak: DataReportal Digital 2026 Turkey
Atalay Tech perspektifinden bakıldığında iyi bir mobil uygulama şirketi; fikri teknik dile çeviren, kapsamı parçalara bölen, ilk sürümü gereksiz şişirmeyen ve projeyi yayın sonrası büyümeye uygun kurgulayan şirkettir.
Bir teklifin düşük veya yüksek görünmesi tek başına anlamlı değildir. Aynı “mobil uygulama” ifadesi altında çok farklı kapsamlar olabilir.
Örneğin bir randevu uygulaması sadece kullanıcı girişi, takvim ve bildirimden oluşuyorsa farklı bütçelendirilir. Ancak aynı uygulamada ödeme altyapısı, çoklu şube yönetimi, canlı mesajlaşma, rol bazlı panel, abonelik sistemi, KVKK onayı, raporlama ve yapay zeka destekli öneri modülü varsa proje artık basit uygulama değil, ürün altyapısıdır.
Bu yüzden mobil uygulama şirketi seçerken ilk toplantıda şu sorulara verilen cevaplara bakılmalıdır:
Kapsam netliği olmayan projede genellikle iki sorun çıkar: Proje ortasında “bu dahil değildi” tartışması başlar veya ilk sürüm gereksiz özelliklerle ağırlaşır. İki senaryo da bütçeyi ve takvimi bozar.
Teknik yetkinliği anlamak için şirketin hangi teknolojiyi kullandığını sormak yeterli değildir. “React Native kullanıyoruz” veya “native yazıyoruz” cevabı tek başına kalite göstergesi olmaz. Önemli olan, bu teknolojinin proje senaryosuna neden uygun görüldüğüdür.
Bir kurumsal saha uygulamasında offline veri senkronizasyonu gerekebilir. Bir sosyal uygulamada gerçek zamanlı mesajlaşma ve bildirim mimarisi öne çıkar. Bir video içerik platformunda medya sıkıştırma, CDN, güvenli video erişimi ve depolama maliyeti kritik hale gelir.
Atalay Tech’in mobil uygulama, web platformu ve AI entegrasyonu içeren proje türlerinde gördüğü temel fark şudur: Teknik tercih, özellik listesine göre değil, ölçeklenme senaryosuna göre yapılmalıdır.
| Kriter | Zayıf Yaklaşım | Güçlü Yaklaşım |
|---|---|---|
| Teknoloji seçimi | “Her projeyi aynı stack ile yaparız” | Proje tipine göre React Native, native, webview veya hibrit yapı değerlendirilir |
| Backend planı | Sadece mobil ekranlara odaklanır | API, yönetim paneli, rol sistemi ve veri modeli birlikte planlanır |
| Performans | Yayın sonrası bakılır | Listeleme, medya, cache ve sorgu yapısı baştan düşünülür |
| Güvenlik | Sadece SSL yeterli görülür | Token, oturum, yetki, log, veri şifreleme ve KVKK akışı planlanır |
| Bakım | “Yayına çıkınca biter” denir | Versiyon güncelleme, hata takibi ve izleme süreci belirlenir |
Burada önemli nokta şudur: İyi şirket, teknolojiyi pazarlama cümlesi olarak değil, karar gerekçesiyle açıklar. “Bu projede neden React Native mantıklı?”, “Hangi durumda native gerekir?”, “Backend nasıl ölçeklenir?” gibi sorulara açık ve somut cevap vermelidir.
Bir şirketin referans sayfası önemli bir sinyaldir; ancak tek başına görsel kalite yeterli değildir. Uygulama güzel görünebilir ama veri akışı kötü olabilir. Panel kullanışsız olabilir. Mağaza yorumları düşük olabilir. Bakım süreci iyi yönetilmemiş olabilir.
Atalay Tech referansları gibi proje sayfalarını incelerken şu detaylara bakmak daha sağlıklıdır:
Bir örnek düşünelim: Lojistik sahasında çalışan 45 kişilik bir ekibi olan işletme, mobil uygulama ile teslimat fotoğrafı, konum, imza ve durum takibi yapmak istiyor. Bu projede görsel tasarım kadar internet kesildiğinde verinin ne olacağı, fotoğraf yükleme maliyeti, konum doğruluğu ve panel raporlaması önemlidir.
Referans incelemesinde “ekranlar güzel mi?” sorusu yerine “benim iş akışıma benzer teknik karmaşıklık çözülmüş mü?” sorusuna odaklanmak gerekir.
Mobil uygulama projelerinde problem çoğu zaman kod yazımında değil, süreç yönetiminde çıkar. Keşif eksik yapılırsa tasarım revizyonları artar. Tasarım netleşmeden geliştirme başlarsa ekranlar değiştikçe yazılım yeniden yazılır. Test planı yoksa mağaza yayını gecikir.
Sağlıklı bir mobil uygulama süreci genellikle şu akışla ilerler:
| Aşama | Amaç | Somut Çıktı | Ortalama Süre |
|---|---|---|---|
| Keşif | İş modeli ve kapsamı netleştirmek | Kapsam dokümanı, kullanıcı rolleri, özellik listesi | 3-10 gün |
| UX/UI tasarım | Kullanıcı akışını görselleştirmek | Wireframe, Figma ekranları, prototip | 1-4 hafta |
| MVP geliştirme | İlk kullanılabilir sürümü üretmek | Mobil uygulama, API, temel panel | 4-10 hafta |
| Test | Hata ve akış kontrollerini yapmak | Test listesi, cihaz kontrolleri, düzeltmeler | 1-3 hafta |
| Yayın | App Store ve Google Play sürecini tamamlamak | Mağaza hesapları, build, review süreci | 3-14 gün |
| Bakım | Uygulamayı canlıda stabil tutmak | Hata takibi, güncelleme, raporlama | Sürekli |
Apple’ın App Store Review Guidelines dokümanında uygulamalar güvenlik, performans, iş modeli, tasarım ve yasal uygunluk gibi başlıklarda değerlendirilir. Bu yüzden mağaza yayını, projenin sonunda “son bir işlem” gibi görülmemelidir; tasarım ve geliştirme aşamasından itibaren dikkate alınmalıdır. Kaynak: Apple App Store Review Guidelines
Google Play tarafında da politika değişiklikleri, veri güvenliği, hassas izinler ve geliştirici gereksinimleri düzenli olarak güncellenir. Özellikle konum, kamera, mikrofon, sağlık verisi, ödeme veya kullanıcı üretimli içerik içeren uygulamalarda bu gereklilikler proje planına baştan dahil edilmelidir. Kaynak: Google Play Policy Center
Mobil uygulama yaptırmak isteyen işletmelerin sık yaptığı hata, ilk sürümde her şeyi istemektir. Bu yaklaşım özellikle startup, yeni pazar testi veya operasyonel dönüşüm projelerinde risklidir.
MVP, ürünün en zayıf hali değildir. MVP, iş modelini test edecek en küçük anlamlı sürümdür.
Örneğin bir eğitim uygulamasında ilk sürümde şu özellikler yeterli olabilir:
Aynı projenin kurumsal sürümünde ise abonelik, sertifika, canlı ders, çoklu eğitmen, raporlama, kurum bazlı lisanslama, AI destekli öneri, CRM entegrasyonu ve gelişmiş analitik gerekebilir.
| Proje Tipi | Kimler İçin Uygun | Kapsam | Tahmini Süre | Tahmini Bütçe |
|---|---|---|---|---|
| MVP | Fikrini test etmek isteyen girişim veya KOBİ | Temel kullanıcı akışı, giriş, panel, sınırlı özellik | 6-10 hafta | 250.000 - 600.000 TL + KDV |
| Orta ölçek | Gelir modeli netleşmiş işletme | Ödeme, bildirim, gelişmiş panel, entegrasyon | 10-18 hafta | 600.000 - 1.500.000 TL + KDV |
| Kurumsal | Çok kullanıcılı, entegrasyonlu yapı | Rol sistemi, ERP/CRM, raporlama, güvenlik, ölçeklenme | 4-8 ay | 1.500.000 TL - 5.000.000 TL+ + KDV |
Bu aralıklar piyasa, kapsam, entegrasyon sayısı, ekip yoğunluğu ve bakım beklentisine göre değişir. Ancak bir şirket size kapsamı anlamadan tek cümleyle fiyat veriyorsa, bu ciddi bir risk sinyalidir.
Daha net bir başlangıç değerlendirmesi için mobil uygulama fiyatları aracını kullanarak fikir seviyesindeki projenin hangi bütçe bandına yaklaşabileceğini görebilirsiniz.
Her proje için aynı ekip modeli doğru değildir. Küçük bir tanıtım uygulaması için freelancer yeterli olabilir. Orta ölçekli bir müşteri uygulaması için mobil uygulama ajansı mantıklı olabilir. API, panel, ödeme, mesajlaşma, video, AI veya kurumsal entegrasyon içeren yapılarda ise yazılım şirketi yaklaşımı daha güvenli olur.
| Ekip Modeli | Avantaj | Risk | Uygun Proje |
|---|---|---|---|
| Freelancer | Daha düşük başlangıç maliyeti | Tek kişiye bağımlılık, bakım riski | Basit MVP, prototip, küçük modül |
| Ajans | Tasarım ve pazarlama dili güçlü olabilir | Teknik derinlik ekipten ekibe değişir | Marka odaklı uygulama, kampanya ürünü |
| Yazılım şirketi | Backend, panel, entegrasyon ve bakım daha sistemlidir | Başlangıç maliyeti daha yüksek olabilir | Kurumsal uygulama, ölçekli mobil ürün |
| İç ekip | Sürekli kontrol sağlar | İşe alım ve yönetim maliyeti yüksektir | Uzun vadeli ürün şirketleri |
Bir persona üzerinden düşünelim: Ayşe, 34 yaşında, İstanbul’da 12 şubeli bir güzellik merkezi zincirini yönetiyor. Mobil uygulamada randevu, ödeme, kampanya bildirimi, sadakat puanı ve şube paneli istiyor. Bu proje sadece “güzel ekran” işi değildir. Takvim çakışması, ödeme iptali, personel yetkisi, bildirim yoğunluğu ve müşteri verisi güvenliği gerekir. Ayşe için tek kişilik çözüm yerine süreç yöneten bir mobil uygulama şirketi daha doğru seçim olur.
İyi teklif, sadece toplam fiyat ve teslim tarihinden oluşmaz. Teklifte neyin dahil olduğu kadar, neyin dahil olmadığı da yazmalıdır.
Mobil uygulama teklifinde şu başlıklar net olmalıdır:
Burada en kritik detaylardan biri kaynak kod ve hesap sahipliğidir. App Store, Google Play, Firebase, ödeme altyapısı, sunucu, domain ve e-posta hesaplarının kime ait olacağı baştan konuşulmalıdır. Aksi halde proje bitince operasyonel bağımlılık oluşabilir.
Kullanıcı verisi toplayan her mobil uygulama, güvenlik açısından değerlendirilmelidir. Özellikle sağlık, finans, eğitim, üyelik, konum, mesajlaşma veya ödeme içeren uygulamalarda bu konu tasarım aşamasında ele alınmalıdır.
Sadece “veriler şifreleniyor” demek yeterli değildir. Hangi veri nerede tutuluyor, kim erişiyor, loglar nasıl saklanıyor, kullanıcı hesabını nasıl siliyor, yedekler nasıl korunuyor, API yetkilendirmesi nasıl yapılıyor soruları cevaplanmalıdır.
GSMA’nın Mobile Economy 2026 raporunda mobil teknolojilerin 2025’te küresel ekonomiye 7,6 trilyon dolar katkı sağladığı belirtiliyor. Mobilin ekonomik ağırlığı arttıkça güvenlik, gizlilik ve operasyonel dayanıklılık da daha kritik hale geliyor. Kaynak: GSMA Mobile Economy 2026
Güvenlik konuşmasını erteleyen ekipler genellikle projeyi yayına yaklaştığında düzeltmeye çalışır. Bu da daha pahalıdır. Örneğin rol sistemi sonradan eklenirse sadece panel değil, API, mobil ekranlar ve test senaryoları da yeniden düzenlenir.
Mobil uygulama yayına çıktığında proje bitmez. App Store ve Google Play politika güncellemeleri, işletim sistemi sürümleri, cihaz uyumluluğu, kütüphane güncellemeleri, sunucu bakımı, hata kayıtları ve kullanıcı geri bildirimleri devam eder.
İyi bir mobil uygulama şirketi yayın sonrası şu başlıkları konuşur:
Örneğin bir e-ticaret uygulamasında ödeme ekranında %3’lük terk oranı düşüşü bile aylık ciroya doğrudan etki edebilir. Bu iyileştirme ancak analitik, event takibi ve düzenli ürün geliştirme kültürüyle yakalanır.
Bazı sinyaller proje başlamadan önce riskin yüksek olduğunu gösterir. Bunlar her zaman kötü niyet anlamına gelmez; ama yönetilmezse bütçe ve zaman kaybı yaratır.
| Kırmızı Bayrak | Neden Riskli? | Ne Yapmalısınız? |
|---|---|---|
| Kapsam sormadan fiyat verme | Proje gerçek boyutu anlaşılmamıştır | Detaylı keşif dokümanı isteyin |
| Her şeyi 2 haftada bitirme vaadi | Test ve mağaza süreci yok sayılıyor olabilir | Aşamaları ve teslimleri sorun |
| Kaynak kod konusunun belirsizliği | Proje sonrası bağımlılık doğabilir | Sözleşmede sahipliği netleştirin |
| Panel ve backend konuşulmaması | Uygulama yönetilemez hale gelebilir | Yönetim ekranlarını ayrıca isteyin |
| Bakım planı olmaması | Yayın sonrası sorunlar sahipsiz kalabilir | Destek modeli talep edin |
| Güvenlik sorularına yüzeysel cevap | Veri riski oluşabilir | API, rol, log ve KVKK akışını sorun |
En sağlıklı seçim yöntemi, sadece “kim daha uygun fiyat verdi?” diye bakmak değildir. “Kim riskleri daha erken fark etti?” sorusu daha iyi sonuç verir.
Atalay Tech olarak mobil uygulama, web platformu, yönetim paneli, AI entegrasyonu ve API tabanlı sistemlerde en kritik kararın proje başında verildiğini görüyoruz: Kapsamı doğru küçültmek.
Birçok işletme ilk toplantıda büyük bir ürün hayal eder. Bu doğaldır. Ancak iyi ekip, fikri küçümsemeden fazlara ayırır. İlk fazda pazara çıkmayı, ikinci fazda veriye göre geliştirmeyi, üçüncü fazda ölçeklemeyi planlar.
Bu yaklaşım özellikle şu proje tiplerinde işe yarar:
Doğru şirket, “evet yaparız” demekle yetinmez. Bazen “bu özellik ilk sürüme girmemeli” diyebilmelidir. Çünkü iyi ürün geliştirme, sadece isteneni kodlamak değil, doğru sırayla inşa etmektir.
İlk kriter fiyat değil, kapsamı anlama kalitesi olmalıdır. Bir şirket ilk görüşmede sadece “kaç ekran olacak?” diye soruyorsa projeyi yüzeysel değerlendiriyor olabilir. Daha güçlü ekipler kullanıcı rollerini, gelir modelini, yönetim paneli ihtiyacını, veri akışını, entegrasyonları, güvenlik seviyesini ve yayın sonrası bakım beklentisini konuşur. Örneğin bir randevu uygulamasında sadece takvim ekranı değil; çakışma yönetimi, iptal politikası, bildirim, ödeme ve personel yetkisi de değerlendirilmelidir. Bu yüzden doğru şirket, tekliften önce iş modelini teknik dile çevirebilen şirkettir.
Evet, özellikle orta ve büyük ölçekli projelerde teknik şartname ciddi avantaj sağlar. Şartname; özellikleri, kullanıcı rollerini, ekranları, yönetim panelini, entegrasyonları, teslimleri ve kabul kriterlerini netleştirir. Bu belge olmadan alınan teklifler birbiriyle karşılaştırılamaz hale gelir. Bir firma sadece mobil ekranları fiyatlarken, başka bir firma backend, panel, test ve mağaza süreçlerini dahil edebilir. Teknik şartname, hem bütçe kontrolü hem de proje yönetimi için gereklidir. MVP seviyesinde bile kısa bir kapsam dokümanı hazırlanması, sonradan çıkacak anlaşmazlıkları azaltır.
En ucuz teklif her zaman kötü değildir; ancak kapsamı belirsiz ucuz teklif risklidir. Düşük fiyatın nedeni bazı kalemlerin dışarıda bırakılması olabilir: yönetim paneli, API güvenliği, test, mağaza yayını, bakım, kaynak kod teslimi veya üçüncü parti servisler ayrıca ücretlendirilebilir. Örneğin ödeme altyapısı içeren bir uygulamada sanal POS entegrasyonu, iade akışı, işlem logları ve hata senaryoları hesaba katılmadıysa proje ortasında ek maliyet doğar. Bu yüzden teklif karşılaştırırken toplam fiyat yerine dahil olan teslimleri, revizyon sınırını ve yayın sonrası desteği incelemek gerekir.
Bu karar projenin türüne bağlıdır. Marka deneyimi, kampanya uygulaması veya tasarım ağırlıklı kısa süreli projelerde ajans modeli yeterli olabilir. Ancak ödeme, mesajlaşma, video, yapay zeka, ERP/CRM entegrasyonu, rol bazlı panel veya yoğun veri akışı olan projelerde yazılım şirketi yaklaşımı daha güvenlidir. Çünkü bu projeler sadece arayüz değil, mimari ve operasyon konusudur. Yazılım şirketi genellikle backend, API, panel, güvenlik, sunucu ve bakım süreçlerini daha bütünsel ele alır. En doğru seçim, projenin teknik karmaşıklığına göre yapılmalıdır.
Mobil uygulama maliyeti ekran sayısından çok iş akışına göre hesaplanır. Kullanıcı rolleri, platform sayısı, backend yapısı, yönetim paneli, ödeme sistemi, bildirimler, medya yükleme, harita, mesajlaşma, AI entegrasyonu, güvenlik ve bakım modeli bütçeyi etkiler. Basit bir MVP 250.000 - 600.000 TL + KDV bandında başlayabilirken, orta ölçekli projeler 600.000 - 1.500.000 TL + KDV aralığına çıkabilir. Kurumsal, entegrasyonlu ve çok rollü projelerde bütçe birkaç milyon TL seviyesine ulaşabilir. Net hesaplama için kapsam analizi yapılmalıdır.
İlk görüşmede teknoloji isimleri yerine karar gerekçelerini sorun. “Neden React Native?”, “Offline çalışması gerekirse ne olur?”, “Bildirim altyapısı nasıl kurulacak?”, “API güvenliği nasıl sağlanacak?”, “Panelde hangi roller olacak?”, “Crash raporlama kullanıyor musunuz?” gibi sorular teknik olgunluğu gösterir. İyi ekipler bu sorulara savunmaya geçmeden net cevap verir. Ayrıca referanslarında sadece görsel ekranlara değil, çözülmüş iş problemlerine bakın. Eğer şirket daha önce panel, ödeme, bildirim, medya, entegrasyon veya canlı veri içeren projeler geliştirdiyse bu iyi bir sinyaldir.
Evet, mobil uygulama canlıya çıktıktan sonra bakım bütçesi planlanmalıdır. İşletim sistemi güncellemeleri, mağaza politika değişiklikleri, sunucu güvenliği, kütüphane güncellemeleri, hata düzeltmeleri ve kullanıcı geri bildirimleri devam eder. Özellikle gelir üreten uygulamalarda bakım, maliyet değil süreklilik yatırımıdır. Örneğin ödeme ekranında çıkan küçük bir hata, günlük satış kaybına neden olabilir. Bu yüzden sözleşmede kritik hata müdahale süresi, aylık destek kapsamı, yeni özellik geliştirme yöntemi ve versiyon güncelleme süreçleri net yazılmalıdır.
Sözleşmede kapsam, teslim tarihleri, ödeme planı, revizyon sınırları, kaynak kod sahipliği, mağaza hesapları, üçüncü parti servisler, bakım süresi, gizlilik ve fesih koşulları net olmalıdır. Ayrıca hangi teslimlerin kabul edilmiş sayılacağı belirtilmelidir. Örneğin “uygulama teslimi” ifadesi tek başına yeterli değildir; iOS ve Android build, panel, API, test ortamı, canlı ortam, mağaza yayını ve dokümantasyon ayrı ayrı yazılmalıdır. Bu netlik hem müşteriyi hem de yazılım ekibini korur. Belirsiz sözleşmeler proje ortasında beklenti çatışmasına neden olur.
Mobil uygulamada teknik borç; hızlı teslim, eksik test, zayıf mimari ve plansız bakım yüzünden uygulamanın zamanla pahalı, kırılgan ve yavaş geliştirilir hale gelmesidir. Bu rehber; teknik borcu önlemek için mimari, test, sürümleme, bakım ve maliyet kararlarını somut örneklerle açıklar.
Mobil uygulama güncelleme süreci yalnızca yeni sürüm yüklemek değildir. Kapsam analizi, sürüm notu, test, mağaza onayı, kademeli dağıtım, hata takibi ve bakım planı birlikte yönetildiğinde uygulama daha stabil, güvenli ve sürdürülebilir olur.
Mobil uygulama bakım ve destek süreci; yayındaki bir uygulamanın güvenli, hızlı, güncel ve kullanıcı beklentilerine uygun kalmasını sağlar. Bu rehberde bakım kapsamını, destek seviyelerini, maliyet aralıklarını, mağaza uyumluluğunu, güvenlik kontrollerini ve Atalay Tech'in proje sonrası yaklaşımını pratik örneklerle in
