
Clients
İstanbul Mobil Uygulama Geliştirme Hizmeti
İstanbul Mobil Uygulama Geliştirme Hizmeti
İstanbul'da mobil uygulama geliştirme hizmeti, keşif aşamasından mağaza yayınına ve sonrasındaki bakıma kadar uzanıyor. Bu rehber hizmetin kapsamını, sürecini ve fiyatı belirleyen değişkenleri açıklıyor.
İstanbul'da mobil uygulama geliştirme hizmeti, keşif aşamasından mağaza yayınına ve sonrasındaki bakıma kadar uzanıyor. Bu rehber hizmetin kapsamını, sürecini ve fiyatı belirleyen değişkenleri açıklıyor.
İstanbul'da mobil uygulama yaptırırken neye bakmalı?
Doğru hizmeti seçmek, teklifi okumadan önce neye bakacağınızı bilmekten geçiyor. Kapsamın nereye kadar uzandığı, sürecin hangi adımlardan oluştuğu ve fiyatı hangi kalemlerin oluşturduğu üç temel kontrol noktasını meydana getiriyor. Aşağıdaki bölümler bu üçünü sırayla ele alıyor ve sonunda teklif toplarken kullanabileceğiniz soru listesini veriyor.
Mobil uygulama geliştirme hizmeti neleri kapsıyor?
Mobil uygulama geliştirme hizmeti, bir fikrin App Store ve Google Play'de yayına girmesi ve yayından sonra yaşamaya devam etmesi için gereken tüm işleri kapsıyor. Yalnızca kod yazmaktan ibaret değil, çünkü teslim edilen şey bir dosya değil, çalışan ve bakımı sürdürülen bir ürün.
Uçtan uca bir hizmet paketi şu başlıklardan oluşuyor.
Planlama ve özellik tanımı, ürünün hedeflerini, kullanıcı davranışını ve hangi ekranın hangi işi yaptığını netleştiriyor. Bu aşamada kullanıcı akışları hazırlanıyor ve ilk sürümün kapsamı yazılı hale geliyor.
UI ve UX tasarımı, kullanıcı yolculuğu haritalarından düşük çözünürlüklü tel çerçevelere, oradan yüksek çözünürlüklü ekranlara ve tasarım sistemine uzanıyor. Çıktılar geliştiriciye hazır biçimde, düzenli Figma dosyaları ve yeniden kullanılabilir bileşen kütüphaneleri olarak teslim ediliyor.
Mobil geliştirme, iOS ve Android tarafında uygulamanın kendisini yazıyor. Temiz ve ölçeklenebilir mimari, performans için optimize edilmiş ekranlar, yerel depolama, önbellekleme ve çevrimdışı destek bu kalemin içinde yer alıyor.
Arka uç geliştirme, veriyi, iş kurallarını, kimlik doğrulamayı ve API uçlarını kuruyor. Rol bazlı erişim ve yetkilendirme de burada tanımlanıyor.
Entegrasyonlar, uygulamayı ödeme sistemlerine, abonelik altyapısına, analitik araçlarına, sosyal girişe, push bildirimlerine, üçüncü taraf API'lerine ve yapay zeka destekli servislere bağlıyor.
Kalite güvence, uygulamayı farklı cihaz ve ekran boyutlarında test ediyor, görsel tutarlılığı ve kararlı davranışı doğruluyor.
Mağaza yayını, listeleme hazırlığını, gönderim desteğini ve uyum kontrollerini kapsıyor.
Analitik ve gelirlendirme kurulumu, olay takibini, dönüşüm ölçümünü ve abonelik yapısını çalışır hale getiriyor.
Bakım ve destek, yayın sonrasında hata giderme, performans iyileştirme, bağımlılık yönetimi ve özellik güncellemelerini yürütüyor.
Teklif alırken bu dokuz başlığın hangilerinin kapsamda olduğunu tek tek sormanız gerekiyor. En sık yaşanan sorun, tekliflerin ilk beş kalemi içerip son dördünü dışarıda bırakması ve farkın proje bittikten sonra ortaya çıkmasıdır.
Kapsam sektöre göre de değişiyor. E-ticaret uygulamalarında ödeme altyapısı, sepet ve kampanya kurgusu eforun büyük bölümünü oluşturuyor. Sağlık ve wellness uygulamalarında kullanıcı verisinin işlenmesi ek uyum yükü getiriyor. Ulaşım ve mobilite platformlarında konum servisleri ile gerçek zamanlı veri öne çıkıyor. Bankacılık ve finans uygulamalarında ise kimlik doğrulama, güvenlik ve mevcut sistem entegrasyonu kapsamın merkezinde duruyor.

Mobil uygulama yaptırma süreci nasıl işliyor?
Mobil uygulama nasıl yapılır sorusunun kurumsal projelerdeki cevabı, her adımın kendi çıktısı olan bir süreçten geçiyor. Aşağıdaki tablo adımları ve o adım sonunda elinize geçen somut çıktıyı gösteriyor.
Adım | Elinize geçen çıktı |
Kick-off ve kapsam netleştirme | Hedef tanımı, ilk sürüm kapsamı, atanan sabit proje ekibi |
Tasarım dili sprinti ve onay | Kısa sürede hazırlanan renk, tipografi ve bileşen dili, ilk onay |
Ekran bazlı tasarım üretimi | Onaylanan tasarım diline göre ekran ekran teslim edilen arayüzler |
Mimari kurulumu ve geliştirme | Çalışan sürümler, API uçları, veri yapısı, projenin yazılım kurgusu |
Entegrasyonlar | Ödeme, abonelik, analitik, bildirim ve üçüncü taraf bağlantıları |
Kalite ve cihaz testi | Test raporu, düzeltilmiş hatalar, kararlı sürüm |
Mağaza listeleme ve gönderim | Yayınlanmış uygulama, mağaza metinleri, uyum kontrolleri |
Yayın sonrası izleme ve iyileştirme | Yayınlanmış proje ve ardından özellik güncellemeleri |
Takvim projeye göre belirleniyor ve tek bir standart süre bulunmuyor. Süreyi asıl belirleyen değişken ekran sayısı değil, bağlanılacak sistem sayısı ile bu sistemlerin dokümantasyon olgunluğu oluyor. Bu yüzden teklif aşamasında adım bazlı bir takvim istemeniz, size tek bir toplam süreden çok daha fazlasını söylüyor.
Süreç boyunca en sık kayma entegrasyon testlerinde yaşanıyor. Karşı tarafın test ortamı hazır değilse veya arayüzü belgelenmemişse ekip bekleme moduna giriyor. İkinci sık kayma nedeni onay döngüleri oluyor; tasarım ve kabul onaylarını verecek kişiler baştan isimlendirilmezse her adım sonunda birkaç günlük beklemeler birikiyor.
İyi işleyen bir süreçte ilerlemeyi düzenli olarak görüyorsunuz. Çalışan sürümlerin belirli aralıklarla paylaşılması, ilerlemenin sunumdan değil çalışan üründen okunmasını sağlıyor.
Mobil uygulama fiyatı nasıl belirleniyor?
Mobil uygulama geliştirmede herkese uyan tek bir yaklaşım bulunmuyor. Doğru geliştirme stratejisi ve dolayısıyla fiyat, ürünün karmaşıklığı, bütçe ve ölçeklenebilirlik gereksinimleri birlikte değerlendirilerek belirleniyor. Bu yüzden hazır bir fiyat listesi yerine projeye özel teklif çıkarılıyor.
Teklifin tutarını belirleyen şey ekran sayısı değil, aşağıdaki kararların toplamı oluyor.
Kapsamı belirleyen karar | Fiyata nasıl yansıyor |
Özellik seti ve ilk sürüm kapsamı | Özellik tanımı aşamasında ilk sürüme hangi akışların gireceği belirlenir; kapsam büyüdükçe geliştirme ve test eforu birlikte artar |
Ekip yapısı ve kıdem | Tek geliştirici ile roller ayrı tanımlanmış sabit bir ekip aynı işi anlatmaz; kıdemli proje yöneticisinin yanına tasarım, arka uç ve test rollerinin ayrı ayrı atanması efor ve fiyatı değiştirir |
Platform stratejisi | Swift ile yerel geliştirme maksimum performans ve derin cihaz erişimi sağlar, Flutter ile tek kod tabanı daha hızlı teslim ve tek bakım hattı sunar |
Arka uç ihtiyacı | Kimlik doğrulama, gerçek zamanlı veri ve bildirim altyapısı kurulacaksa arka uç ayrı bir geliştirme kalemi olur |
Entegrasyon listesi | Ödeme, abonelik, analitik, sosyal giriş, push bildirim ve üçüncü taraf API'lerin her biri ayrı bağlantı, test ve hata senaryosu getirir |
Tasarım derinliği | Tasarım dili sprintinden ekran bazlı üretime uzanan çıktı seti, ekran sayısından bağımsız bir efor kalemidir |
Faz yapısı | Kapsamlı işlerde ilk faz MVP olarak sınırlanıp ayrı fiyatlanabilir; sonraki fazlar kapsam netleştikçe ayrı kalem olarak eklenir |
Gelirlendirme kurulumu | Abonelik yapısı, ödeme duvarı ve deneme akışları tasarım ve geliştirme tarafında ayrı iş oluşturur |
Yayın sonrası kapsam | Bakım, izleme ve büyüme çalışmaları ilk teslimden sonra tekrar eden kalemlerdir |
Bu kararların hepsi keşif ve özellik tanımı aşamasında netleşiyor. Kapsam yazılı hale gelmeden çıkan bir fiyat, tahmin olmaktan öteye geçmiyor. Bu yüzden teklif almadan önce entegrasyon listesini ve kullanıcı rollerini çıkarmanız, gelen rakamın gerçekçiliğini doğrudan artırıyor.
Sağlıklı bir fiyatlandırma ilk günden itibaren öngörülebilir oluyor. Bütçenin nereye gittiğinin görünmesi, sürpriz kalem çıkmaması ve kapsam dışı bırakılan işlerin de yazılı olması aranması gereken standardı oluşturuyor. Teklifte hangi kalemin ne kadar tuttuğu görünmüyorsa, o teklif karşılaştırılabilir bir teklif sayılmıyor.
Yayın sonrası kalemleri ilk bütçeye dahil etmeniz gerekiyor. Bakım, izleme ve gelirlendirme çalışmalarının kapsamı sözleşmede tanımlanmadığında bu gider yok olmuyor, yalnızca birinci yıl görünmez kalıyor ve ikinci yıl planlanmamış bir harcama olarak masaya geliyor.


