Mobil uygulama teknik şartname, bir uygulamanın “ne yapılacağını”, “nasıl çalışacağını”, “hangi sınırlar içinde teslim edileceğini” ve “başarı kriterlerinin nasıl ölçüleceğini” yazılı hale getiren proje dokümanıdır.
Bir mobil uygulama fikri ilk görüşmede genellikle basit görünür: üyelik olacak, kullanıcı ürün görecek, ödeme yapacak, bildirim gelecek, yönetim paneli olacak. Fakat gerçek geliştirme sürecinde fark yaratan şey, bu cümlelerin teknik karşılığının netleşmesidir.
Örneğin “bildirim gelsin” cümlesi tek başına yeterli değildir. Bildirim kimlere gidecek? Kullanıcı kapatabilecek mi? Segment bazlı mı olacak? Saat kısıtı var mı? iOS ve Android’de aynı davranış mı bekleniyor? Yönetim panelinden manuel gönderim yapılacak mı? Otomatik tetiklenen bildirimler olacak mı?
İyi hazırlanmış bir şartname, bu soruları proje başlamadan cevaplar. Bu sayede mobil uygulama geliştirme süreci daha kontrollü ilerler, teklif daha gerçekçi çıkar, teslim kapsamı tartışmaya açık kalmaz.
Türkiye’de mobil uygulama projeleri için bu ihtiyaç daha da belirgin hale geldi. DataReportal’ın 2026 Türkiye raporunda GSMA Intelligence verilerine göre Türkiye’de 2025 sonunda 81,9 milyon hücresel mobil bağlantı bulunuyor. Bu, mobil ürünlerin artık yalnızca “ek kanal” değil, işin ana temas noktalarından biri olduğunu gösteriyor. DataReportal Digital 2026 Turkey
Küresel ölçekte de tablo benzer. GSMA’nın 2026 Mobile Economy raporuna göre mobil teknolojiler ve hizmetler 2025’te küresel ekonomiye 7,6 trilyon dolar katkı sağladı. Bu büyüklük, mobil projelerde plansız ilerlemenin neden pahalıya mal olabileceğini net şekilde ortaya koyuyor. GSMA Mobile Economy 2026
Mobil uygulama teknik şartname; mobil uygulamanın ekranlarını, kullanıcı rollerini, özelliklerini, veri akışını, API ihtiyaçlarını, yönetim panelini, güvenlik gereksinimlerini, test kriterlerini, yayın sürecini ve bakım beklentilerini tanımlayan dokümandır.
Bu doküman yalnızca yazılımcı için hazırlanmaz. İş sahibi, ürün yöneticisi, tasarımcı, backend geliştirici, mobil geliştirici, test ekibi ve gerektiğinde hukuk/muhasebe ekibi aynı kapsamı okuyabilmelidir.
Bir şartname şu sorulara net cevap vermelidir:
Atalay Tech tarafında mobil uygulama, web platformu, yönetim paneli ve AI entegrasyonu içeren projelerde en sık gördüğümüz problem, şartnamenin özellik listesi gibi yazılmasıdır. “Login, profil, ödeme, bildirim” gibi maddeler gerçek kapsamı anlatmaz. Bu maddelerin her biri kendi içinde karar, ekran, iş kuralı, güvenlik ve test senaryosu gerektirir.
Bir yazılım projesinde fiyat, yalnızca ekran sayısına göre belirlenmez. Entegrasyon sayısı, veri yapısı, kullanıcı rolleri, offline çalışma ihtiyacı, güvenlik seviyesi, yönetim paneli kapsamı, tasarım detayları ve test yükü fiyatı ciddi şekilde değiştirir.
“Mobil uygulama yaptırmak istiyorum” diyen iki işletme aynı bütçeye ihtiyaç duymaz. Bir restoranın sadakat uygulaması ile doktor-hasta iletişimi, video içerik, ödeme ve randevu içeren bir sağlık uygulaması aynı kapsamda değildir.
Bu yüzden mobil uygulama yaptırmak isteyen işletmelerin ilk adımı, fikri satış cümlesinden çıkarıp teknik kapsam dokümanına dönüştürmek olmalıdır.
Teknik şartname olmadan alınan tekliflerde genellikle üç risk oluşur:
Doğru şartname, teklifin hem müşteri hem yazılım ekibi için adil olmasını sağlar.
Şartname, yalnızca fikir anlatımı değil; uygulanabilir teknik doküman olmalıdır. İyi bir mobil uygulama teknik şartname dokümanında aşağıdaki bölümler bulunmalıdır.
| Bölüm | Ne Anlatır? | Neden Gerekli? |
|---|---|---|
| Proje amacı | Uygulamanın çözdüğü ana problem | Kapsamın dağılmasını engeller |
| Kullanıcı rolleri | Müşteri, satıcı, admin, saha ekibi gibi roller | Yetki ve ekran ayrımını netleştirir |
| Ekran listesi | Giriş, profil, liste, detay, ödeme, panel ekranları | Tasarım ve geliştirme eforunu belirler |
| İş kuralları | Onay, iptal, iade, puan, limit, statü kuralları | Backend mantığını netleştirir |
| Entegrasyonlar | Ödeme, kargo, ERP, CRM, harita, SMS, e-posta | Maliyet ve riskleri belirler |
| Veri modeli | Kullanıcı, ürün, sipariş, mesaj, içerik gibi kayıtlar | Veritabanı ve API tasarımını yönlendirir |
| Güvenlik | KVKK, yetkilendirme, şifreleme, loglama | Hukuki ve operasyonel riski azaltır |
| Test kriterleri | Hangi senaryolar kabul edilecek? | Teslim kalitesini ölçülebilir yapar |
| Yayın süreci | App Store, Google Play, hesaplar, görseller | Mağaza reddi riskini azaltır |
| Bakım kapsamı | Hata, güncelleme, izleme, destek süresi | Yayın sonrası beklentiyi netleştirir |
Bu tablo, şartnamenin iskeletidir. Her projede tüm başlıklar aynı derinlikte olmayabilir; fakat mobil uygulama gibi çok parçalı ürünlerde bu başlıkların atlanması proje riskini büyütür.
Teknik şartname hazırlarken en güçlü yöntemlerden biri kullanıcı senaryosu yazmaktır. Çünkü kullanıcı senaryosu, soyut özellikleri gerçek akışa çevirir.
Örnek persona:
Ayşe, 28 yaşında freelance tasarımcı. Yoğun çalıştığı için hizmet aldığı platformlardan hızlı teklif almak, ödeme durumunu takip etmek ve bildirimlerle süreci kaçırmamak istiyor.
Bu persona üzerinden bir mobil uygulama akışı şöyle yazılabilir:
Bu senaryo tek başına bile birçok teknik kararı ortaya çıkarır. OTP doğrulama var mı? Form dinamik mi? Teklif PDF olarak üretilecek mi? Kullanıcı teklif geçmişini görecek mi? Yönetim panelinde satış ekibinin yetkisi ne olacak?
Atalay Tech’in proje deneyimlerinde mobil uygulama, web paneli ve backend aynı anda düşünülmediğinde en çok revize çıkaran alan genellikle burasıdır. Mobil ekran güzel tasarlanır; fakat panelde o ekranı besleyecek içerik yönetimi eksik kalır. Bu nedenle şartname, yalnızca uygulama ekranlarını değil, uygulamayı yönetecek operasyonu da kapsamalıdır.
Mobil uygulama teknik şartname hazırlarken en kritik ayrım MVP ile kurumsal ürün arasındadır. MVP, fikrin pazarda test edilmesi için gereken minimum değerli üründür. Kurumsal kapsam ise daha fazla rol, entegrasyon, raporlama, güvenlik ve ölçeklenebilirlik içerir.
Aşağıdaki maliyetler Türkiye pazarı için 2026 yılına göre tahmini aralıklardır. Projenin sektörü, entegrasyon sayısı, tasarım kalitesi, backend mimarisi ve yayın sonrası destek ihtiyacı bu rakamları değiştirebilir.
| Kapsam Tipi | Tipik İçerik | Tahmini Süre | Tahmini Bütçe |
|---|---|---|---|
| MVP mobil uygulama | Üyelik, temel profil, 5-8 ekran, basit panel, temel bildirim | 4-8 hafta | 250.000 - 600.000 TL + KDV |
| Orta ölçek uygulama | Rol bazlı yapı, ödeme, API entegrasyonu, gelişmiş panel, raporlama | 8-14 hafta | 600.000 - 1.500.000 TL + KDV |
| Kurumsal mobil ürün | ERP/CRM entegrasyonu, çoklu rol, güvenlik katmanı, loglama, ölçeklenebilir altyapı | 12-24 hafta | 1.500.000 - 4.000.000 TL + KDV |
| Platform ürünü | Mobil uygulama, web paneli, çok taraflı pazar yeri, ödeme, sözleşme, AI/otomasyon | 16-32 hafta | 3.000.000 TL + KDV ve üzeri |
Bu tablo kesin fiyat listesi değildir. Ama şartname hazırlarken bütçe gerçekçiliğini kontrol etmek için iyi bir çerçeve sağlar. Daha net aralık görmek isteyen işletmeler, kapsamı kabaca belirledikten sonra mobil uygulama fiyatları aracını kullanarak ilk tahmini çıkarabilir.
Mobil uygulama teknik şartname hazırlama süreci, fikir yazmaktan daha disiplinli ilerlemelidir. Aşağıdaki sıra, hem ajansla çalışacak işletmeler hem de iç yazılım ekibi olan şirketler için uygulanabilir bir modeldir.
İlk bölümde uygulamanın neden yapılacağını yazın. Burada “modern bir mobil uygulama istiyoruz” gibi genel cümleler yerine ölçülebilir hedefler kullanılmalıdır.
Örnek hedefler:
Bu hedefler, özellik önceliği belirler. Örneğin hedef teklif süresini kısaltmaksa ilk sürümde gelişmiş sosyal özellikler yerine hızlı form, otomatik teklif mantığı ve bildirim akışı daha değerlidir.
Mobil uygulamalarda roller çoğu zaman başlangıçta hafife alınır. Oysa rol yapısı, hem ekranları hem API yetkilerini hem de panel mimarisini belirler.
Örnek roller:
Her rol için şu sorular cevaplanmalıdır:
Rol bazlı yetki tanımı yapılmazsa, proje sonunda güvenlik açığı veya operasyon karmaşası oluşabilir. Özellikle sağlık, finans, eğitim, lojistik ve B2B sipariş projelerinde bu ayrım şartnamede açık yazılmalıdır.
Şartnameye yalnızca ekran adları yazmak yeterli değildir. Her ekranın amacı, gösterdiği veri, kullanıcı aksiyonu ve hata durumları belirtilmelidir.
Örnek ekran tanımı:
| Ekran | Kullanıcı Aksiyonu | Backend İhtiyacı | Not |
|---|---|---|---|
| Giriş ekranı | E-posta/telefon ile giriş | Auth API, OTP veya şifre kontrolü | Hatalı giriş limiti olmalı |
| Profil ekranı | Bilgi görüntüleme ve düzenleme | Kullanıcı güncelleme API | Telefon değişirse tekrar doğrulama |
| Teklif formu | İhtiyaç seçimi ve açıklama gönderme | Talep oluşturma API | Dosya yükleme opsiyonel |
| Teklif detay | Fiyat, kapsam, durum görüntüleme | Teklif detay API | Onay/ret butonu olabilir |
| Bildirim merkezi | Geçmiş bildirimleri görme | Notification list API | Okundu bilgisi tutulmalı |
Bu tablo tasarım sürecini hızlandırır. Tasarımcı hangi ekranları çizeceğini bilir, backend geliştirici hangi verilerin döneceğini planlar, müşteri hangi davranışları beklediğini net görür.
Mobil uygulama projelerinde maliyeti en çok değiştiren başlıklardan biri entegrasyondur. Bir uygulama tek başına çalışmayabilir; ödeme, ERP, CRM, kargo, harita, SMS, e-posta, muhasebe veya yapay zekâ servislerine bağlanması gerekebilir.
Bu noktada API entegrasyonu ihtiyacı şartnamenin ayrı bir bölümü olmalıdır.
Entegrasyon bölümünde şunlar yazılmalıdır:
Örneğin bir B2B sipariş uygulamasında stok bilgisi ERP’den geliyorsa, “stok gösterilecek” demek yeterli değildir. Stok ne sıklıkta güncellenecek? Ürün sepete eklendikten sonra stok değişirse ne olacak? Sipariş ERP’ye düşmezse operasyon ekibine bildirim gidecek mi? Bunlar şartnameye yazılmalıdır.
Mobil uygulamanın arkasında genellikle bir yönetim paneli bulunur. İçerikler, kullanıcılar, siparişler, talepler, bildirimler, raporlar ve yetkiler bu panelden yönetilir.
Bu nedenle yönetim paneli geliştirme mobil proje şartnamesinin ayrılmaz parçasıdır.
Panel kapsamı genellikle şu modüllerden oluşur:
| Panel Modülü | Tipik İşlev | Şartnamede Netleşmesi Gereken Nokta |
|---|---|---|
| Kullanıcı yönetimi | Kullanıcı listeleme, pasife alma, rol verme | Admin hangi verileri düzenleyebilir? |
| İçerik yönetimi | Banner, duyuru, kategori, sayfa yönetimi | Yayın tarihi ve dil desteği olacak mı? |
| Sipariş/talep yönetimi | Durum değiştirme, not ekleme, filtreleme | Statü akışı nasıl çalışacak? |
| Bildirim yönetimi | Push, e-posta, SMS gönderimi | Segment ve zamanlama olacak mı? |
| Raporlama | Grafik, tablo, dışa aktarma | Hangi KPI’lar izlenecek? |
| Yetki yönetimi | Rol bazlı erişim | Her admin aynı yetkiye sahip mi? |
Şartname yalnızca mobil uygulamaya odaklanırsa, panel geliştirme sonradan “ek iş” gibi görünür. Oysa uygulamanın sürdürülebilir çalışması için panel çoğu zaman mobil ekranlar kadar önemlidir.
Mobil uygulama veri topluyorsa güvenlik bölümü şartnamede bulunmalıdır. Bu bölüm özellikle kullanıcı hesabı, ödeme, sağlık verisi, konum, mesajlaşma, belge yükleme veya kimlik doğrulama içeren projelerde kritik hale gelir.
Apple App Store Review Guidelines; güvenlik, performans, iş modeli, tasarım ve hukuki gereklilikleri ayrı başlıklar altında değerlendirir. Bu nedenle iOS yayını hedefleyen projelerde gizlilik, veri kullanımı ve izin ekranları şartnamede erken aşamada düşünülmelidir. Apple App Store Review Guidelines
Google tarafında da Android Developers kalite rehberi; performans, kararlılık, uyumluluk ve yanıt verme hızını temel kalite kriterleri arasında ele alır. Bu kriterler yalnızca teknik ekip için değil, şartname hazırlayan iş sahibi için de önemlidir. Android Core App Quality Guidelines
Güvenlik bölümünde şunlar yer almalıdır:
Bu bölüm, yalnızca teknik riskleri değil, marka güvenini de etkiler. Kullanıcının konum, belge veya ödeme bilgisi paylaştığı bir uygulamada güvenlik maddeleri belirsizse ürün yayına çıksa bile operasyonel risk devam eder.
Şartnamede en çok atlanan alanlardan biri kabul kriterleridir. “Uygulama çalışır durumda teslim edilecek” gibi bir ifade yeterli değildir. Hangi senaryolar çalışırsa teslim kabul edilecek, hangi hatalar kritik sayılacak, hangi cihazlarda test yapılacak net yazılmalıdır.
Örnek kabul kriterleri:
Bu kriterler, teslim toplantısında tartışmayı azaltır. İş sahibi “ben böyle beklemiyordum” demek yerine önceden yazılmış kabul senaryolarına göre kontrol yapar.
Teknik şartname, teknoloji seçimini de etkiler. Her proje native geliştirme gerektirmez; her proje no-code ile de sürdürülemez. Karar, bütçe, performans, ölçeklenme, mağaza gereksinimleri ve entegrasyon derinliğine göre verilmelidir.
| Seçenek | Uygun Olduğu Proje | Avantaj | Risk |
|---|---|---|---|
| No-code | Basit MVP, iç operasyon prototipi | Hızlı başlangıç, düşük ilk maliyet | Ölçek, özel entegrasyon ve performans sınırı |
| Cross-platform | iOS + Android hedefleyen çoğu ticari uygulama | Tek kod tabanı, hızlı geliştirme | Çok özel native özelliklerde ek çalışma |
| Native iOS/Android | Yüksek performans, cihaz donanımı, özel animasyon | Platforma özel maksimum kontrol | Daha yüksek bütçe ve iki ayrı geliştirme hattı |
| Web tabanlı PWA | Basit kullanıcı akışı, mağaza zorunlu değilse | Kurulum gerekmez, hızlı yayın | App Store/Play Store deneyimi ve cihaz özellikleri sınırlı |
Atalay Tech tarafında birçok ticari mobil projede cross-platform yaklaşım, özellikle iOS ve Android’in aynı anda hedeflendiği durumlarda verimli olabilir. Ancak ödeme, mesajlaşma, medya işleme, yoğun harita kullanımı veya cihaz donanımı gerektiren projelerde teknik karar şartnameye göre verilmelidir.
Bu karar yalnızca “hangi teknoloji daha iyi?” sorusu değildir. Daha doğru soru şudur: Bu ürünün ilk 12 ayda hangi kullanıcı yüküne, hangi entegrasyonlara ve hangi değişim hızına ihtiyacı var?
Şartname, proje sürecinin başlangıç dokümanıdır. Ancak tek başına yeterli değildir; keşif, tasarım, geliştirme, test, yayın ve bakım adımlarına bağlanmalıdır.
| Aşama | Şartnamedeki Karşılığı | Çıktı |
|---|---|---|
| Keşif | Amaç, kullanıcı rolleri, iş kuralları | Net kapsam dokümanı |
| Tasarım | Ekran listesi, kullanıcı akışları | UI/UX tasarımları |
| MVP geliştirme | Öncelikli özellikler | İlk çalışır sürüm |
| Backend/API | Veri modeli, entegrasyonlar | API ve panel altyapısı |
| Test | Kabul kriterleri, cihaz listesi | Hata listesi ve düzeltmeler |
| Yayın | Mağaza gereksinimleri, hesaplar | App Store ve Google Play yayını |
| Bakım | Destek kapsamı, izleme, güncelleme | Sürdürülebilir ürün yönetimi |
Bu bağ kurulduğunda şartname yaşayan bir proje referansına dönüşür. Her yeni özellik talebinde şu soru sorulur: Bu özellik MVP kapsamında mı, sonraki fazda mı, yoksa yeni teklif konusu mu?
Aşağıdaki yapı, mobil uygulama projesi için başlangıç şartnamesi hazırlarken kullanılabilir. Her başlık proje özelinde genişletilmelidir.
1. Proje Tanımı
2. Kullanıcı Rolleri
3. Mobil Uygulama Ekranları
4. Yönetim Paneli
5. Entegrasyonlar
6. Güvenlik ve KVKK
7. Test ve Teslim
Bu yapı, özel yazılım geliştirme projelerinde de kullanılabilir. Mobil uygulama, web platformu veya AI destekli sistem fark etmeksizin kapsam ne kadar netse geliştirme süreci o kadar kontrollü ilerler.
Mobil uygulama şartnamesinde sık görülen hatalar genellikle teknik bilgi eksikliğinden değil, kararların yazıya dökülmemesinden kaynaklanır.
En yaygın hatalar şunlardır:
Örneğin “ödeme alınacak” maddesi tek başına teknik kapsam değildir. Kart saklama olacak mı? Taksit olacak mı? İade süreci panelden mi yönetilecek? Başarısız ödeme tekrar denenebilecek mi? Fatura entegrasyonu var mı? Bu sorular cevaplanmadan ödeme modülü gerçek anlamda tanımlanmış sayılmaz.
Atalay Tech olarak mobil uygulama, web platformu, yönetim paneli, API entegrasyonu ve AI destekli yazılım projelerinde şartnameyi yalnızca teklif hazırlamak için kullanmıyoruz. İyi şartname, projenin risk haritasını da çıkarır.
Bir projede risk genellikle şu alanlarda yoğunlaşır:
Bu yüzden şartnameyi “ajansa verilecek doküman” olarak değil, iş modelini teknik dile çeviren bir ürün belgesi olarak görmek gerekir. Şartname ne kadar netse, teklif o kadar gerçekçi; proje planı o kadar ölçülebilir; teslim süreci o kadar sağlıklı olur.
Mobil uygulama teknik şartname için tek bir ideal sayfa sayısı yoktur. Basit bir MVP için 8-15 sayfalık net bir doküman yeterli olabilirken, ödeme, panel, ERP entegrasyonu, rol bazlı yetki ve raporlama içeren kurumsal projelerde 25-60 sayfalık daha detaylı bir doküman gerekebilir. Önemli olan sayfa sayısı değil, kararların açık yazılmasıdır. Örneğin 40 sayfalık ama belirsiz bir doküman, 12 sayfalık net bir şartnameden daha zayıf olabilir. Her ekran, rol, entegrasyon, veri akışı ve kabul kriteri somut şekilde tanımlanıyorsa doküman görevini yerine getirir.
En sağlıklı model ortak hazırlıktır. İş sahibi problemi, hedef kullanıcıyı, operasyon kurallarını ve ticari beklentiyi en iyi bilen taraftır. Yazılım ajansı ise bu beklentileri teknik mimariye, ekran akışına, API yapısına, veri modeline ve geliştirme planına dönüştürür. Müşteri yalnızca “şunu istiyorum” seviyesinde kalırsa kapsam eksik kalabilir. Ajans müşteriyi hiç dinlemeden teknik doküman hazırlarsa iş gerçekleri kaçabilir. Bu nedenle ilk taslak müşteri tarafından ihtiyaç dokümanı olarak hazırlanabilir, teknik şartname ise keşif görüşmeleriyle birlikte profesyonel ekip tarafından netleştirilmelidir.
Ön görüşme için kabaca fiyat aralığı alınabilir; fakat ciddi teklif için şartname gerekir. Şartname olmadan verilen fiyatlar çoğu zaman varsayıma dayanır. Bu da proje sırasında ek maliyet, süre uzaması veya kapsam anlaşmazlığı doğurabilir. Örneğin “kullanıcı mesajlaşması olacak” cümlesi; birebir mesaj, grup mesajı, medya gönderimi, okundu bilgisi, bildirim, moderasyon ve şikayet sistemi gibi birçok alt karara ayrılır. Bu kararlar yazılmadan verilen teklif ya eksik olur ya da belirsizlik payı nedeniyle gereğinden yüksek çıkar.
MVP şartnamesi, ürünün pazara çıkması veya fikrin doğrulanması için gereken minimum kapsamı tanımlar. Genellikle temel kullanıcı akışı, sınırlı ekran seti, basit yönetim paneli ve kritik özelliklere odaklanır. Kurumsal uygulama şartnamesi ise daha geniştir; rol bazlı yetki, çoklu departman kullanımı, ERP/CRM entegrasyonu, detaylı raporlama, loglama, güvenlik politikaları, performans hedefleri ve bakım süreçlerini içerir. MVP’de “hızlı doğrulama” öncelikliyken, kurumsal projede “sürdürülebilirlik, güvenlik ve ölçeklenebilirlik” daha baskındır. Bu nedenle iki şartname aynı formatı kullansa bile detay seviyesi farklıdır.
Şartnamede doğrudan nihai fiyat yazmak zorunlu değildir; fakat kapsamın bütçe seviyesine uygun olup olmadığı belirtilmelidir. Daha doğru yaklaşım, şartname içinde MVP, orta ölçek ve ileri faz ayrımı yapmaktır. Böylece yazılım ekibi hangi özelliklerin ilk teslimde, hangilerinin sonraki fazda olduğunu görür. Nihai fiyat genellikle şartnameye göre hazırlanan teklif dokümanında yer alır. Yine de iş sahibi kendi içinde bütçe bandı belirlemelidir. Örneğin 300.000 TL bütçeyle kurumsal ERP entegrasyonlu, ödeme sistemli, çok rollü bir platform beklemek gerçekçi değildir.
Evet, içermelidir. Mobil uygulama yalnızca geliştirilip cihazda çalıştırılınca tamamlanmış sayılmaz; App Store ve Google Play yayın süreci de planlanmalıdır. Şartnamede geliştirici hesaplarının kime ait olacağı, mağaza açıklamalarının kim tarafından hazırlanacağı, ekran görüntüleri, gizlilik politikası, hesap silme bağlantısı, test kullanıcıları ve inceleme süreci belirtilmelidir. Apple ve Google kalite, gizlilik ve performans kriterlerine dikkat eder. Bu gereksinimler proje sonunda düşünülürse yayın gecikebilir. Özellikle kullanıcı verisi, ödeme, sağlık, çocuklara yönelik içerik veya konum izni içeren uygulamalarda yayın maddeleri erken yazılmalıdır.
Çünkü mobil uygulamanın sürdürülebilir yönetimi çoğu zaman panel üzerinden yapılır. Kullanıcıları görmek, içerik eklemek, talepleri yönetmek, bildirim göndermek, rapor almak veya işlem geçmişini incelemek panel gerektirir. Şartnamede panel ayrı yazılmazsa müşteri paneli doğal olarak kapsamda varsayabilir, yazılım ekibi ise yalnızca mobil uygulamayı fiyatlamış olabilir. Bu durum proje ortasında anlaşmazlık yaratır. Panel modülleri, admin rolleri, filtreler, dışa aktarma seçenekleri, bildirim gönderimi ve raporlama ihtiyaçları baştan yazılırsa teklif ve süre daha doğru çıkar.
Evet, fakat değişiklik yönetimi net olmalıdır. Yazılım projelerinde fikirler geliştikçe yeni ihtiyaçlar çıkabilir. Buradaki kritik nokta, her değişikliğin aynı kapsam içinde varsayılmamasıdır. Şartnameye göre MVP kapsamı sabitlenir; sonradan gelen talepler “küçük revizyon”, “ek geliştirme” veya “sonraki faz” olarak sınıflandırılır. Örneğin buton metni değişikliği küçük revizyon olabilir; fakat yeni ödeme yöntemi, yeni kullanıcı rolü veya ERP entegrasyonu ek geliştirme sayılır. Bu ayrım yazılı olursa hem müşteri hem yazılım ekibi daha sağlıklı ilerler.
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
