Bir mobil uygulama projesinde sözleşme, yalnızca “taraflar anlaştı” belgesi değildir. Hangi ekranların yapılacağını, hangi API’lerin bağlanacağını, ödeme planının nasıl işleyeceğini, kaynak kodunun kimde kalacağını, yayın sonrası hataların nasıl ele alınacağını ve kullanıcı verisinin nasıl korunacağını belirleyen operasyonel bir haritadır.
Özellikle mobil uygulama geliştirme projelerinde sözlü mutabakat çok hızlı dağılır. İlk görüşmede “basit üyelik sistemi” gibi görünen bir özellik; SMS doğrulama, sosyal giriş, rol bazlı yetki, KVKK onayı, hesap silme, oturum güvenliği ve yönetim paneli gerektirdiğinde gerçek kapsam değişir.
Atalay Tech tarafında mobil uygulama, web platformu, yönetim paneli, ödeme sistemi, AI entegrasyonu ve teslim sonrası bakım içeren projelerde en sık gördüğümüz risk şudur: müşteri “uygulama yapılsın” der, geliştirici “MVP teslim ediyorum” diye düşünür, fakat sözleşmede MVP’nin sınırı yazmadığı için iki taraf farklı beklentiyle ilerler.
Bu yüzden mobil uygulama yaptırırken sözleşme, hukuk metni kadar teknik kapsam dokümanı gibi de düşünülmelidir. Hatta çoğu zaman iyi hazırlanmış bir kapsam eki, sözleşmenin en kritik parçasıdır.
Bu içerik hukuki danışmanlık yerine geçmez. Mobil uygulama sözleşmesi hazırlarken avukat, mali müşavir ve teknik ekip birlikte çalışmalıdır. Buradaki amaç, proje sahibi olarak hangi maddeleri sorgulamanız gerektiğini netleştirmektir.
Mobil uygulama projelerinde ürün fikri genellikle ilk toplantıda net görünür. Örneğin bir randevu uygulaması için “kullanıcı randevu alsın, işletme onaylasın, bildirim gitsin” denir. Fakat gerçek projede kullanıcı kayıt akışı, işletme paneli, iptal politikası, ödeme alma, takvim çakışması, push bildirim, log kayıtları ve destek süreçleri devreye girer.
Sözleşme bu belirsizlikleri azaltır. Şu sorulara yazılı cevap verir:
Örneğin sağlık, finans, eğitim, üyelik veya pazaryeri uygulaması yaptıran bir işletme için sözleşmede veri güvenliği, loglama, erişim yetkileri ve bakım süreci çok daha kritik hale gelir. Çünkü proje sadece ekran geliştirmekten ibaret değildir; veri, ödeme, kullanıcı güveni ve operasyon sürekliliği de işin parçasıdır.
Mobil uygulama yatırımı yapmadan önce daha geniş karar sürecini görmek isteyen işletmeler için mobil uygulama yaptırmak sayfası, proje yaklaşımı ve doğru hazırlık başlıklarını ayrıca açıklar.
Mobil uygulama sözleşmesinin tek tip bir şablonu yoktur. Bir restoran sipariş uygulaması ile B2B bayi sipariş uygulamasının riski aynı değildir. Yine de her projede yer alması gereken temel maddeler vardır.
Aşağıdaki tablo, sözleşmede bulunması gereken maddeleri ve neden kritik olduklarını özetler.
| Sözleşme Maddesi | Neyi Netleştirir? | Eksik Olursa Ne Olur? |
|---|---|---|
| Proje kapsamı | Ekranlar, modüller, entegrasyonlar | “Bu da dahil değil miydi?” tartışması çıkar |
| Teslim takvimi | Milestone, sprint, yayın hedefi | Süre beklentisi belirsiz kalır |
| Ödeme planı | Peşinat, ara ödeme, teslim ödemesi | Nakit akışı ve iş durdurma koşulları karışır |
| Fikri mülkiyet | Kaynak kodu, tasarım, lisans hakları | Kodun kime ait olduğu tartışılır |
| Revizyon sınırı | Kaç revizyon dahil? | Sonsuz değişiklik döngüsü oluşur |
| Test ve kabul | Hangi kriterle teslim kabul edilir? | Teslimat sürekli ertelenir |
| KVKK ve veri güvenliği | Kullanıcı verisi, rol, log, yedek | Hukuki ve operasyonel risk artar |
| Bakım ve destek | Hata, güncelleme, SLA, ücret | Yayın sonrası sorumluluk belirsizleşir |
| Fesih ve gecikme | Taraflar ayrılırsa ne olur? | Yarım kalan proje için hak kaybı doğar |
Bu maddelerin her biri kısa yazılabilir; fakat muğlak yazılmamalıdır. “Uygulama geliştirilecektir” ifadesi yeterli değildir. “iOS ve Android mobil uygulama, Laravel tabanlı API, yönetim paneli, üyelik, profil, bildirim ve ödeme entegrasyonu geliştirilecektir” gibi kapsamı somutlaştıran ifadeler kullanılmalıdır.
Sözleşmenin en önemli bölümü proje kapsamıdır. Çünkü anlaşmazlıkların çoğu fiyat veya süre nedeniyle değil, kapsamın farklı anlaşılması nedeniyle çıkar.
Kapsam maddesi şu parçaları ayırmalıdır:
Örneğin “pazaryeri mobil uygulaması” ifadesi tek başına yeterli değildir. Pazaryeri; satıcı paneli, ürün yönetimi, komisyon yapısı, ödeme ayrıştırma, iade akışı, kargo entegrasyonu, bildirim sistemi, yorum/moderasyon ve anlaşmazlık yönetimi içerebilir. Bunların hangisi ilk sürümde yapılacak, hangisi sonraki fazda kalacak net yazılmalıdır.
Sözleşmeye bağlı bir “Teknik Kapsam Ek’i” oluşturmak çok sağlıklıdır. Bu ek, hukuk dilinden daha pratik bir proje dokümanı gibi davranır.
Örnek modül kırılımı şöyle olabilir:
| Modül | İlk Sürümde Var mı? | Not |
|---|---|---|
| Kullanıcı kaydı | Evet | E-posta veya telefon doğrulama belirtilmeli |
| Sosyal giriş | Opsiyonel | Apple/Google hesabı ayrıca yazılmalı |
| Profil yönetimi | Evet | Fotoğraf, ad, telefon, il/ilçe alanları |
| Push bildirim | Evet | Firebase/Apple tarafı dahil edilmeli |
| Ödeme sistemi | Projeye bağlı | Sanal POS, cüzdan veya abonelik ayrı yazılmalı |
| Yönetim paneli | Evet | Kullanıcı, içerik, bildirim yönetimi |
| AI özelliği | Opsiyonel | Model, kullanım limiti ve maliyet belirtilmeli |
| Çoklu dil | Opsiyonel | TR/EN gibi diller tek tek yazılmalı |
Bu yaklaşım özellikle MVP projelerinde önemlidir. Bir girişimci ilk sürümde pazarı test etmek istiyorsa her özelliği sözleşmeye koymak maliyeti artırır. Bir kurumsal şirket ise ERP entegrasyonu, kullanıcı rolleri ve raporlama gibi başlıkları ilk sürümden istemek zorunda kalabilir.
Her mobil uygulama sözleşmesi aynı detay seviyesine ihtiyaç duymaz. MVP bir ürün için karar hızı ve kapsam kontrolü öne çıkarken, kurumsal projelerde entegrasyon, güvenlik, bakım ve SLA maddeleri daha detaylı olmalıdır.
Aşağıdaki maliyet aralıkları 2026 Türkiye piyasası için tahmini proje ölçeklerini gösterir. Gerçek fiyat; ekran sayısı, entegrasyon sayısı, tasarım seviyesi, API karmaşıklığı, güvenlik ihtiyacı ve teslim takvimine göre değişir. Daha net bir ön değerlendirme için mobil uygulama fiyatları aracını kullanabilirsiniz.
| Proje Tipi | Tahmini Kapsam | Tahmini Süre | Tahmini Maliyet |
|---|---|---|---|
| MVP mobil uygulama | 8-15 ekran, temel API, admin panel | 4-8 hafta | 200.000 - 600.000 TL + KDV |
| Orta ölçek uygulama | 15-35 ekran, ödeme, bildirim, raporlama | 8-16 hafta | 600.000 - 1.500.000 TL + KDV |
| Kurumsal uygulama | ERP/CRM entegrasyonu, rol sistemi, yüksek güvenlik | 3-6 ay | 1.500.000 - 5.000.000 TL+ + KDV |
| AI destekli uygulama | Mobil + backend + AI akışı + kullanım limiti | 2-5 ay | 900.000 - 4.000.000 TL+ + KDV |
MVP sözleşmesinde “ilk sürümde olmayanlar” özellikle yazılmalıdır. Örneğin “uygulama içi mesajlaşma, canlı destek, abonelik sistemi ve gelişmiş raporlama ilk faz kapsamına dahil değildir” gibi negatif kapsam maddeleri, sonradan çıkacak tartışmaları azaltır.
Kurumsal projede ise entegrasyon sorumluluğu ayrılmalıdır. ERP veya muhasebe yazılımı API erişimi müşteri tarafından sağlanacaksa, sözleşmede “entegrasyon için gerekli API dokümantasyonu, test hesabı ve yetkilendirme bilgileri müşteri tarafından sağlanır” maddesi bulunmalıdır.
Mobil uygulama yaptırırken en çok atlanan maddelerden biri fikri mülkiyettir. Proje sonunda müşteri uygulamayı kullanabilir ama kaynak kodun tüm mali hakları devredildi mi? Tasarım dosyaları teslim edilecek mi? Ajansın daha önce geliştirdiği altyapı bileşenleri projeye dahil mi? Bunlar sözleşmede ayrılmalıdır.
Türkiye’de yazılım ve bilgisayar programları, şartları oluştuğunda Fikir ve Sanat Eserleri Kanunu kapsamında korunabilir. Kanunda mali hakların birbirinden bağımsız olduğu ve her hakkın ayrı ayrı tasarrufa konu olabileceği kabul edilir. Bu nedenle “uygulama yapıldı, her şey müşteriye geçti” varsayımı risklidir. Kaynak: 5846 sayılı Fikir ve Sanat Eserleri Kanunu.
Sözleşmede şu ayrımlar yazılmalıdır:
Atalay Tech perspektifinde doğru model şudur: müşteriye proje kapsamında ihtiyaç duyduğu kullanım, yayınlama ve geliştirmeye devam etme hakları açıkça tanımlanır; ajansın genel amaçlı altyapı bilgisi, know-how’ı ve tekrar kullanılabilir bileşenleri ise ayrıca değerlendirilir. Bu ayrım hem müşteriyi hem geliştirici ekibi korur.
Mobil uygulama projeleri tek günde teslim edilen işler değildir. Bu yüzden ödeme planı, proje takvimiyle uyumlu olmalıdır. Peşinat, ara ödeme ve teslim öncesi ödeme kalemleri net yazılmadığında hem müşteri hem ajans zor durumda kalır.
Yaygın ödeme modelleri şunlardır:
| Ödeme Modeli | Ne Zaman Mantıklı? | Risk |
|---|---|---|
| %40 / %30 / %30 | MVP ve orta ölçek projeler | Kapsam büyürse ara ödeme yetmeyebilir |
| %30 / %40 / %30 | Tasarım ve geliştirme ağırlıklı işler | İlk fazda nakit planı zayıf kalabilir |
| Aylık milestone | 3 ay+ kurumsal projeler | Milestone kabul kriteri net olmalı |
| Saatlik/faz bazlı | Kapsam belirsiz projeler | Bütçe üst limiti ayrıca yazılmalı |
| Bakım aboneliği | Yayın sonrası destek | SLA ve kapsam net olmazsa tartışma çıkar |
Sözleşmede ödeme gecikmesi için makul bir prosedür bulunmalıdır. Örneğin “vadesi geçen ödeme 7 iş günü içinde yapılmazsa geliştirme çalışmaları geçici olarak durdurulabilir” gibi bir madde, tarafların beklentisini netleştirir. Burada amaç müşteriyi sıkıştırmak değil, proje kaynak planını korumaktır.
Ayrıca KDV, stopaj, banka masrafı, döviz kuru, taksit tarihi ve fatura kesim zamanı açık yazılmalıdır. “200.000 TL proje bedeli” ile “200.000 TL + KDV proje bedeli” arasında ciddi fark vardır.
Sözleşmede sadece “proje 8 haftada teslim edilir” yazmak çoğu zaman yeterli değildir. Çünkü teslim süresi yalnızca yazılım ekibinin hızına bağlı değildir. Müşteri içerikleri, marka materyallerini, mağaza hesaplarını, API bilgilerini, test geri bildirimlerini ve ödeme entegrasyonu belgelerini zamanında sağlamazsa takvim etkilenir.
Bu nedenle takvim milestone bazlı yazılmalıdır:
| Faz | Örnek Süre | Teslimat |
|---|---|---|
| Keşif ve kapsam | 3-7 gün | Kapsam dokümanı, kullanıcı akışları |
| UI/UX tasarım | 1-3 hafta | Ana ekran tasarımları, prototip |
| Backend/API | 2-6 hafta | API, veritabanı, admin panel |
| Mobil geliştirme | 4-10 hafta | iOS/Android uygulama sürümü |
| Test ve düzeltme | 1-3 hafta | Hata listesi, test build |
| Mağaza yayını | 3-14 gün | App Store / Google Play gönderimi |
| Bakım | 1-12 ay | Hata desteği, güncelleme takibi |
Kabul kriterleri de teknik olarak ölçülebilir olmalıdır. Örneğin “uygulama düzgün çalışacaktır” yerine “kapsam ekinde belirtilen kullanıcı kayıt, profil, bildirim, ödeme ve yönetim paneli akışları test ortamında çalışır şekilde teslim edilir” ifadesi daha sağlıklıdır.
Müşteri geri bildirimi için de süre yazılmalıdır. Örneğin “test sürümü gönderildikten sonra müşteri 5 iş günü içinde geri bildirim iletir; bu süre içinde geri bildirim gelmezse ilgili faz kabul edilmiş sayılır” gibi bir madde, projenin sonsuz bekleme döngüsüne girmesini engeller.
Mobil uygulama projelerinde değişiklik kaçınılmazdır. İlk prototip görüldüğünde yeni fikirler çıkar. Test aşamasında kullanıcı deneyimi iyileştirmeleri fark edilir. Bazen iş modeli değişir ve uygulamaya yeni rol, yeni ödeme akışı veya yeni rapor istenir.
Problem değişiklik istemek değildir; problem değişikliğin sözleşmede nasıl yönetileceğinin yazılmamasıdır.
Sözleşmede şu ayrımlar net olmalıdır:
Örneğin müşteri ilk kapsamda “randevu sistemi” istemiş olsun. Sonra “randevuya kapora alınsın, iptal süresine göre otomatik iade yapılsın, işletme panelinde komisyon raporu gözüksün” dediğinde bu artık basit revizyon değil, yeni iş kuralıdır. Sözleşme bu farkı tanımlamalıdır.
Atalay Tech’in proje yaklaşımında kapsam değişiklikleri genellikle ayrı teklif, ek faz veya sonraki sprint olarak ele alınır. Bu model hem ürünü kilitlemez hem de ilk sürümün gereksiz büyümesini engeller.
Mobil uygulama kullanıcı verisi topluyorsa sözleşmede KVKK, gizlilik ve güvenlik başlıkları mutlaka bulunmalıdır. Kullanıcı adı, telefon, e-posta, konum, sağlık bilgisi, finansal bilgi, cihaz bilgisi veya mesaj içerikleri işleniyorsa risk seviyesi artar.
Kişisel Verileri Koruma Kurumu, veri sorumlusu ve veri işleyen ayrımını açıklar. Genel olarak veri işleme amaçlarını ve vasıtalarını belirleyen taraf veri sorumlusu; veri sorumlusunun verdiği yetkiye dayanarak veri işleyen taraf ise veri işleyen konumunda olabilir. Kaynak: KVKK - Veri Sorumlusu ve Veri İşleyen.
Mobil uygulama sözleşmesinde şu maddeler özellikle değerlendirilmelidir:
| Güvenlik Başlığı | Sözleşmede Ne Yazılmalı? | Örnek Risk |
|---|---|---|
| Veri rolleri | Veri sorumlusu / veri işleyen ayrımı | KVKK sorumluluğu belirsiz kalır |
| Erişim yetkileri | Admin, editör, destek rolleri | Gereksiz veri erişimi oluşur |
| Log kayıtları | Hangi işlem ne kadar tutulur? | Olay sonrası iz sürülemez |
| Şifreleme | HTTPS, token, parola hash | Hesap güvenliği zayıflar |
| Yedekleme | Frekans, saklama, geri dönüş | Veri kaybı yaşanabilir |
| Hesap silme | Kullanıcı talebi nasıl işlenir? | Mağaza ve KVKK uyumu bozulur |
| Üçüncü taraf servis | Firebase, ödeme, analitik | Veri aktarımı belirsiz kalır |
Ayrıca App Store ve Google Play süreçlerinde gizlilik beyanı, hesap silme, veri toplama açıklamaları ve uygulama izinleri önemlidir. Apple Developer Program License Agreement, geliştiricilerin Apple yazılımları ve servislerini belirli şartlarla kullanmasına izin verir; Google Play Developer Distribution Agreement ise Google Play üzerinden ürün dağıtımına ilişkin bağlayıcı şartları tanımlar. Kaynaklar: Apple Developer Program License Agreement ve Google Play Developer Distribution Agreement.
Bu yüzden sözleşmede “mağaza politikalarına uyum için gerekli metinler, izin açıklamaları ve gizlilik politikası müşteri tarafından sağlanır; teknik yerleştirme geliştirici tarafından yapılır” gibi bir ayrım yapılabilir. Hukuki metinleri yazılım ekibinin tek başına hazırlaması doğru değildir.
Mobil uygulama yayın süreci sözleşmede ayrı bir başlık olmalıdır. Çünkü uygulamanın kod olarak hazır olması, App Store veya Google Play’de kesin yayınlanacağı anlamına gelmez. Mağazalar uygulamayı inceleyebilir, ek bilgi isteyebilir veya revizyon talep edebilir.
Sözleşmede şu sorular cevaplanmalıdır:
Özellikle markaya ait uygulamalarda mağaza hesabının müşteri adına olması daha sağlıklıdır. Böylece uygulamanın uzun vadeli sahipliği, ödeme bilgileri, geliştirici hesabı doğrulaması ve marka kontrolü müşteride kalır. Ajans ise teknik geliştirici veya yetkili kullanıcı olarak sürece dahil olabilir.
Mobil uygulama yayınlandıktan sonra iş bitmez. iOS ve Android işletim sistemleri güncellenir, kütüphaneler değişir, cihaz davranışları farklılaşır, mağaza politikaları yenilenir, kullanıcılar hata bildirir ve yeni ihtiyaçlar doğar.
Bu yüzden sözleşmede teknik destek ve bakım maddesi ayrı yazılmalıdır. Bakım kapsamı “her şeyi kapsar” gibi belirsiz olmamalıdır.
Bakım maddesinde şu ayrımlar bulunabilir:
| Destek Türü | Bakım Kapsamına Dahil mi? | Not |
|---|---|---|
| Kritik hata düzeltme | Genellikle evet | Uygulamayı kullanılamaz yapan hatalar |
| Küçük hata düzeltme | Pakete bağlı | Öncelik seviyesi belirlenmeli |
| Yeni özellik | Hayır | Ayrı teklif veya sprint |
| OS güncelleme uyumu | Pakete bağlı | iOS/Android majör sürümler etkileyebilir |
| Sunucu bakımı | Pakete bağlı | Yedek, uptime, güvenlik güncellemesi |
| Mağaza yeniden gönderimi | Pakete bağlı | Red sebebi kapsamı etkiler |
| Kullanıcı destek operasyonu | Genellikle hayır | Çağrı merkezi veya müşteri hizmeti ayrı iş |
SLA yani hizmet seviyesi de netleştirilebilir. Örneğin kritik hataya 4 saat içinde dönüş, yüksek öncelikli hataya 1 iş günü içinde dönüş, düşük öncelikli isteğe planlanan sprintte dönüş gibi seviyeler yazılabilir.
Diyelim ki Ayşe, 32 yaşında, İstanbul’da butik fitness stüdyosu işletiyor. Üyeler için ders takvimi, rezervasyon, paket satın alma ve bildirim içeren bir mobil uygulama yaptırmak istiyor.
İlk görüşmede proje basit görünür: kullanıcı kayıt olacak, ders seçecek, rezervasyon yapacak. Fakat sözleşmede ödeme sistemi, iptal politikası, eğitmen paneli, paket hakkı düşümü, ders kontenjanı ve push bildirim detayları yazılmadıysa geliştirme başladıktan sonra sorun çıkar.
Ayşe uygulamanın “paket hakkı bitince otomatik ödeme alsın” ister. Geliştirici ise ilk kapsamı “sadece rezervasyon” olarak anlamıştır. Eğer sözleşmede ödeme entegrasyonu ve abonelik akışı yoksa bu ek kapsam olur.
Aynı şekilde uygulama yayına çıktığında kullanıcılar “hesabımı sil” talebi gönderdiğinde teknik ve hukuki süreç hazır değilse App Store incelemesi veya kullanıcı şikayetiyle sorun yaşanabilir. Bu nedenle sözleşme; fikir aşamasındaki heyecanı, uygulanabilir ürün kapsamına dönüştüren filtredir.
Bir yazılım ajansının teklifini sadece fiyat üzerinden değerlendirmek risklidir. Sözleşme ve teklif dokümanı, ajansın proje yönetimi olgunluğunu gösterir.
Aşağıdaki işaretler olumlu kabul edilebilir:
Tersine, “her şey dahil mobil uygulama”, “sınırsız revizyon”, “2 haftada tüm platformlar”, “yayın garantisi”, “kaynak kodu konusu sonra bakılır” gibi ifadeler dikkatli incelenmelidir. Yazılımda belirsiz vaat, genellikle proje ilerledikçe maliyet veya kalite riski olarak geri döner.
Atalay Tech olarak mobil uygulama, web uygulaması ve AI entegrasyonu içeren projelerde teklifin yalnızca fiyat değil; kapsam, teslimat, bakım ve teknik sorumluluklarla birlikte okunması gerektiğini savunuyoruz. Sağlıklı proje, güçlü sözleşme ve gerçekçi kapsamla başlar.
Mobil uygulama sözleşmesini imzalamadan önce aşağıdaki kontrol listesini kullanabilirsiniz. Her maddenin karşısında “evet” diyemiyorsanız, imza öncesi netleştirme istemek daha güvenlidir.
| Kontrol Sorusu | Cevap Net mi? | Neden Önemli? |
|---|---|---|
| Uygulama iOS ve Android mi olacak? | Evet/Hayır | Platform maliyetini belirler |
| Backend ve admin panel dahil mi? | Evet/Hayır | Mobil uygulamanın yönetimini etkiler |
| Tasarım dosyaları teslim edilecek mi? | Evet/Hayır | Gelecekte geliştirme özgürlüğü sağlar |
| Kaynak kodu devri yazıyor mu? | Evet/Hayır | Sahiplik tartışmasını azaltır |
| Revizyon sayısı belli mi? | Evet/Hayır | Sonsuz revizyon riskini azaltır |
| KVKK rolleri yazılmış mı? | Evet/Hayır | Veri sorumluluğunu netleştirir |
| Ödeme gecikmesi prosedürü var mı? | Evet/Hayır | İş durdurma/fesih riskini yönetir |
| Mağaza yayın sorumluluğu ayrılmış mı? | Evet/Hayır | App Store/Google Play sürecini netleştirir |
| Bakım süresi ve kapsamı yazıyor mu? | Evet/Hayır | Yayın sonrası destek beklentisini belirler |
| Ek kapsam fiyatlandırması yazıyor mu? | Evet/Hayır | Yeni talepleri yönetilebilir kılar |
Bu tabloyu bir avukat veya proje danışmanı ile birlikte gözden geçirmek, özellikle yüksek bütçeli mobil uygulama yatırımlarında ciddi avantaj sağlar.
Hukuken her iş ilişkisinde yazılı sözleşme tek geçerli yol olmak zorunda değildir; fakat mobil uygulama gibi kapsamı, teslimatı, ödeme planı, fikri mülkiyeti ve veri güvenliğini içeren projelerde yazılı sözleşme pratik olarak zorunlu kabul edilmelidir. Çünkü proje ilerledikçe tarafların hafızası değil, yazılı mutabakat belirleyici olur. Özellikle kaynak kodu, bakım süresi, mağaza yayın desteği ve ek kapsam maddeleri sözleşmede yoksa, teslim aşamasında ciddi anlaşmazlık yaşanabilir. Kısa bir sözleşme bile hiç sözleşme olmamasından iyidir; ancak teknik kapsam ekiyle desteklenmiş sözleşme en sağlıklı modeldir.
Bu tamamen iş modeline ve anlaşmaya bağlıdır. Müşteri uygulamanın uzun vadeli sahibi olmak, ileride farklı ekiplerle geliştirme yaptırmak veya yatırım sürecinde teknik varlığını göstermek istiyorsa kaynak kodu teslimi açıkça yazılmalıdır. Ancak ajansın kendi geliştirdiği genel altyapı, panel bileşenleri, tekrar kullanılabilir paketleri veya know-how’ı projeden ayrı tutulabilir. Bu yüzden sözleşmede “proje özelinde geliştirilen kaynak kod”, “ajansa ait önceden var olan bileşenler” ve “üçüncü taraf açık kaynak kütüphaneler” ayrı tanımlanmalıdır. En riskli durum, kaynak kodu hakkında hiçbir şey yazılmamasıdır.
Basit MVP projelerinde 1-3 ay hata desteği yeterli olabilir; daha ciddi ticari uygulamalarda 6-12 aylık bakım planı düşünülmelidir. Fakat burada önemli olan süre değil, bakımın kapsamıdır. Kritik hata düzeltme, küçük hata, işletim sistemi uyumu, sunucu takibi, mağaza güncellemesi ve yeni özellik talepleri aynı şey değildir. Sözleşmede “6 ay destek” yazıp detay vermemek yanlıştır. Örneğin “yayın sonrası 6 ay boyunca kapsam dahilindeki fonksiyonlarda ortaya çıkan yazılımsal hatalar giderilir; yeni özellikler ve üçüncü taraf servis değişiklikleri ayrıca fiyatlandırılır” gibi net ifade kullanılmalıdır.
Red sebebine göre değişir. Uygulama teknik hata nedeniyle reddedildiyse geliştirici ekibin düzeltme sorumluluğu olabilir. Fakat red sebebi hukuki metin eksikliği, marka hakkı, kullanıcı verisi beyanı, uygunsuz içerik, eksik lisans, yanıltıcı açıklama veya müşteri operasyonundan kaynaklanan bir durumsa sorumluluk müşteriye ait olabilir. Bu yüzden sözleşmede mağaza yayın desteği ayrı yazılmalıdır. Ayrıca “mağaza platformlarının nihai inceleme ve yayın kararları geliştiricinin kontrolü dışında olabilir” benzeri bir madde gerçekçi beklenti oluşturur. Yayın desteği verilebilir; fakat mağaza onayı garanti edilemez.
KVKK maddesi, uygulamanın hangi verileri topladığını, tarafların veri rolünü, veri güvenliği sorumluluklarını, üçüncü taraf servisleri ve kullanıcı haklarına ilişkin teknik süreçleri ele almalıdır. Yazılım ajansı çoğu projede teknik hizmet sağlayıcı veya veri işleyen gibi konumlanabilir; müşteri ise işleme amacını belirlediği için veri sorumlusu olabilir. Ancak bu durum projeye göre değişir ve hukuki değerlendirme gerektirir. Sözleşmede gizlilik politikası, aydınlatma metni ve açık rıza metinlerinin kim tarafından hazırlanacağı da yazılmalıdır. Yazılımcının hukuki metin yazması beklenmemeli; teknik entegrasyon sorumluluğu ayrılmalıdır.
Sınırsız revizyon ilk bakışta müşteri lehine görünür, fakat pratikte proje kalitesini ve takvimi bozar. Çünkü sınırsız revizyon, kapsamı sürekli değişen ve teslim edilemeyen bir ürüne dönüşebilir. Daha sağlıklı model, tasarım için belirli sayıda revizyon turu, geliştirme için hata düzeltme süreci ve yeni özellikler için ek kapsam prosedürü tanımlamaktır. Örneğin “UI tasarım aşamasında 2 revizyon turu dahildir; onaylanan tasarım sonrası yapısal ekran değişiklikleri ek kapsam olarak değerlendirilir” ifadesi daha yönetilebilir bir çerçeve oluşturur. Bu yaklaşım hem müşteri beklentisini hem ekip planlamasını korur.
Ödeme planı tarih, oran, tutar, KDV, fatura zamanı ve ödeme gecikmesi prosedürüyle birlikte yazılmalıdır. Sadece “proje bedeli 500.000 TL” demek yeterli değildir. “%40 sözleşme imzasında, %30 test sürümü tesliminde, %30 mağaza yayını öncesinde ödenir” gibi milestone bazlı model daha nettir. Kurumsal projelerde aylık milestone veya faz bazlı ödeme kullanılabilir. Ayrıca ödeme gecikmesi halinde geliştirme çalışmalarının durdurulup durdurulmayacağı, gecikme süresinin proje takvimini nasıl etkileyeceği ve fesih hakkının ne zaman doğacağı açıkça belirtilmelidir.
Evet, özellikle üçüncü taraf servis, döviz bazlı lisans, SMS, e-posta, harita, AI API, bulut sunucu, ödeme sistemi ve mağaza ücretleri gibi maliyetler projeye dahilse ek maliyet maddesi bulunmalıdır. Örneğin AI destekli bir mobil uygulamada model kullanım maliyeti, kullanıcı sayısı arttıkça değişebilir. Harita tabanlı bir uygulamada Google Maps veya benzeri servislerin kullanım limitleri faturayı etkileyebilir. Sözleşmede hangi maliyetlerin proje bedeline dahil olduğu, hangilerinin müşteri tarafından ayrıca karşılanacağı net yazılmalıdır. Aksi halde operasyon büyüdüğünde taraflar beklenmeyen masraflarla karşılaşabilir.
Mobil uygulama bütçesi yalnızca yazılım geliştirme bedelinden oluşmaz. Kapsam, tasarım, entegrasyon, güvenlik, test, mağaza yayını, bakım ve büyüme maliyetleri birlikte planlanmalıdır. Bu rehber, MVP'den kurumsal uygulamalara kadar gerçekçi bütçe kalemlerini anlatır.
ERP entegrasyonlu mobil uygulama; saha satış, bayi siparişi, stok takibi, servis operasyonu ve yönetici raporlarını ERP verisiyle mobilde kullanılabilir hale getirir. Bu rehberde kullanım senaryoları, entegrasyon mimarisi, maliyet aralıkları, güvenlik, test süreci ve proje planlaması teknik açıdan ele alınır.
Restoran sipariş uygulaması geliştirme; menü yönetimi, online ödeme, kurye takibi, kampanya kurgusu, POS entegrasyonu ve müşteri sadakati gibi birçok katmanı birlikte planlamayı gerektirir. Bu rehber, restoran zincirleri ve bağımsız işletmeler için teknik kapsamı, maliyet aralıklarını ve geliştirme sürecini açıklar.