Hangi teknolojiyle geliştirilmeli?
Teknoloji kararı bir tercih meselesi değil, bütçe ve bakım kararı. iOS tarafında Swift, Android tarafında Kotlin ile yerel geliştirme yapıldığında cihaz özelliklerine ve performansa en derin erişim sağlanıyor. Flutter ile tek kod tabanı üzerinden çalışıldığında iki platform aynı anda geliştiriliyor, bu da hem geliştirme süresini hem sonraki bakım yükünü düşürüyor.
Karar kuralı uygulamanın ne yaptığına bağlanıyor. Yoğun kamera işleme, artırılmış gerçeklik, arka planda sürekli konum takibi veya cihaz donanımına derin erişim gerekiyorsa yerel geliştirme öne çıkıyor. İş akışı, form, liste, panel ve entegrasyon ağırlıklı uygulamalarda tek kod tabanı hem takvimi hem toplam maliyeti kısaltıyor.
Arka uç tarafında Node.js, Firebase ve AWS yaygın kullanılan bileşenleri oluşturuyor. Web arayüzü veya yönetim paneli de gerekiyorsa React ve Next.js bu tarafa ekleniyor. Tasarım tarafında Figma, hem ekranların hem yeniden kullanılabilir bileşen kütüphanesinin ortak çalışma alanı oluyor.
Hizmet alırken ajansın bu kararı sizin adınıza gerekçelendirmesini istemeniz gerekiyor. Teknoloji seçimini yalnızca kendi ekibinin alışkanlığına dayandıran bir teklif, iki yıl sonra bakım maliyeti olarak size geri dönüyor.
Kendiniz mi yapmalısınız, hizmet mi almalısınız?
Mobil uygulama yapma araçları son yıllarda ciddi biçimde gelişti. Kod yazmadan uygulama üreten platformlar, yapay zeka destekli kod üreticileri ve ücretsiz şablon siteleri artık gerçekten çalışan çıktılar veriyor. Bu yüzden hizmet almadan önce sorulması gereken soru, aracın yeterli olup olmadığı değil, sizin senaryonuzda nereye kadar yeterli olduğu.
Kod yazmadan çalışan platformlar üç durumda iş görüyor. Fikrinizi doğrulamak için basit bir prototip çıkarmak, tek yönlü bilgi sunan bir katalog veya etkinlik uygulaması yayınlamak ve iç ekibin kullanacağı küçük bir form aracı kurmak bu durumları oluşturuyor.
Aynı araçlar dört noktada duvara çarpıyor. Kurumsal sisteminize entegrasyon gerektiğinde platformun hazır bağlantıları yetmiyor, kullanıcı rolü ve yetki matrisi karmaşıklaştığında yönetilemez hale geliyor, veri işleme ve saklama üzerinde tam kontrol isteyen uyum gereklilikleri karşılanamıyor, kullanıcı sayısı büyüdüğünde performans ve maliyet öngörülemez biçimde artıyor. Bunlara ek olarak platform kapandığında veya fiyatlandırmasını değiştirdiğinde elinizde taşınabilir bir kod tabanı kalmıyor.
Yapay zeka ile mobil uygulama yapma tarafında durum biraz farklı işliyor. Kod üreten yapay zeka araçları deneyimli bir geliştiricinin hızını artırıyor, fakat mimari kararları, güvenlik gözden geçirmesini ve entegrasyon tasarımını üstlenmiyor. Kurumsal bir uygulamada eforun büyük bölümü zaten bu üç kalemde toplandığı için, üretilen kodun miktarı toplam takvimi tek başına kısaltmıyor.
Pratik karar kuralı şu şekilde işliyor. Uygulamanız mevcut kurumsal sistemlerinize bağlanacaksa, birden fazla kullanıcı rolü barındıracaksa veya kişisel veri işleyecekse profesyonel hizmet almak gerekiyor. Bu üçü yoksa bir platformla başlayıp doğrulama sonrası geliştirmeye geçmek bütçenizi koruyor.
Mobil uygulama ekibinde hangi roller yer alıyor?
Hizmet alırken teklifin arkasındaki ekibin bileşimini görmek, fiyatı anlamanın en pratik yolunu oluşturuyor. Tek bir geliştirici üzerinden yürüyen bir teklifle rollerin ayrı ayrı tanımlandığı bir teklif aynı işi anlatmıyor.
Kıdemli ürün veya teknik lider kapsamı yönetiyor, teknik kararları alıyor ve sizinle tek muhatap olarak çalışıyor.
UI ve UX tasarımcısı akışları kuruyor, ekranları üretiyor ve tasarım sistemini kalıcı hale getiriyor.
Mobil geliştiriciler iOS, Android ve Flutter tarafını yazıyor, cihaz uyumluluğunu ve performansı üstleniyor.
Arka uç mühendisi veriyi, iş kurallarını, kimlik doğrulamayı ve API uçlarını kuruyor.
Ön yüz geliştirici web paneli veya yönetim arayüzü gerektiğinde React ve Next.js tarafını yürütüyor.
Kalite güvence uzmanı cihaz matrisinde testi yürütüyor ve mağaza öncesi kontrolleri yapıyor.
Küçük kapsamlı projelerde bir kişi birden fazla rolü taşıyabiliyor ve bu durum sorun oluşturmuyor. Sorun, rollerin hiç tanımlanmamasından çıkıyor. Teklifte entegrasyon ve test işleri görünmüyorsa bu iki kalem kaybolmuyor, yalnızca fiyatlanmamış olarak duruyor ve proje ortasında ek kalem olarak geri geliyor.
Uzun soluklu ürünlerde ekip bileşimi sabit kalabiliyor. Aynı kişilerin projede devamlı çalıştığı bir modelde ürün bilgisi ekipte kalıyor, geliştirme hızı oturuyor ve yeni kişilerin adaptasyon süresi bütçeden düşmüyor.

İstanbul'da mobil uygulama geliştirme hizmeti veren firmalar
İstanbul'daki sağlayıcılar üç farklı modelde çalışıyor ve doğru seçim, projenizin hangi modele ihtiyaç duyduğunu belirlemekten geçiyor.
Ürün ekipleri uygulamayı uçtan uca sahipleniyor. Tasarımdan yayın sonrası büyümeye kadar sorumluluğu üstlenirler ve süreç boyunca tek muhatap olarak çalışırlar. Mobil uygulamasının sahipliğini tek bir ekibe devretmek isteyen şirketler bu modeli arıyor.
Neon Apps, bu modelde çalışan ve ana hizmet alanını mobil uygulama geliştirme oluşturan bir firma. İstanbul ve New York'ta faaliyet gösteriyor, 85 kişilik in-house ekiple çalışıyor, bugüne kadar 550 proje tamamladı ve yayına aldığı 500'ü aşkın uygulama toplamda 100 milyon kullanıcıya ulaştı.
Modelin pratikte ne anlama geldiği, ürün ekibi tanımının çoğu firmadaki karşılığından daha somut. Kick-off'tan itibaren aynı kıdemli proje yöneticisi ve aynı geliştirme ekibi projenin sonuna kadar sabit kalıyor, yani proje ilerledikçe muhatap değişmiyor ve bilgi kaybolmuyor. Tasarım süreci de klasik olarak önce tüm ekranların bitip sonra geliştirmenin başladığı akışı izlemiyor. Kick-off sonrası kısa bir tasarım dili sprintiyle erken onay alınıyor, ardından ekranlar teker teker üretilip onaylanıyor. Büyük kapsamlı işlerde fiyatlandırma tek bir toplam rakamla değil, ilk fazı MVP olarak sınırlayıp sonraki fazları kapsam netleştikçe ayrı kalem olarak fiyatlandıran bir modelle ilerliyor. Bu da bütçenin ikinci yılda planlanmamış bir kalemle karşılaşma riskini baştan kapatıyor.
iOS tarafında Swift, çoklu platformda Flutter kullanılıyor. Geliştirici hesabı, sertifikalar, imza anahtarları ve devir paketinin kimin adına duracağı baştan sözleşmeye yazılıyor, KVKK kapsamında veri işleyen taahhüdü de aynı şekilde netleştiriliyor. Müşteri portföyü sektör çeşitliliğini yansıtıyor. Tera Yatırım finans, TAV Havalimanları mobilite, Protein Ocean e-ticaret ve Onedio medya tarafında yer alıyor ve her biri farklı bir kapsam ile entegrasyon profilinde ilerledi. Keşif aşamasından mağaza yayınına kadar süreç tek ekiple yürütülüyor, yayın sonrasında uygulama büyütme ve gelirlendirme danışmanlığı da hizmet kapsamına dahil. Yani model yayına alıp bırakan değil, yayına alıp büyüten bir ürün ekibi mantığıyla çalışıyor.
Ürün ekibi modelinde çalışan ve belirli sektörlerde derinleşmiş firmalar da bulunuyor. Mobven mobil bankacılık ve dijital cüzdan senaryolarında, Applogist lojistik ve saha operasyonu ağırlıklı projelerde, Commencis ise bankacılık, sigorta ve havacılık gibi düzenlemeye tabi sektörlerde çok paydaşlı programlar yürütüyor. Projeniz bu sektörlerden birine giriyorsa niş uzmanlık avantaj sağlayabilir.
Kaynak sağlayıcıları kendi ürün ekibinizi büyütmeniz için mühendis kiralıyor. Bu modelde ürün yönetimi ve teslim sorumluluğu size kalıyor, yani ekibi yönlendirecek bir teknik lidere veya proje yöneticisine zaten sahip olmanız gerekiyor. OBSS binden fazla yazılım mühendisiyle, PiA dört yüzü aşkın ekip üyesiyle, Intertech ise finans sektörüne odaklanan geniş kadrosuyla bu tarafta çalışıyor. Kendi ekibiniz yoksa bu model, sahiplenecek bir muhatabınız olmadan yönetmeniz gereken bir yükün altına sokuyor sizi.
Ürün ve platform sağlayıcıları hazır çözümlerini mevcut sisteminize entegre ediyor. Etiya telekom operatörleri için iş destek sistemi platformu sunuyor, SESTEK ise konuşma tabanlı yapay zeka ürünleri geliştiriyor. Sıfırdan bir uygulama yazdırmak istiyorsanız bu kategori aradığınız hizmeti vermiyor. İhtiyacınız uçtan uca yeni bir ürün değil, mevcut bir sisteme nokta çözüm eklemekse doğru adrese bakıyorsunuz.
Yanlış modelle eşleşmek, bütçeyi ve takvimi en çok zorlayan hata olarak öne çıkıyor. Ürün ekibi beklerken kaynak sağlayıcısıyla anlaşan bir şirket, yönetmeyi planlamadığı bir ekibin altında kalıyor. Firmaların ayrıntılı karşılaştırması, ekip büyüklükleri ve hangi proje tipine uygun oldukları için İstanbul'da kurumsal mobil uygulama geliştirme firmaları yazımıza bakabilirsiniz.
Mağaza yayını ve uyum sorumluluğu kimde?
Hizmet satın alırken uyum konusunun kritik tarafı kuralların kendisi değil, sorumluluğun sözleşmede kime yazıldığı. Aynı gereklilik bir projede ajansın işi, başka bir projede müşterinin işi olarak tanımlanabiliyor. Bu ayrım baştan yapılmazsa iş yayın haftasında sahipsiz kalıyor.
Mağaza tarafında dört sorunun cevabı sözleşmede yer almalı. Geliştirici hesabı kimin adına açılıyor, sertifikalar ve imza anahtarları kimde duruyor, mağaza listeleme metinlerini kim hazırlıyor ve red gelmesi durumunda düzeltme kimin eforundan düşüyor. Gerekliliklerin kaynağını Apple'ın App Review Guidelines ve Google Play'in Developer Program Policy dokümanları oluşturuyor, ancak doküman kimin ne yapacağını söylemiyor. İyi tanımlanmış bir hizmette listeleme hazırlığı, gönderim desteği ve uyum kontrolleri kapsamın içinde duruyor.
Kişisel veri tarafında KVKK sizi veri sorumlusu, hizmet aldığınız ajansı ise veri işleyen konumuna yerleştiriyor. Aydınlatma metninin yazılması, saklama sürelerinin belirlenmesi ve alt işleyenlerin listelenmesi bu ayrıma göre paylaşılıyor. Hizmet sözleşmesinde veri işleyen taahhüdü bulunmuyorsa eksik, proje bittikten sonra hukuk biriminden geri geliyor.
Yayın sonrası: bakım, izleme ve büyüme
Uygulama yayına girdiğinde iş bitmiyor. Yayın sonrası dönem üç ayrı çalışma alanından oluşuyor ve bunların hangisinin hizmet kapsamında olduğunu baştan netleştirmek gerekiyor.
Bakım tarafı hata gidermeyi, performans iyileştirmeyi ve bağımlılık yönetimini kapsıyor. Sağlıklı bir bakım yaklaşımı hatayı gördüğü yerde yamamak yerine kök nedeni araştırıyor, etkilenen kullanıcı akışını yeniden düzenliyor. Performans tarafında yükleme süreleri, arka uç işlemleri, arayüz render süresi, önbellekleme ve API iletişimi ayrı ayrı ele alınıyor. Bağımlılık tarafında işletim sistemi güncellemeleri, çatı yazılım yükseltmeleri ve kütüphane değişiklikleri düzenli olarak takip ediliyor.
İzleme tarafı uygulamanın gerçek dünyadaki davranışını görünür kılıyor. Çökme ve hata takibi, performans izleme, kullanım ve davranış içgörüleri ile kritik durumlar için proaktif uyarılar bu alanı oluşturuyor. İzleme kurulmadığında sorunlar kullanıcı şikâyetiyle öğrenilmeye başlıyor, bu da en pahalı öğrenme biçimi.
Büyüme ve gelirlendirme tarafı kullanımı sürdürülebilir sonuca çeviriyor. Kullanıcı davranışı, ürün hunileri ve temel metrikler analiz edilerek kullanıcının nerede düştüğü, dönüşümü neyin sınırladığı ve hangi değişikliğin en yüksek etkiyi yaratacağı belirleniyor. Çalışma alanları arasında edinme kanalları ve maliyet kalemleri, ilk deneyim ve aktivasyon adımları, elde tutma ve terk oranları, ödeme duvarı performansı ile abonelik davranışı yer alıyor.
Abonelik modeliyle çalışan uygulamalarda ödeme duvarı tasarımı, fiyat kademeleri, deneme ve yükseltme akışları, kampanyalar ve abonelik sürdürme mekanizmaları doğrudan gelire dokunuyor. Bu kalemlerin hizmet kapsamında olup olmadığı, uygulamanın ikinci yılındaki gelirini belirliyor.
Hizmet alırken sormanız gereken sorular
Aşağıdaki sekiz soru hizmetin kapsamını ve teslim disiplinini ölçüyor. Hepsini aynı biçimde her adaya yöneltmeniz, gelen cevapları yan yana okunabilir hale getiriyor.
1. Yukarıdaki dokuz hizmet başlığından hangileri bu teklifin içinde, hangileri opsiyon olarak duruyor?
2. Kapsam dışı bıraktığınız işleri de yazılı olarak listeler misiniz?
3. Projeye atanacak ekibin rolleri ve kıdemleri sözleşmede tanımlanıyor mu?
4. Çalışan bir sürümü hangi sıklıkta görebiliyoruz ve ilerleme nasıl raporlanıyor?
5. Test hangi cihaz ve işletim sistemi matrisinde yürütülüyor?
6. Geliştirici hesabı, sertifikalar ve imza anahtarları kimin adına duruyor?
7. Analitik, izleme ve gelirlendirme kurulumu kapsama giriyor mu?
8. Devir paketinde kod, dokümantasyon ve altyapı erişimleri hangi biçimde teslim ediliyor?
Altıncı ve sekizinci sorular ileride ajans değiştirme ihtimalinizi doğrudan belirliyor. Bu ikisine yazılı cevap almadan sözleşme aşamasına geçmemeniz sizi koruyor.
Sıkça Sorulan Sorular
Mobil uygulama yaptırmak ne kadar sürer?
Mobil uygulama fiyatı neye göre belirleniyor?
Tek kod tabanı mı, yerel geliştirme mi seçilmeli?
Kod yazmadan mobil uygulama yapmak yeterli olur mu?
Neon Apps mobil uygulama geliştirme hizmeti kapsamında neler sunuyor?
İlham Almaya Devam Et
Yeni tasarım içgörüleri, makaleler ve kaynaklar doğrudan gelen kutunuza gelsin.
Neon Apps ekibinden hikayeler, içgörüler ve güncellemeleri doğrudan gelen kutunuza alın.
Son Bloglar
İlham Almaya Devam Et
Neon Apps ekibinden hikayeler, içgörüler ve güncellemeler doğrudan gelen kutunuza gelsin.
Bir projeniz mi var?
Bize Ulaşın
Bir projeniz mi var? Startup'lar ve küresel markalar için dünya standartlarında mobil ve web uygulamaları geliştiriyoruz.
Neon Apps, İstanbul ve New York ofislerinde 85 kişilik kendi ekibiyle mobil, web ve SaaS projeleri hayata geçiren bir ürün geliştirme şirketidir. Uzun vadeli bir çözüm ortağı olarak, markalar için ölçeklenebilir dijital ürünler üretiyoruz.

Clients
İstanbul Mobil Uygulama Geliştirme Hizmeti
İstanbul Mobil Uygulama Geliştirme Hizmeti
İstanbul'da mobil uygulama geliştirme hizmeti, keşif aşamasından mağaza yayınına ve sonrasındaki bakıma kadar uzanıyor. Bu rehber hizmetin kapsamını, sürecini ve fiyatı belirleyen değişkenleri açıklıyor.
İstanbul'da mobil uygulama geliştirme hizmeti, keşif aşamasından mağaza yayınına ve sonrasındaki bakıma kadar uzanıyor. Bu rehber hizmetin kapsamını, sürecini ve fiyatı belirleyen değişkenleri açıklıyor.
İstanbul'da mobil uygulama yaptırırken neye bakmalı?
Doğru hizmeti seçmek, teklifi okumadan önce neye bakacağınızı bilmekten geçiyor. Kapsamın nereye kadar uzandığı, sürecin hangi adımlardan oluştuğu ve fiyatı hangi kalemlerin oluşturduğu üç temel kontrol noktasını meydana getiriyor. Aşağıdaki bölümler bu üçünü sırayla ele alıyor ve sonunda teklif toplarken kullanabileceğiniz soru listesini veriyor.
Mobil uygulama geliştirme hizmeti neleri kapsıyor?
Mobil uygulama geliştirme hizmeti, bir fikrin App Store ve Google Play'de yayına girmesi ve yayından sonra yaşamaya devam etmesi için gereken tüm işleri kapsıyor. Yalnızca kod yazmaktan ibaret değil, çünkü teslim edilen şey bir dosya değil, çalışan ve bakımı sürdürülen bir ürün.
Uçtan uca bir hizmet paketi şu başlıklardan oluşuyor.
Planlama ve özellik tanımı, ürünün hedeflerini, kullanıcı davranışını ve hangi ekranın hangi işi yaptığını netleştiriyor. Bu aşamada kullanıcı akışları hazırlanıyor ve ilk sürümün kapsamı yazılı hale geliyor.
UI ve UX tasarımı, kullanıcı yolculuğu haritalarından düşük çözünürlüklü tel çerçevelere, oradan yüksek çözünürlüklü ekranlara ve tasarım sistemine uzanıyor. Çıktılar geliştiriciye hazır biçimde, düzenli Figma dosyaları ve yeniden kullanılabilir bileşen kütüphaneleri olarak teslim ediliyor.
Mobil geliştirme, iOS ve Android tarafında uygulamanın kendisini yazıyor. Temiz ve ölçeklenebilir mimari, performans için optimize edilmiş ekranlar, yerel depolama, önbellekleme ve çevrimdışı destek bu kalemin içinde yer alıyor.
Arka uç geliştirme, veriyi, iş kurallarını, kimlik doğrulamayı ve API uçlarını kuruyor. Rol bazlı erişim ve yetkilendirme de burada tanımlanıyor.
Entegrasyonlar, uygulamayı ödeme sistemlerine, abonelik altyapısına, analitik araçlarına, sosyal girişe, push bildirimlerine, üçüncü taraf API'lerine ve yapay zeka destekli servislere bağlıyor.
Kalite güvence, uygulamayı farklı cihaz ve ekran boyutlarında test ediyor, görsel tutarlılığı ve kararlı davranışı doğruluyor.
Mağaza yayını, listeleme hazırlığını, gönderim desteğini ve uyum kontrollerini kapsıyor.
Analitik ve gelirlendirme kurulumu, olay takibini, dönüşüm ölçümünü ve abonelik yapısını çalışır hale getiriyor.
Bakım ve destek, yayın sonrasında hata giderme, performans iyileştirme, bağımlılık yönetimi ve özellik güncellemelerini yürütüyor.
Teklif alırken bu dokuz başlığın hangilerinin kapsamda olduğunu tek tek sormanız gerekiyor. En sık yaşanan sorun, tekliflerin ilk beş kalemi içerip son dördünü dışarıda bırakması ve farkın proje bittikten sonra ortaya çıkmasıdır.
Kapsam sektöre göre de değişiyor. E-ticaret uygulamalarında ödeme altyapısı, sepet ve kampanya kurgusu eforun büyük bölümünü oluşturuyor. Sağlık ve wellness uygulamalarında kullanıcı verisinin işlenmesi ek uyum yükü getiriyor. Ulaşım ve mobilite platformlarında konum servisleri ile gerçek zamanlı veri öne çıkıyor. Bankacılık ve finans uygulamalarında ise kimlik doğrulama, güvenlik ve mevcut sistem entegrasyonu kapsamın merkezinde duruyor.

Mobil uygulama yaptırma süreci nasıl işliyor?
Mobil uygulama nasıl yapılır sorusunun kurumsal projelerdeki cevabı, her adımın kendi çıktısı olan bir süreçten geçiyor. Aşağıdaki tablo adımları ve o adım sonunda elinize geçen somut çıktıyı gösteriyor.
Adım | Elinize geçen çıktı |
Kick-off ve kapsam netleştirme | Hedef tanımı, ilk sürüm kapsamı, atanan sabit proje ekibi |
Tasarım dili sprinti ve onay | Kısa sürede hazırlanan renk, tipografi ve bileşen dili, ilk onay |
Ekran bazlı tasarım üretimi | Onaylanan tasarım diline göre ekran ekran teslim edilen arayüzler |
Mimari kurulumu ve geliştirme | Çalışan sürümler, API uçları, veri yapısı, projenin yazılım kurgusu |
Entegrasyonlar | Ödeme, abonelik, analitik, bildirim ve üçüncü taraf bağlantıları |
Kalite ve cihaz testi | Test raporu, düzeltilmiş hatalar, kararlı sürüm |
Mağaza listeleme ve gönderim | Yayınlanmış uygulama, mağaza metinleri, uyum kontrolleri |
Yayın sonrası izleme ve iyileştirme | Yayınlanmış proje ve ardından özellik güncellemeleri |
Takvim projeye göre belirleniyor ve tek bir standart süre bulunmuyor. Süreyi asıl belirleyen değişken ekran sayısı değil, bağlanılacak sistem sayısı ile bu sistemlerin dokümantasyon olgunluğu oluyor. Bu yüzden teklif aşamasında adım bazlı bir takvim istemeniz, size tek bir toplam süreden çok daha fazlasını söylüyor.
Süreç boyunca en sık kayma entegrasyon testlerinde yaşanıyor. Karşı tarafın test ortamı hazır değilse veya arayüzü belgelenmemişse ekip bekleme moduna giriyor. İkinci sık kayma nedeni onay döngüleri oluyor; tasarım ve kabul onaylarını verecek kişiler baştan isimlendirilmezse her adım sonunda birkaç günlük beklemeler birikiyor.
İyi işleyen bir süreçte ilerlemeyi düzenli olarak görüyorsunuz. Çalışan sürümlerin belirli aralıklarla paylaşılması, ilerlemenin sunumdan değil çalışan üründen okunmasını sağlıyor.
Mobil uygulama fiyatı nasıl belirleniyor?
Mobil uygulama geliştirmede herkese uyan tek bir yaklaşım bulunmuyor. Doğru geliştirme stratejisi ve dolayısıyla fiyat, ürünün karmaşıklığı, bütçe ve ölçeklenebilirlik gereksinimleri birlikte değerlendirilerek belirleniyor. Bu yüzden hazır bir fiyat listesi yerine projeye özel teklif çıkarılıyor.
Teklifin tutarını belirleyen şey ekran sayısı değil, aşağıdaki kararların toplamı oluyor.
Kapsamı belirleyen karar | Fiyata nasıl yansıyor |
Özellik seti ve ilk sürüm kapsamı | Özellik tanımı aşamasında ilk sürüme hangi akışların gireceği belirlenir; kapsam büyüdükçe geliştirme ve test eforu birlikte artar |
Ekip yapısı ve kıdem | Tek geliştirici ile roller ayrı tanımlanmış sabit bir ekip aynı işi anlatmaz; kıdemli proje yöneticisinin yanına tasarım, arka uç ve test rollerinin ayrı ayrı atanması efor ve fiyatı değiştirir |
Platform stratejisi | Swift ile yerel geliştirme maksimum performans ve derin cihaz erişimi sağlar, Flutter ile tek kod tabanı daha hızlı teslim ve tek bakım hattı sunar |
Arka uç ihtiyacı | Kimlik doğrulama, gerçek zamanlı veri ve bildirim altyapısı kurulacaksa arka uç ayrı bir geliştirme kalemi olur |
Entegrasyon listesi | Ödeme, abonelik, analitik, sosyal giriş, push bildirim ve üçüncü taraf API'lerin her biri ayrı bağlantı, test ve hata senaryosu getirir |
Tasarım derinliği | Tasarım dili sprintinden ekran bazlı üretime uzanan çıktı seti, ekran sayısından bağımsız bir efor kalemidir |
Faz yapısı | Kapsamlı işlerde ilk faz MVP olarak sınırlanıp ayrı fiyatlanabilir; sonraki fazlar kapsam netleştikçe ayrı kalem olarak eklenir |
Gelirlendirme kurulumu | Abonelik yapısı, ödeme duvarı ve deneme akışları tasarım ve geliştirme tarafında ayrı iş oluşturur |
Yayın sonrası kapsam | Bakım, izleme ve büyüme çalışmaları ilk teslimden sonra tekrar eden kalemlerdir |
Bu kararların hepsi keşif ve özellik tanımı aşamasında netleşiyor. Kapsam yazılı hale gelmeden çıkan bir fiyat, tahmin olmaktan öteye geçmiyor. Bu yüzden teklif almadan önce entegrasyon listesini ve kullanıcı rollerini çıkarmanız, gelen rakamın gerçekçiliğini doğrudan artırıyor.
Sağlıklı bir fiyatlandırma ilk günden itibaren öngörülebilir oluyor. Bütçenin nereye gittiğinin görünmesi, sürpriz kalem çıkmaması ve kapsam dışı bırakılan işlerin de yazılı olması aranması gereken standardı oluşturuyor. Teklifte hangi kalemin ne kadar tuttuğu görünmüyorsa, o teklif karşılaştırılabilir bir teklif sayılmıyor.
Yayın sonrası kalemleri ilk bütçeye dahil etmeniz gerekiyor. Bakım, izleme ve gelirlendirme çalışmalarının kapsamı sözleşmede tanımlanmadığında bu gider yok olmuyor, yalnızca birinci yıl görünmez kalıyor ve ikinci yıl planlanmamış bir harcama olarak masaya geliyor.


Hangi teknolojiyle geliştirilmeli?
Teknoloji kararı bir tercih meselesi değil, bütçe ve bakım kararı. iOS tarafında Swift, Android tarafında Kotlin ile yerel geliştirme yapıldığında cihaz özelliklerine ve performansa en derin erişim sağlanıyor. Flutter ile tek kod tabanı üzerinden çalışıldığında iki platform aynı anda geliştiriliyor, bu da hem geliştirme süresini hem sonraki bakım yükünü düşürüyor.
Karar kuralı uygulamanın ne yaptığına bağlanıyor. Yoğun kamera işleme, artırılmış gerçeklik, arka planda sürekli konum takibi veya cihaz donanımına derin erişim gerekiyorsa yerel geliştirme öne çıkıyor. İş akışı, form, liste, panel ve entegrasyon ağırlıklı uygulamalarda tek kod tabanı hem takvimi hem toplam maliyeti kısaltıyor.
Arka uç tarafında Node.js, Firebase ve AWS yaygın kullanılan bileşenleri oluşturuyor. Web arayüzü veya yönetim paneli de gerekiyorsa React ve Next.js bu tarafa ekleniyor. Tasarım tarafında Figma, hem ekranların hem yeniden kullanılabilir bileşen kütüphanesinin ortak çalışma alanı oluyor.
Hizmet alırken ajansın bu kararı sizin adınıza gerekçelendirmesini istemeniz gerekiyor. Teknoloji seçimini yalnızca kendi ekibinin alışkanlığına dayandıran bir teklif, iki yıl sonra bakım maliyeti olarak size geri dönüyor.
Kendiniz mi yapmalısınız, hizmet mi almalısınız?
Mobil uygulama yapma araçları son yıllarda ciddi biçimde gelişti. Kod yazmadan uygulama üreten platformlar, yapay zeka destekli kod üreticileri ve ücretsiz şablon siteleri artık gerçekten çalışan çıktılar veriyor. Bu yüzden hizmet almadan önce sorulması gereken soru, aracın yeterli olup olmadığı değil, sizin senaryonuzda nereye kadar yeterli olduğu.
Kod yazmadan çalışan platformlar üç durumda iş görüyor. Fikrinizi doğrulamak için basit bir prototip çıkarmak, tek yönlü bilgi sunan bir katalog veya etkinlik uygulaması yayınlamak ve iç ekibin kullanacağı küçük bir form aracı kurmak bu durumları oluşturuyor.
Aynı araçlar dört noktada duvara çarpıyor. Kurumsal sisteminize entegrasyon gerektiğinde platformun hazır bağlantıları yetmiyor, kullanıcı rolü ve yetki matrisi karmaşıklaştığında yönetilemez hale geliyor, veri işleme ve saklama üzerinde tam kontrol isteyen uyum gereklilikleri karşılanamıyor, kullanıcı sayısı büyüdüğünde performans ve maliyet öngörülemez biçimde artıyor. Bunlara ek olarak platform kapandığında veya fiyatlandırmasını değiştirdiğinde elinizde taşınabilir bir kod tabanı kalmıyor.
Yapay zeka ile mobil uygulama yapma tarafında durum biraz farklı işliyor. Kod üreten yapay zeka araçları deneyimli bir geliştiricinin hızını artırıyor, fakat mimari kararları, güvenlik gözden geçirmesini ve entegrasyon tasarımını üstlenmiyor. Kurumsal bir uygulamada eforun büyük bölümü zaten bu üç kalemde toplandığı için, üretilen kodun miktarı toplam takvimi tek başına kısaltmıyor.
Pratik karar kuralı şu şekilde işliyor. Uygulamanız mevcut kurumsal sistemlerinize bağlanacaksa, birden fazla kullanıcı rolü barındıracaksa veya kişisel veri işleyecekse profesyonel hizmet almak gerekiyor. Bu üçü yoksa bir platformla başlayıp doğrulama sonrası geliştirmeye geçmek bütçenizi koruyor.
Mobil uygulama ekibinde hangi roller yer alıyor?
Hizmet alırken teklifin arkasındaki ekibin bileşimini görmek, fiyatı anlamanın en pratik yolunu oluşturuyor. Tek bir geliştirici üzerinden yürüyen bir teklifle rollerin ayrı ayrı tanımlandığı bir teklif aynı işi anlatmıyor.
Kıdemli ürün veya teknik lider kapsamı yönetiyor, teknik kararları alıyor ve sizinle tek muhatap olarak çalışıyor.
UI ve UX tasarımcısı akışları kuruyor, ekranları üretiyor ve tasarım sistemini kalıcı hale getiriyor.
Mobil geliştiriciler iOS, Android ve Flutter tarafını yazıyor, cihaz uyumluluğunu ve performansı üstleniyor.
Arka uç mühendisi veriyi, iş kurallarını, kimlik doğrulamayı ve API uçlarını kuruyor.
Ön yüz geliştirici web paneli veya yönetim arayüzü gerektiğinde React ve Next.js tarafını yürütüyor.
Kalite güvence uzmanı cihaz matrisinde testi yürütüyor ve mağaza öncesi kontrolleri yapıyor.
Küçük kapsamlı projelerde bir kişi birden fazla rolü taşıyabiliyor ve bu durum sorun oluşturmuyor. Sorun, rollerin hiç tanımlanmamasından çıkıyor. Teklifte entegrasyon ve test işleri görünmüyorsa bu iki kalem kaybolmuyor, yalnızca fiyatlanmamış olarak duruyor ve proje ortasında ek kalem olarak geri geliyor.
Uzun soluklu ürünlerde ekip bileşimi sabit kalabiliyor. Aynı kişilerin projede devamlı çalıştığı bir modelde ürün bilgisi ekipte kalıyor, geliştirme hızı oturuyor ve yeni kişilerin adaptasyon süresi bütçeden düşmüyor.

İstanbul'da mobil uygulama geliştirme hizmeti veren firmalar
İstanbul'daki sağlayıcılar üç farklı modelde çalışıyor ve doğru seçim, projenizin hangi modele ihtiyaç duyduğunu belirlemekten geçiyor.
Ürün ekipleri uygulamayı uçtan uca sahipleniyor. Tasarımdan yayın sonrası büyümeye kadar sorumluluğu üstlenirler ve süreç boyunca tek muhatap olarak çalışırlar. Mobil uygulamasının sahipliğini tek bir ekibe devretmek isteyen şirketler bu modeli arıyor.
Neon Apps, bu modelde çalışan ve ana hizmet alanını mobil uygulama geliştirme oluşturan bir firma. İstanbul ve New York'ta faaliyet gösteriyor, 85 kişilik in-house ekiple çalışıyor, bugüne kadar 550 proje tamamladı ve yayına aldığı 500'ü aşkın uygulama toplamda 100 milyon kullanıcıya ulaştı.
Modelin pratikte ne anlama geldiği, ürün ekibi tanımının çoğu firmadaki karşılığından daha somut. Kick-off'tan itibaren aynı kıdemli proje yöneticisi ve aynı geliştirme ekibi projenin sonuna kadar sabit kalıyor, yani proje ilerledikçe muhatap değişmiyor ve bilgi kaybolmuyor. Tasarım süreci de klasik olarak önce tüm ekranların bitip sonra geliştirmenin başladığı akışı izlemiyor. Kick-off sonrası kısa bir tasarım dili sprintiyle erken onay alınıyor, ardından ekranlar teker teker üretilip onaylanıyor. Büyük kapsamlı işlerde fiyatlandırma tek bir toplam rakamla değil, ilk fazı MVP olarak sınırlayıp sonraki fazları kapsam netleştikçe ayrı kalem olarak fiyatlandıran bir modelle ilerliyor. Bu da bütçenin ikinci yılda planlanmamış bir kalemle karşılaşma riskini baştan kapatıyor.
iOS tarafında Swift, çoklu platformda Flutter kullanılıyor. Geliştirici hesabı, sertifikalar, imza anahtarları ve devir paketinin kimin adına duracağı baştan sözleşmeye yazılıyor, KVKK kapsamında veri işleyen taahhüdü de aynı şekilde netleştiriliyor. Müşteri portföyü sektör çeşitliliğini yansıtıyor. Tera Yatırım finans, TAV Havalimanları mobilite, Protein Ocean e-ticaret ve Onedio medya tarafında yer alıyor ve her biri farklı bir kapsam ile entegrasyon profilinde ilerledi. Keşif aşamasından mağaza yayınına kadar süreç tek ekiple yürütülüyor, yayın sonrasında uygulama büyütme ve gelirlendirme danışmanlığı da hizmet kapsamına dahil. Yani model yayına alıp bırakan değil, yayına alıp büyüten bir ürün ekibi mantığıyla çalışıyor.
Ürün ekibi modelinde çalışan ve belirli sektörlerde derinleşmiş firmalar da bulunuyor. Mobven mobil bankacılık ve dijital cüzdan senaryolarında, Applogist lojistik ve saha operasyonu ağırlıklı projelerde, Commencis ise bankacılık, sigorta ve havacılık gibi düzenlemeye tabi sektörlerde çok paydaşlı programlar yürütüyor. Projeniz bu sektörlerden birine giriyorsa niş uzmanlık avantaj sağlayabilir.
Kaynak sağlayıcıları kendi ürün ekibinizi büyütmeniz için mühendis kiralıyor. Bu modelde ürün yönetimi ve teslim sorumluluğu size kalıyor, yani ekibi yönlendirecek bir teknik lidere veya proje yöneticisine zaten sahip olmanız gerekiyor. OBSS binden fazla yazılım mühendisiyle, PiA dört yüzü aşkın ekip üyesiyle, Intertech ise finans sektörüne odaklanan geniş kadrosuyla bu tarafta çalışıyor. Kendi ekibiniz yoksa bu model, sahiplenecek bir muhatabınız olmadan yönetmeniz gereken bir yükün altına sokuyor sizi.
Ürün ve platform sağlayıcıları hazır çözümlerini mevcut sisteminize entegre ediyor. Etiya telekom operatörleri için iş destek sistemi platformu sunuyor, SESTEK ise konuşma tabanlı yapay zeka ürünleri geliştiriyor. Sıfırdan bir uygulama yazdırmak istiyorsanız bu kategori aradığınız hizmeti vermiyor. İhtiyacınız uçtan uca yeni bir ürün değil, mevcut bir sisteme nokta çözüm eklemekse doğru adrese bakıyorsunuz.
Yanlış modelle eşleşmek, bütçeyi ve takvimi en çok zorlayan hata olarak öne çıkıyor. Ürün ekibi beklerken kaynak sağlayıcısıyla anlaşan bir şirket, yönetmeyi planlamadığı bir ekibin altında kalıyor. Firmaların ayrıntılı karşılaştırması, ekip büyüklükleri ve hangi proje tipine uygun oldukları için İstanbul'da kurumsal mobil uygulama geliştirme firmaları yazımıza bakabilirsiniz.
Mağaza yayını ve uyum sorumluluğu kimde?
Hizmet satın alırken uyum konusunun kritik tarafı kuralların kendisi değil, sorumluluğun sözleşmede kime yazıldığı. Aynı gereklilik bir projede ajansın işi, başka bir projede müşterinin işi olarak tanımlanabiliyor. Bu ayrım baştan yapılmazsa iş yayın haftasında sahipsiz kalıyor.
Mağaza tarafında dört sorunun cevabı sözleşmede yer almalı. Geliştirici hesabı kimin adına açılıyor, sertifikalar ve imza anahtarları kimde duruyor, mağaza listeleme metinlerini kim hazırlıyor ve red gelmesi durumunda düzeltme kimin eforundan düşüyor. Gerekliliklerin kaynağını Apple'ın App Review Guidelines ve Google Play'in Developer Program Policy dokümanları oluşturuyor, ancak doküman kimin ne yapacağını söylemiyor. İyi tanımlanmış bir hizmette listeleme hazırlığı, gönderim desteği ve uyum kontrolleri kapsamın içinde duruyor.
Kişisel veri tarafında KVKK sizi veri sorumlusu, hizmet aldığınız ajansı ise veri işleyen konumuna yerleştiriyor. Aydınlatma metninin yazılması, saklama sürelerinin belirlenmesi ve alt işleyenlerin listelenmesi bu ayrıma göre paylaşılıyor. Hizmet sözleşmesinde veri işleyen taahhüdü bulunmuyorsa eksik, proje bittikten sonra hukuk biriminden geri geliyor.
Yayın sonrası: bakım, izleme ve büyüme
Uygulama yayına girdiğinde iş bitmiyor. Yayın sonrası dönem üç ayrı çalışma alanından oluşuyor ve bunların hangisinin hizmet kapsamında olduğunu baştan netleştirmek gerekiyor.
Bakım tarafı hata gidermeyi, performans iyileştirmeyi ve bağımlılık yönetimini kapsıyor. Sağlıklı bir bakım yaklaşımı hatayı gördüğü yerde yamamak yerine kök nedeni araştırıyor, etkilenen kullanıcı akışını yeniden düzenliyor. Performans tarafında yükleme süreleri, arka uç işlemleri, arayüz render süresi, önbellekleme ve API iletişimi ayrı ayrı ele alınıyor. Bağımlılık tarafında işletim sistemi güncellemeleri, çatı yazılım yükseltmeleri ve kütüphane değişiklikleri düzenli olarak takip ediliyor.
İzleme tarafı uygulamanın gerçek dünyadaki davranışını görünür kılıyor. Çökme ve hata takibi, performans izleme, kullanım ve davranış içgörüleri ile kritik durumlar için proaktif uyarılar bu alanı oluşturuyor. İzleme kurulmadığında sorunlar kullanıcı şikâyetiyle öğrenilmeye başlıyor, bu da en pahalı öğrenme biçimi.
Büyüme ve gelirlendirme tarafı kullanımı sürdürülebilir sonuca çeviriyor. Kullanıcı davranışı, ürün hunileri ve temel metrikler analiz edilerek kullanıcının nerede düştüğü, dönüşümü neyin sınırladığı ve hangi değişikliğin en yüksek etkiyi yaratacağı belirleniyor. Çalışma alanları arasında edinme kanalları ve maliyet kalemleri, ilk deneyim ve aktivasyon adımları, elde tutma ve terk oranları, ödeme duvarı performansı ile abonelik davranışı yer alıyor.
Abonelik modeliyle çalışan uygulamalarda ödeme duvarı tasarımı, fiyat kademeleri, deneme ve yükseltme akışları, kampanyalar ve abonelik sürdürme mekanizmaları doğrudan gelire dokunuyor. Bu kalemlerin hizmet kapsamında olup olmadığı, uygulamanın ikinci yılındaki gelirini belirliyor.
Hizmet alırken sormanız gereken sorular
Aşağıdaki sekiz soru hizmetin kapsamını ve teslim disiplinini ölçüyor. Hepsini aynı biçimde her adaya yöneltmeniz, gelen cevapları yan yana okunabilir hale getiriyor.
1. Yukarıdaki dokuz hizmet başlığından hangileri bu teklifin içinde, hangileri opsiyon olarak duruyor?
2. Kapsam dışı bıraktığınız işleri de yazılı olarak listeler misiniz?
3. Projeye atanacak ekibin rolleri ve kıdemleri sözleşmede tanımlanıyor mu?
4. Çalışan bir sürümü hangi sıklıkta görebiliyoruz ve ilerleme nasıl raporlanıyor?
5. Test hangi cihaz ve işletim sistemi matrisinde yürütülüyor?
6. Geliştirici hesabı, sertifikalar ve imza anahtarları kimin adına duruyor?
7. Analitik, izleme ve gelirlendirme kurulumu kapsama giriyor mu?
8. Devir paketinde kod, dokümantasyon ve altyapı erişimleri hangi biçimde teslim ediliyor?
Altıncı ve sekizinci sorular ileride ajans değiştirme ihtimalinizi doğrudan belirliyor. Bu ikisine yazılı cevap almadan sözleşme aşamasına geçmemeniz sizi koruyor.
Sıkça Sorulan Sorular
Mobil uygulama yaptırmak ne kadar sürer?
Mobil uygulama fiyatı neye göre belirleniyor?
Tek kod tabanı mı, yerel geliştirme mi seçilmeli?
Kod yazmadan mobil uygulama yapmak yeterli olur mu?
Neon Apps mobil uygulama geliştirme hizmeti kapsamında neler sunuyor?
İlham Almaya Devam Et
Yeni tasarım içgörüleri, makaleler ve kaynaklar doğrudan gelen kutunuza gelsin.
Neon Apps ekibinden hikayeler, içgörüler ve güncellemeleri doğrudan gelen kutunuza alın.
Son Bloglar
İlham Almaya Devam Et
Neon Apps ekibinden hikayeler, içgörüler ve güncellemeler doğrudan gelen kutunuza gelsin.
Bir projeniz mi var?
Bize Ulaşın
Bir projeniz mi var? Startup'lar ve küresel markalar için dünya standartlarında mobil ve web uygulamaları geliştiriyoruz.
Neon Apps, İstanbul ve New York ofislerinde 85 kişilik kendi ekibiyle mobil, web ve SaaS projeleri hayata geçiren bir ürün geliştirme şirketidir. Uzun vadeli bir çözüm ortağı olarak, markalar için ölçeklenebilir dijital ürünler üretiyoruz.

Clients
İstanbul Mobil Uygulama Geliştirme Hizmeti
İstanbul Mobil Uygulama Geliştirme Hizmeti
İstanbul'da mobil uygulama geliştirme hizmeti, keşif aşamasından mağaza yayınına ve sonrasındaki bakıma kadar uzanıyor. Bu rehber hizmetin kapsamını, sürecini ve fiyatı belirleyen değişkenleri açıklıyor.
İstanbul'da mobil uygulama geliştirme hizmeti, keşif aşamasından mağaza yayınına ve sonrasındaki bakıma kadar uzanıyor. Bu rehber hizmetin kapsamını, sürecini ve fiyatı belirleyen değişkenleri açıklıyor.
İstanbul'da mobil uygulama yaptırırken neye bakmalı?
Doğru hizmeti seçmek, teklifi okumadan önce neye bakacağınızı bilmekten geçiyor. Kapsamın nereye kadar uzandığı, sürecin hangi adımlardan oluştuğu ve fiyatı hangi kalemlerin oluşturduğu üç temel kontrol noktasını meydana getiriyor. Aşağıdaki bölümler bu üçünü sırayla ele alıyor ve sonunda teklif toplarken kullanabileceğiniz soru listesini veriyor.
Mobil uygulama geliştirme hizmeti neleri kapsıyor?
Mobil uygulama geliştirme hizmeti, bir fikrin App Store ve Google Play'de yayına girmesi ve yayından sonra yaşamaya devam etmesi için gereken tüm işleri kapsıyor. Yalnızca kod yazmaktan ibaret değil, çünkü teslim edilen şey bir dosya değil, çalışan ve bakımı sürdürülen bir ürün.
Uçtan uca bir hizmet paketi şu başlıklardan oluşuyor.
Planlama ve özellik tanımı, ürünün hedeflerini, kullanıcı davranışını ve hangi ekranın hangi işi yaptığını netleştiriyor. Bu aşamada kullanıcı akışları hazırlanıyor ve ilk sürümün kapsamı yazılı hale geliyor.
UI ve UX tasarımı, kullanıcı yolculuğu haritalarından düşük çözünürlüklü tel çerçevelere, oradan yüksek çözünürlüklü ekranlara ve tasarım sistemine uzanıyor. Çıktılar geliştiriciye hazır biçimde, düzenli Figma dosyaları ve yeniden kullanılabilir bileşen kütüphaneleri olarak teslim ediliyor.
Mobil geliştirme, iOS ve Android tarafında uygulamanın kendisini yazıyor. Temiz ve ölçeklenebilir mimari, performans için optimize edilmiş ekranlar, yerel depolama, önbellekleme ve çevrimdışı destek bu kalemin içinde yer alıyor.
Arka uç geliştirme, veriyi, iş kurallarını, kimlik doğrulamayı ve API uçlarını kuruyor. Rol bazlı erişim ve yetkilendirme de burada tanımlanıyor.
Entegrasyonlar, uygulamayı ödeme sistemlerine, abonelik altyapısına, analitik araçlarına, sosyal girişe, push bildirimlerine, üçüncü taraf API'lerine ve yapay zeka destekli servislere bağlıyor.
Kalite güvence, uygulamayı farklı cihaz ve ekran boyutlarında test ediyor, görsel tutarlılığı ve kararlı davranışı doğruluyor.
Mağaza yayını, listeleme hazırlığını, gönderim desteğini ve uyum kontrollerini kapsıyor.
Analitik ve gelirlendirme kurulumu, olay takibini, dönüşüm ölçümünü ve abonelik yapısını çalışır hale getiriyor.
Bakım ve destek, yayın sonrasında hata giderme, performans iyileştirme, bağımlılık yönetimi ve özellik güncellemelerini yürütüyor.
Teklif alırken bu dokuz başlığın hangilerinin kapsamda olduğunu tek tek sormanız gerekiyor. En sık yaşanan sorun, tekliflerin ilk beş kalemi içerip son dördünü dışarıda bırakması ve farkın proje bittikten sonra ortaya çıkmasıdır.
Kapsam sektöre göre de değişiyor. E-ticaret uygulamalarında ödeme altyapısı, sepet ve kampanya kurgusu eforun büyük bölümünü oluşturuyor. Sağlık ve wellness uygulamalarında kullanıcı verisinin işlenmesi ek uyum yükü getiriyor. Ulaşım ve mobilite platformlarında konum servisleri ile gerçek zamanlı veri öne çıkıyor. Bankacılık ve finans uygulamalarında ise kimlik doğrulama, güvenlik ve mevcut sistem entegrasyonu kapsamın merkezinde duruyor.

Mobil uygulama yaptırma süreci nasıl işliyor?
Mobil uygulama nasıl yapılır sorusunun kurumsal projelerdeki cevabı, her adımın kendi çıktısı olan bir süreçten geçiyor. Aşağıdaki tablo adımları ve o adım sonunda elinize geçen somut çıktıyı gösteriyor.
Adım | Elinize geçen çıktı |
Kick-off ve kapsam netleştirme | Hedef tanımı, ilk sürüm kapsamı, atanan sabit proje ekibi |
Tasarım dili sprinti ve onay | Kısa sürede hazırlanan renk, tipografi ve bileşen dili, ilk onay |
Ekran bazlı tasarım üretimi | Onaylanan tasarım diline göre ekran ekran teslim edilen arayüzler |
Mimari kurulumu ve geliştirme | Çalışan sürümler, API uçları, veri yapısı, projenin yazılım kurgusu |
Entegrasyonlar | Ödeme, abonelik, analitik, bildirim ve üçüncü taraf bağlantıları |
Kalite ve cihaz testi | Test raporu, düzeltilmiş hatalar, kararlı sürüm |
Mağaza listeleme ve gönderim | Yayınlanmış uygulama, mağaza metinleri, uyum kontrolleri |
Yayın sonrası izleme ve iyileştirme | Yayınlanmış proje ve ardından özellik güncellemeleri |
Takvim projeye göre belirleniyor ve tek bir standart süre bulunmuyor. Süreyi asıl belirleyen değişken ekran sayısı değil, bağlanılacak sistem sayısı ile bu sistemlerin dokümantasyon olgunluğu oluyor. Bu yüzden teklif aşamasında adım bazlı bir takvim istemeniz, size tek bir toplam süreden çok daha fazlasını söylüyor.
Süreç boyunca en sık kayma entegrasyon testlerinde yaşanıyor. Karşı tarafın test ortamı hazır değilse veya arayüzü belgelenmemişse ekip bekleme moduna giriyor. İkinci sık kayma nedeni onay döngüleri oluyor; tasarım ve kabul onaylarını verecek kişiler baştan isimlendirilmezse her adım sonunda birkaç günlük beklemeler birikiyor.
İyi işleyen bir süreçte ilerlemeyi düzenli olarak görüyorsunuz. Çalışan sürümlerin belirli aralıklarla paylaşılması, ilerlemenin sunumdan değil çalışan üründen okunmasını sağlıyor.
Mobil uygulama fiyatı nasıl belirleniyor?
Mobil uygulama geliştirmede herkese uyan tek bir yaklaşım bulunmuyor. Doğru geliştirme stratejisi ve dolayısıyla fiyat, ürünün karmaşıklığı, bütçe ve ölçeklenebilirlik gereksinimleri birlikte değerlendirilerek belirleniyor. Bu yüzden hazır bir fiyat listesi yerine projeye özel teklif çıkarılıyor.
Teklifin tutarını belirleyen şey ekran sayısı değil, aşağıdaki kararların toplamı oluyor.
Kapsamı belirleyen karar | Fiyata nasıl yansıyor |
Özellik seti ve ilk sürüm kapsamı | Özellik tanımı aşamasında ilk sürüme hangi akışların gireceği belirlenir; kapsam büyüdükçe geliştirme ve test eforu birlikte artar |
Ekip yapısı ve kıdem | Tek geliştirici ile roller ayrı tanımlanmış sabit bir ekip aynı işi anlatmaz; kıdemli proje yöneticisinin yanına tasarım, arka uç ve test rollerinin ayrı ayrı atanması efor ve fiyatı değiştirir |
Platform stratejisi | Swift ile yerel geliştirme maksimum performans ve derin cihaz erişimi sağlar, Flutter ile tek kod tabanı daha hızlı teslim ve tek bakım hattı sunar |
Arka uç ihtiyacı | Kimlik doğrulama, gerçek zamanlı veri ve bildirim altyapısı kurulacaksa arka uç ayrı bir geliştirme kalemi olur |
Entegrasyon listesi | Ödeme, abonelik, analitik, sosyal giriş, push bildirim ve üçüncü taraf API'lerin her biri ayrı bağlantı, test ve hata senaryosu getirir |
Tasarım derinliği | Tasarım dili sprintinden ekran bazlı üretime uzanan çıktı seti, ekran sayısından bağımsız bir efor kalemidir |
Faz yapısı | Kapsamlı işlerde ilk faz MVP olarak sınırlanıp ayrı fiyatlanabilir; sonraki fazlar kapsam netleştikçe ayrı kalem olarak eklenir |
Gelirlendirme kurulumu | Abonelik yapısı, ödeme duvarı ve deneme akışları tasarım ve geliştirme tarafında ayrı iş oluşturur |
Yayın sonrası kapsam | Bakım, izleme ve büyüme çalışmaları ilk teslimden sonra tekrar eden kalemlerdir |
Bu kararların hepsi keşif ve özellik tanımı aşamasında netleşiyor. Kapsam yazılı hale gelmeden çıkan bir fiyat, tahmin olmaktan öteye geçmiyor. Bu yüzden teklif almadan önce entegrasyon listesini ve kullanıcı rollerini çıkarmanız, gelen rakamın gerçekçiliğini doğrudan artırıyor.
Sağlıklı bir fiyatlandırma ilk günden itibaren öngörülebilir oluyor. Bütçenin nereye gittiğinin görünmesi, sürpriz kalem çıkmaması ve kapsam dışı bırakılan işlerin de yazılı olması aranması gereken standardı oluşturuyor. Teklifte hangi kalemin ne kadar tuttuğu görünmüyorsa, o teklif karşılaştırılabilir bir teklif sayılmıyor.
Yayın sonrası kalemleri ilk bütçeye dahil etmeniz gerekiyor. Bakım, izleme ve gelirlendirme çalışmalarının kapsamı sözleşmede tanımlanmadığında bu gider yok olmuyor, yalnızca birinci yıl görünmez kalıyor ve ikinci yıl planlanmamış bir harcama olarak masaya geliyor.


Hangi teknolojiyle geliştirilmeli?
Teknoloji kararı bir tercih meselesi değil, bütçe ve bakım kararı. iOS tarafında Swift, Android tarafında Kotlin ile yerel geliştirme yapıldığında cihaz özelliklerine ve performansa en derin erişim sağlanıyor. Flutter ile tek kod tabanı üzerinden çalışıldığında iki platform aynı anda geliştiriliyor, bu da hem geliştirme süresini hem sonraki bakım yükünü düşürüyor.
Karar kuralı uygulamanın ne yaptığına bağlanıyor. Yoğun kamera işleme, artırılmış gerçeklik, arka planda sürekli konum takibi veya cihaz donanımına derin erişim gerekiyorsa yerel geliştirme öne çıkıyor. İş akışı, form, liste, panel ve entegrasyon ağırlıklı uygulamalarda tek kod tabanı hem takvimi hem toplam maliyeti kısaltıyor.
Arka uç tarafında Node.js, Firebase ve AWS yaygın kullanılan bileşenleri oluşturuyor. Web arayüzü veya yönetim paneli de gerekiyorsa React ve Next.js bu tarafa ekleniyor. Tasarım tarafında Figma, hem ekranların hem yeniden kullanılabilir bileşen kütüphanesinin ortak çalışma alanı oluyor.
Hizmet alırken ajansın bu kararı sizin adınıza gerekçelendirmesini istemeniz gerekiyor. Teknoloji seçimini yalnızca kendi ekibinin alışkanlığına dayandıran bir teklif, iki yıl sonra bakım maliyeti olarak size geri dönüyor.
Kendiniz mi yapmalısınız, hizmet mi almalısınız?
Mobil uygulama yapma araçları son yıllarda ciddi biçimde gelişti. Kod yazmadan uygulama üreten platformlar, yapay zeka destekli kod üreticileri ve ücretsiz şablon siteleri artık gerçekten çalışan çıktılar veriyor. Bu yüzden hizmet almadan önce sorulması gereken soru, aracın yeterli olup olmadığı değil, sizin senaryonuzda nereye kadar yeterli olduğu.
Kod yazmadan çalışan platformlar üç durumda iş görüyor. Fikrinizi doğrulamak için basit bir prototip çıkarmak, tek yönlü bilgi sunan bir katalog veya etkinlik uygulaması yayınlamak ve iç ekibin kullanacağı küçük bir form aracı kurmak bu durumları oluşturuyor.
Aynı araçlar dört noktada duvara çarpıyor. Kurumsal sisteminize entegrasyon gerektiğinde platformun hazır bağlantıları yetmiyor, kullanıcı rolü ve yetki matrisi karmaşıklaştığında yönetilemez hale geliyor, veri işleme ve saklama üzerinde tam kontrol isteyen uyum gereklilikleri karşılanamıyor, kullanıcı sayısı büyüdüğünde performans ve maliyet öngörülemez biçimde artıyor. Bunlara ek olarak platform kapandığında veya fiyatlandırmasını değiştirdiğinde elinizde taşınabilir bir kod tabanı kalmıyor.
Yapay zeka ile mobil uygulama yapma tarafında durum biraz farklı işliyor. Kod üreten yapay zeka araçları deneyimli bir geliştiricinin hızını artırıyor, fakat mimari kararları, güvenlik gözden geçirmesini ve entegrasyon tasarımını üstlenmiyor. Kurumsal bir uygulamada eforun büyük bölümü zaten bu üç kalemde toplandığı için, üretilen kodun miktarı toplam takvimi tek başına kısaltmıyor.
Pratik karar kuralı şu şekilde işliyor. Uygulamanız mevcut kurumsal sistemlerinize bağlanacaksa, birden fazla kullanıcı rolü barındıracaksa veya kişisel veri işleyecekse profesyonel hizmet almak gerekiyor. Bu üçü yoksa bir platformla başlayıp doğrulama sonrası geliştirmeye geçmek bütçenizi koruyor.
Mobil uygulama ekibinde hangi roller yer alıyor?
Hizmet alırken teklifin arkasındaki ekibin bileşimini görmek, fiyatı anlamanın en pratik yolunu oluşturuyor. Tek bir geliştirici üzerinden yürüyen bir teklifle rollerin ayrı ayrı tanımlandığı bir teklif aynı işi anlatmıyor.
Kıdemli ürün veya teknik lider kapsamı yönetiyor, teknik kararları alıyor ve sizinle tek muhatap olarak çalışıyor.
UI ve UX tasarımcısı akışları kuruyor, ekranları üretiyor ve tasarım sistemini kalıcı hale getiriyor.
Mobil geliştiriciler iOS, Android ve Flutter tarafını yazıyor, cihaz uyumluluğunu ve performansı üstleniyor.
Arka uç mühendisi veriyi, iş kurallarını, kimlik doğrulamayı ve API uçlarını kuruyor.
Ön yüz geliştirici web paneli veya yönetim arayüzü gerektiğinde React ve Next.js tarafını yürütüyor.
Kalite güvence uzmanı cihaz matrisinde testi yürütüyor ve mağaza öncesi kontrolleri yapıyor.
Küçük kapsamlı projelerde bir kişi birden fazla rolü taşıyabiliyor ve bu durum sorun oluşturmuyor. Sorun, rollerin hiç tanımlanmamasından çıkıyor. Teklifte entegrasyon ve test işleri görünmüyorsa bu iki kalem kaybolmuyor, yalnızca fiyatlanmamış olarak duruyor ve proje ortasında ek kalem olarak geri geliyor.
Uzun soluklu ürünlerde ekip bileşimi sabit kalabiliyor. Aynı kişilerin projede devamlı çalıştığı bir modelde ürün bilgisi ekipte kalıyor, geliştirme hızı oturuyor ve yeni kişilerin adaptasyon süresi bütçeden düşmüyor.

İstanbul'da mobil uygulama geliştirme hizmeti veren firmalar
İstanbul'daki sağlayıcılar üç farklı modelde çalışıyor ve doğru seçim, projenizin hangi modele ihtiyaç duyduğunu belirlemekten geçiyor.
Ürün ekipleri uygulamayı uçtan uca sahipleniyor. Tasarımdan yayın sonrası büyümeye kadar sorumluluğu üstlenirler ve süreç boyunca tek muhatap olarak çalışırlar. Mobil uygulamasının sahipliğini tek bir ekibe devretmek isteyen şirketler bu modeli arıyor.
Neon Apps, bu modelde çalışan ve ana hizmet alanını mobil uygulama geliştirme oluşturan bir firma. İstanbul ve New York'ta faaliyet gösteriyor, 85 kişilik in-house ekiple çalışıyor, bugüne kadar 550 proje tamamladı ve yayına aldığı 500'ü aşkın uygulama toplamda 100 milyon kullanıcıya ulaştı.
Modelin pratikte ne anlama geldiği, ürün ekibi tanımının çoğu firmadaki karşılığından daha somut. Kick-off'tan itibaren aynı kıdemli proje yöneticisi ve aynı geliştirme ekibi projenin sonuna kadar sabit kalıyor, yani proje ilerledikçe muhatap değişmiyor ve bilgi kaybolmuyor. Tasarım süreci de klasik olarak önce tüm ekranların bitip sonra geliştirmenin başladığı akışı izlemiyor. Kick-off sonrası kısa bir tasarım dili sprintiyle erken onay alınıyor, ardından ekranlar teker teker üretilip onaylanıyor. Büyük kapsamlı işlerde fiyatlandırma tek bir toplam rakamla değil, ilk fazı MVP olarak sınırlayıp sonraki fazları kapsam netleştikçe ayrı kalem olarak fiyatlandıran bir modelle ilerliyor. Bu da bütçenin ikinci yılda planlanmamış bir kalemle karşılaşma riskini baştan kapatıyor.
iOS tarafında Swift, çoklu platformda Flutter kullanılıyor. Geliştirici hesabı, sertifikalar, imza anahtarları ve devir paketinin kimin adına duracağı baştan sözleşmeye yazılıyor, KVKK kapsamında veri işleyen taahhüdü de aynı şekilde netleştiriliyor. Müşteri portföyü sektör çeşitliliğini yansıtıyor. Tera Yatırım finans, TAV Havalimanları mobilite, Protein Ocean e-ticaret ve Onedio medya tarafında yer alıyor ve her biri farklı bir kapsam ile entegrasyon profilinde ilerledi. Keşif aşamasından mağaza yayınına kadar süreç tek ekiple yürütülüyor, yayın sonrasında uygulama büyütme ve gelirlendirme danışmanlığı da hizmet kapsamına dahil. Yani model yayına alıp bırakan değil, yayına alıp büyüten bir ürün ekibi mantığıyla çalışıyor.
Ürün ekibi modelinde çalışan ve belirli sektörlerde derinleşmiş firmalar da bulunuyor. Mobven mobil bankacılık ve dijital cüzdan senaryolarında, Applogist lojistik ve saha operasyonu ağırlıklı projelerde, Commencis ise bankacılık, sigorta ve havacılık gibi düzenlemeye tabi sektörlerde çok paydaşlı programlar yürütüyor. Projeniz bu sektörlerden birine giriyorsa niş uzmanlık avantaj sağlayabilir.
Kaynak sağlayıcıları kendi ürün ekibinizi büyütmeniz için mühendis kiralıyor. Bu modelde ürün yönetimi ve teslim sorumluluğu size kalıyor, yani ekibi yönlendirecek bir teknik lidere veya proje yöneticisine zaten sahip olmanız gerekiyor. OBSS binden fazla yazılım mühendisiyle, PiA dört yüzü aşkın ekip üyesiyle, Intertech ise finans sektörüne odaklanan geniş kadrosuyla bu tarafta çalışıyor. Kendi ekibiniz yoksa bu model, sahiplenecek bir muhatabınız olmadan yönetmeniz gereken bir yükün altına sokuyor sizi.
Ürün ve platform sağlayıcıları hazır çözümlerini mevcut sisteminize entegre ediyor. Etiya telekom operatörleri için iş destek sistemi platformu sunuyor, SESTEK ise konuşma tabanlı yapay zeka ürünleri geliştiriyor. Sıfırdan bir uygulama yazdırmak istiyorsanız bu kategori aradığınız hizmeti vermiyor. İhtiyacınız uçtan uca yeni bir ürün değil, mevcut bir sisteme nokta çözüm eklemekse doğru adrese bakıyorsunuz.
Yanlış modelle eşleşmek, bütçeyi ve takvimi en çok zorlayan hata olarak öne çıkıyor. Ürün ekibi beklerken kaynak sağlayıcısıyla anlaşan bir şirket, yönetmeyi planlamadığı bir ekibin altında kalıyor. Firmaların ayrıntılı karşılaştırması, ekip büyüklükleri ve hangi proje tipine uygun oldukları için İstanbul'da kurumsal mobil uygulama geliştirme firmaları yazımıza bakabilirsiniz.
Mağaza yayını ve uyum sorumluluğu kimde?
Hizmet satın alırken uyum konusunun kritik tarafı kuralların kendisi değil, sorumluluğun sözleşmede kime yazıldığı. Aynı gereklilik bir projede ajansın işi, başka bir projede müşterinin işi olarak tanımlanabiliyor. Bu ayrım baştan yapılmazsa iş yayın haftasında sahipsiz kalıyor.
Mağaza tarafında dört sorunun cevabı sözleşmede yer almalı. Geliştirici hesabı kimin adına açılıyor, sertifikalar ve imza anahtarları kimde duruyor, mağaza listeleme metinlerini kim hazırlıyor ve red gelmesi durumunda düzeltme kimin eforundan düşüyor. Gerekliliklerin kaynağını Apple'ın App Review Guidelines ve Google Play'in Developer Program Policy dokümanları oluşturuyor, ancak doküman kimin ne yapacağını söylemiyor. İyi tanımlanmış bir hizmette listeleme hazırlığı, gönderim desteği ve uyum kontrolleri kapsamın içinde duruyor.
Kişisel veri tarafında KVKK sizi veri sorumlusu, hizmet aldığınız ajansı ise veri işleyen konumuna yerleştiriyor. Aydınlatma metninin yazılması, saklama sürelerinin belirlenmesi ve alt işleyenlerin listelenmesi bu ayrıma göre paylaşılıyor. Hizmet sözleşmesinde veri işleyen taahhüdü bulunmuyorsa eksik, proje bittikten sonra hukuk biriminden geri geliyor.
Yayın sonrası: bakım, izleme ve büyüme
Uygulama yayına girdiğinde iş bitmiyor. Yayın sonrası dönem üç ayrı çalışma alanından oluşuyor ve bunların hangisinin hizmet kapsamında olduğunu baştan netleştirmek gerekiyor.
Bakım tarafı hata gidermeyi, performans iyileştirmeyi ve bağımlılık yönetimini kapsıyor. Sağlıklı bir bakım yaklaşımı hatayı gördüğü yerde yamamak yerine kök nedeni araştırıyor, etkilenen kullanıcı akışını yeniden düzenliyor. Performans tarafında yükleme süreleri, arka uç işlemleri, arayüz render süresi, önbellekleme ve API iletişimi ayrı ayrı ele alınıyor. Bağımlılık tarafında işletim sistemi güncellemeleri, çatı yazılım yükseltmeleri ve kütüphane değişiklikleri düzenli olarak takip ediliyor.
İzleme tarafı uygulamanın gerçek dünyadaki davranışını görünür kılıyor. Çökme ve hata takibi, performans izleme, kullanım ve davranış içgörüleri ile kritik durumlar için proaktif uyarılar bu alanı oluşturuyor. İzleme kurulmadığında sorunlar kullanıcı şikâyetiyle öğrenilmeye başlıyor, bu da en pahalı öğrenme biçimi.
Büyüme ve gelirlendirme tarafı kullanımı sürdürülebilir sonuca çeviriyor. Kullanıcı davranışı, ürün hunileri ve temel metrikler analiz edilerek kullanıcının nerede düştüğü, dönüşümü neyin sınırladığı ve hangi değişikliğin en yüksek etkiyi yaratacağı belirleniyor. Çalışma alanları arasında edinme kanalları ve maliyet kalemleri, ilk deneyim ve aktivasyon adımları, elde tutma ve terk oranları, ödeme duvarı performansı ile abonelik davranışı yer alıyor.
Abonelik modeliyle çalışan uygulamalarda ödeme duvarı tasarımı, fiyat kademeleri, deneme ve yükseltme akışları, kampanyalar ve abonelik sürdürme mekanizmaları doğrudan gelire dokunuyor. Bu kalemlerin hizmet kapsamında olup olmadığı, uygulamanın ikinci yılındaki gelirini belirliyor.
Hizmet alırken sormanız gereken sorular
Aşağıdaki sekiz soru hizmetin kapsamını ve teslim disiplinini ölçüyor. Hepsini aynı biçimde her adaya yöneltmeniz, gelen cevapları yan yana okunabilir hale getiriyor.
1. Yukarıdaki dokuz hizmet başlığından hangileri bu teklifin içinde, hangileri opsiyon olarak duruyor?
2. Kapsam dışı bıraktığınız işleri de yazılı olarak listeler misiniz?
3. Projeye atanacak ekibin rolleri ve kıdemleri sözleşmede tanımlanıyor mu?
4. Çalışan bir sürümü hangi sıklıkta görebiliyoruz ve ilerleme nasıl raporlanıyor?
5. Test hangi cihaz ve işletim sistemi matrisinde yürütülüyor?
6. Geliştirici hesabı, sertifikalar ve imza anahtarları kimin adına duruyor?
7. Analitik, izleme ve gelirlendirme kurulumu kapsama giriyor mu?
8. Devir paketinde kod, dokümantasyon ve altyapı erişimleri hangi biçimde teslim ediliyor?
Altıncı ve sekizinci sorular ileride ajans değiştirme ihtimalinizi doğrudan belirliyor. Bu ikisine yazılı cevap almadan sözleşme aşamasına geçmemeniz sizi koruyor.
Sıkça Sorulan Sorular
Mobil uygulama yaptırmak ne kadar sürer?
Mobil uygulama fiyatı neye göre belirleniyor?
Tek kod tabanı mı, yerel geliştirme mi seçilmeli?
Kod yazmadan mobil uygulama yapmak yeterli olur mu?
Neon Apps mobil uygulama geliştirme hizmeti kapsamında neler sunuyor?
İlham Almaya Devam Et
Yeni tasarım içgörüleri, makaleler ve kaynaklar doğrudan gelen kutunuza gelsin.
Neon Apps ekibinden hikayeler, içgörüler ve güncellemeleri doğrudan gelen kutunuza alın.
Son Bloglar
İlham Almaya Devam Et
Neon Apps ekibinden hikayeler, içgörüler ve güncellemeler doğrudan gelen kutunuza gelsin.
Bir projeniz mi var?
Bize Ulaşın
Bir projeniz mi var? Startup'lar ve küresel markalar için dünya standartlarında mobil ve web uygulamaları geliştiriyoruz.
Neon Apps, İstanbul ve New York ofislerinde 85 kişilik kendi ekibiyle mobil, web ve SaaS projeleri hayata geçiren bir ürün geliştirme şirketidir. Uzun vadeli bir çözüm ortağı olarak, markalar için ölçeklenebilir dijital ürünler üretiyoruz.




