Mobil Uygulama Geliştirme Sözleşmesi ve Kaynak Kod Teslimi Rehberi
Mobil uygulama geliştirme sözleşmesinde kapsam, kabul, fikrî haklar, kaynak kod teslimi, mağaza hesapları, bakım ve fesih maddelerini doğru kurgulayın.
Kısa cevap: İyi sözleşme yalnızca bedeli değil, çalışabilir teslimi tarif eder
Mobil uygulama geliştirme sözleşmesi; fikir, ekran ve ödeme takvimi yazılmış bir sipariş formundan daha fazlasıdır. İşletmenin satın aldığı şey yalnızca App Store’da görünen son paket değil; sürdürülebilir kaynak kod, backend, veritabanı değişiklikleri, tasarım, test kanıtı, mağaza kaydı, dokümantasyon ve bu varlıkları kullanma hakkıdır. Sözleşme “kaynak kod teslim edilir” deyip hangi deponun, hangi sürümün, hangi bağımlılıklarla ve hangi haklarla teslim edileceğini söylemiyorsa en kritik riski açık bırakır.
Bu rehber hukuki görüş yerine geçmez. Ama hukuk danışmanının inceleyeceği ticari metne teknik gerçekliği taşıyacak kontrol alanlarını sunar. En iyi sonuç, ürün sahibi, teknik sorumlu ve hukuk danışmanının aynı teslim envanteri üzerinde çalışmasıyla alınır. Teknik ekler belirsizse çok güçlü bir genel sözleşme bile uygulamanın yeniden build edilememesi, hesapların devredilememesi veya kabul tartışmasının aylar sürmesi gibi sorunları tek başına çözemez.
Kimler bu sözleşmeyi ayrıntılı kurmalı?
İlk kez uygulama yaptıran girişimler, şirket dışından ajans veya freelancer kullanan işletmeler, yatırım ya da şirket satışı ihtimali bulunan ürünler, kişisel veri işleyen platformlar ve birden çok tedarikçinin aynı backend üzerinde çalışacağı kurumsal projeler için ayrıntılı teknik ek zorunluya yakındır. Küçük bir MVP’de dahi depo ve hesap sahipliği baştan kurulmazsa ürün doğrulandıktan sonra geçiş maliyeti büyür.
Mevcut bir ajansın yerine yeni ekip alma ihtimali hiç yokmuş gibi sözleşme yapmak gerçekçi değildir. Tedarikçi değişikliği başarısızlık anlamına gelmeyebilir; şirket büyür, uzmanlık ihtiyacı değişir veya ürün iç ekibe alınır. Bu nedenle sözleşme yalnızca iyi giden senaryoyu değil, makul bir ayrılığı da tasarlamalıdır. Amaç geliştiriciyi cezalandırmak değil, her iki tarafın sorumluluk ve sınırlarını ölçülebilir hale getirmektir.
Sözleşme modeli için karar matrisi
| Model | Ne zaman kullanılır? | Müşterinin dikkat edeceği nokta |
|---|---|---|
| Sabit kapsam / kilometre taşı | Gereksinimler ve kabul çıktıları yeterince netse | Değişiklik talebi, bağımlılık ve kabul süresi |
| Zaman ve malzeme | Ürün keşfi devam ediyor, öncelikler değişebiliyorsa | Kapasite, raporlama, bütçe tavanı ve çıktı görünürlüğü |
| Ayrı keşif + uygulama | Teknik belirsizlik veya entegrasyon riski yüksekse | Keşif belgelerinin sonraki tedarikçide kullanılabilmesi |
| Ürün ekibi aboneliği | Sürekli geliştirme ve bakım bekleniyorsa | Rol kapasitesi, servis seviyesi ve çıkış/handover koşulları |
Sabit fiyat sözleşmesi belirsiz kapsamı sihirli biçimde sabitlemez. Bilinmeyen bir entegrasyon, onaysız tasarım veya tanımsız performans beklentisi varsa risk ya fiyat tamponuna ya değişiklik talebine ya da kalite kaybına dönüşür. Buna karşılık zaman ve malzeme modeli de sınırsız fatura anlamına gelmemelidir. Sprint hedefi, görünür iş listesi, kabul edilen kapasite, harcama uyarısı ve durdurma yetkisi yazılmalıdır.
Teknik kapsam eki ekran listesinden nasıl ayrılır?
“Profil, sepet, bildirim” şeklindeki liste teklif karşılaştırmak için yetersizdir. Her modül; aktör, ön koşul, ana akış, istisna, veri, entegrasyon ve kabul sonucu ile tanımlanmalıdır. Örneğin profil modülünde e-posta değiştirme sırasında yeniden doğrulama var mı, hesap silme veriyi ne zaman anonimleştiriyor, bir kullanıcı aynı anda kaç cihazda oturum açabiliyor? Bu davranışlar yazılmadığında taraflar aynı ekran adına farklı ürünler yükler.
Teknik ek ayrıca platformları, desteklenen işletim sistemi aralığını, telefon/tablet kapsamını, dil ve erişilebilirlik beklentisini, backend ve yönetim panelini, çevrimdışı davranışı, üçüncü taraf servisleri, analitiği ve yayın sorumluluğunu kapsamalıdır. Mockup teslimi ile üretime hazır tasarım, API bağlamak ile API geliştirmek, mağazaya paket yüklemek ile incelemeyi yönetmek aynı iş değildir. Teklifte “dahil/değil/müşteri sağlar” işaretleri kullanmak sınırları görünür yapar.
Fikrî haklar: Tek bir “tüm haklar” cümlesi neden yetmez?
Mobil ürün en az dört varlık sınıfı içerir: bu proje için yazılan özgün kod ve tasarım; tedarikçinin projeden önce sahip olduğu genel bileşenler; açık kaynak paketler; lisanslı üçüncü taraf hizmet ve içerikler. Müşteriye devredilebilecek haklar bu sınıflarda aynı değildir. Sözleşmede önceden var olan varlıklar listelenmeli, projeye özgü çıktılar tanımlanmalı ve üçüncü taraf koşullarının teslim envanterinde gösterilmesi istenmelidir.
Türkiye’de bilgisayar programları ve mali haklara ilişkin çerçeve için 5846 sayılı Fikir ve Sanat Eserleri Kanunu’nun resmi metni incelenebilir. Hak devri, lisans, çalışan veya alt yüklenici katkısı, ülke ve süre gibi konular somut projeye göre hukuk danışmanıyla kurulmalıdır. Teknik ekibin görevi hukuki nitelendirme yapmak değil, hangi dosya ve bileşenin kim tarafından üretildiğini izlenebilir hale getirmektir.
Tedarikçi alt yüklenici kullanıyorsa zincir ayrıca önemlidir. Ajansın müşteriye vaat ettiği hakkı kendi çalışanı veya yüklenicisinden edinmiş olması gerekir. Kod incelemesinde internette bulunan lisanssız parçalar, satın alınmış UI kitleri, ücretli fontlar veya yeniden dağıtılamayan SDK’lar tespit edilebilir. Sözleşme, tedarikçinin bileşen envanteri sunmasını ve lisans ihlali bildirim sürecini tanımlamalıdır.
Kaynak kod teslimi teknik olarak ne demektir?
Kaynak kod tesliminin en iyi kanıtı, projenin müşterinin sahibi olduğu GitHub, GitLab veya eşdeğer kurumsal organizasyonda geliştirilmesidir. Tedarikçiye kişisel hesaplarla rol verilir; branch koruması, kod incelemesi ve çok faktörlü giriş uygulanır. Böylece her kilometre taşında güncel commit geçmişi müşterinin kontrolündedir. GitHub’ın repository transfer belgesi bir deponun aktarılabileceğini gösterse de transferi sona bırakmak erişim ve organizasyon politikası açısından gereksiz risk yaratabilir.
Teslim edilen depo temiz bir bilgisayarda dokümana göre build edilebilmelidir. Sadece geliştiricinin makinesinde bulunan sertifika, yerel dosya, özel paket veya gizli anahtar build için şart olmamalıdır. Bağımlılık sürümleri kilitlenmeli; ortam değişkenlerinin adları ve kaynağı belgelenmeli; geliştirme, test ve canlı yapılandırması ayrılmalıdır. Gizli değerler kod deposuna yazılmaz, müşterinin kontrol ettiği güvenli bir sır yönetim sisteminden sağlanır.
Commit geçmişi de teslimatın parçasıdır. ZIP dosyası son görünümü verir fakat kararların, geri dönüş noktalarının, katkıların ve güvenlik taramasının izini zayıflatır. Tag ve sürüm notları mağazadaki binary ile hangi kodun eşleştiğini göstermelidir. Backend, mobil istemci, yönetim paneli, altyapı kodu ve veritabanı göçleri farklı depolardaysa hepsi teslim envanterine bağlanmalıdır.
Hesaplar, imza anahtarları ve yayın sahipliği
Apple Developer, App Store Connect ve Google Play Console hesabı ticari ürünün kimliğiyle yakından ilişkilidir. Hesap mümkünse müşteri organizasyonu tarafından açılmalı; geliştirme ekibi rol bazlı davet edilmelidir. Google’ın Play Console kullanıcı ve izin rehberi ile Apple’ın App Store Connect rol izinleri erişimin görev bazında sınırlandırılmasına yardımcı olur.
iOS sertifikaları, provisioning profilleri, push anahtarı, Android upload key, Play App Signing bilgisi, Firebase projesi, bulut hesabı, alan adı, e-posta sağlayıcısı ve ödeme sistemi tek bir “mağaza hesabı” başlığında kaybolmamalıdır. Her varlık için sahip, yönetici, fatura sorumlusu, kurtarma e-postası ve devir yöntemi yazılmalıdır. Anahtar teslimi düz metin e-posta ile değil kontrollü kasa ve erişim kaydıyla yapılmalıdır.
Mağazada geliştiricinin hesabında yayınlanmış uygulama sonradan aktarılabilir; ancak koşullar ve bazı bağlı servisler ek çalışma yaratır. Apple’ın uygulama transferi genel görünümü ile Google’ın uygulama transferi rehberi bu bağımlılıkları açıklar. Sözleşmede “gerektiğinde devir yapılır” yerine transfer uygunluğu, gerekli işbirliği ve bağlı servis güncellemeleri tarif edilmelidir.
Kabul kriteri ve ödeme kilometre taşı nasıl eşleşir?
Ödeme yalnızca takvim tarihine bağlanırsa görünür fakat kullanılamaz çıktı tartışma yaratır. Her kilometre taşı; demo ortamı, dahil kullanıcı senaryoları, kabul testleri, izin verilen hata seviyeleri, müşteri inceleme süresi ve düzeltme döngüsüyle tanımlanmalıdır. Kabul edilmemiş küçük görsel hata ile ödeme akışını engelleyen kritik sorun aynı sınıfta tutulmamalıdır.
Mağaza onayı tümüyle geliştiricinin kontrolünde değildir; yine de politika uyumlu hazırlık, doğru beyan, test hesabı ve teknik retlerin giderilmesi sorumluluğu belirlenebilir. Müşterinin sağlaması gereken şirket belgesi, hukuki metin, ürün içeriği veya ödeme hesabı gecikirse takvimin nasıl etkileneceği de yazılmalıdır. Sessiz kabul maddesi varsa inceleme süresi gerçekçi olmalı ve hangi çıktının incelemeye hazır sayıldığı açık olmalıdır.
Maliyet ve süreyi sözleşmede etkileyen etkenler
Sözleşme hazırlığının proje maliyetine etkisi, belirsizlikleri erken çözme düzeyiyle ilişkilidir. Çoklu rol, ödeme, abonelik, harita, donanım, ERP, yüksek güvenlik veya eski sistem entegrasyonu ayrıntılı keşif gerektirir. Tasarım ve API hazır değilse geliştirme süresine dahil edilmelidir. Veri göçü, mağaza hesabı doğrulaması, dış sağlayıcı sertifikasyonu ve içerik onayı takımın kodlama hızından bağımsız beklemeler yaratabilir.
Fiyat karşılaştırırken tasarım dosyası, backend, admin panel, QA, cihaz testi, güvenlik kontrolü, mağaza yayını, dokümantasyon ve garanti dahil mi bakılmalıdır. Ucuz teklif bu kalemleri müşteriye bırakıyor olabilir. Sabit rakam yerine varsayım ve hariçler tablosu, birim değişiklik yöntemi ve faz bazlı bütçe görünürlüğü istenmelidir. Üçüncü taraf abonelikleri, mağaza üyelikleri, bulut kullanımı ve mesaj gönderim bedelleri geliştirme ücretinden ayrılmalıdır.
Asgari teslim envanteri
- Commit geçmişi ve sürüm etiketleriyle tüm kaynak kod depoları
- Bağımlılık kilit dosyaları, lisans/SBOM envanteri ve üçüncü taraf bildirimleri
- Tasarım kaynakları, ikonlar, fontlar ve içerik lisansları
- API şeması, veri modeli, veritabanı göçleri ve örnek istekler
- Temiz ortam kurulum, build, imzalama ve yayın talimatları
- Test senaryoları, test sonuçları, bilinen hata ve teknik borç listesi
- Mimari kararlar, entegrasyon ve operasyon dokümanı
- Mağaza kayıtları, gizlilik beyanları ve yayınlanmış sürüm bilgisi
- Hesap ve rol envanteri, alan adı, bulut, bildirim, analitik ve ödeme erişimleri
- Yedekleme, geri yükleme, izleme ve olay müdahale prosedürü
Sözleşmede sık görülen riskli ifadeler
“Benzer özellikler”, “gerekli entegrasyonlar”, “sınırsız revizyon”, “hatasız teslim”, “uygun cihazlar” ve “kaynak kod daha sonra verilir” ölçülebilir değildir. Sınırsız vaatler güvence gibi görünür, fakat sınır tanımlamadığı için uygulanabilirliği düşüktür. Revizyonun tasarım turu mu, yeni özellik mi olduğu; hatanın kabul edilmiş gereksinimden sapma mı, değişen tercih mi olduğu belirlenmelidir.
Diğer kırmızı bayraklar; ödeme tamamlanana kadar müşterinin hiçbir kod görünürlüğü olmaması, mağaza ve bulutun geliştiricinin kişisel hesabında tutulması, alt yüklenici kullanımının belirsizliği, lisans envanterinin reddedilmesi ve fesih halinde yalnızca binary teslim edilmesidir. Müşteri tarafında da geciken içerik/onay, tek karar verici olmaması ve sürekli kapsam ekleyip tarihi sabit tutma beklentisi projeyi bozar. Sözleşme iki tarafın katkısını dengeli biçimde yazar.
Teklif ve sözleşme kontrol listesi
- İş hedefi, kullanıcı rolleri ve sürüm kapsamı teknik ekte mevcut mu?
- Dahil, hariç ve müşteri tarafından sağlanacak kalemler açık mı?
- Kilometre taşı başına demo, kabul kriteri ve ödeme koşulu eşleşiyor mu?
- Değişiklik taleplerinin süre ve bütçeye etkisi nasıl onaylanacak?
- Projeye özgü, önceden var olan ve üçüncü taraf varlıklar ayrıldı mı?
- Mali hak veya lisans kapsamı hukuk danışmanı tarafından doğrulandı mı?
- Kod müşterinin kurumsal deposunda mı; build ve yayın tekrarlanabilir mi?
- Mağaza, bulut, alan adı, analitik ve ödeme hesaplarının sahibi kim?
- Güvenlik, KVKK, yedekleme ve alt işleyen sorumlulukları tanımlı mı?
- Garanti ile yeni özellik/bakım arasındaki sınır ve SLA belli mi?
- Fesihte güncel kod, belge, veri, erişim ve geçiş desteği kaç iş gününde sağlanacak?
- Uyuşmazlık öncesi teknik değerlendirme ve bildirim mekanizması var mı?
Sözleşmeden teslimata önerilen süreç
Önce tek sayfalık ürün özeti ve kapsam varsayımları hazırlanır. Ardından kullanıcı akışları, veri sınıfları, entegrasyonlar ve en riskli teknik konular keşfedilir. Bu bilgi teknik şartnameye, kabul senaryolarına ve teslim envanterine çevrilir. Hukuk danışmanı hak, sorumluluk, gizlilik, fesih ve uyuşmazlık maddelerini bu somut ekler üzerinden düzenler.
Geliştirme başlarken müşteri organizasyonları ve rol erişimleri kurulur. Her sprintte kod, test sonucu, demo ve karar kaydı görünür olur. Kilometre taşı sonunda yalnızca sunum değil, belirtilen ortamda çalıştırılabilir sürüm teslim edilir. Yayın öncesi hesap envanteri, mağaza beyanları, yedekleme ve güvenlik kontrol edilir. Son kabulte temiz makinede build provası ve erişim denetimi yapılır.
Bakım sözleşmesi ayrı olsa bile çıkış planı ana sözleşmede bulunmalıdır. Son sürüm, açık hata, teknik borç, aktif olay, lisans yenileme ve erişim sahipleri ortak bir handover tutanağına bağlanır. Böylece iş ilişkisi devam ederken de ürün tek bir kişinin hafızasına bağlı kalmaz.
Sonuç: Kaynak kodun değeri, kullanılabilir ve yönetilebilir olmasındadır
Mobil uygulama geliştirme sözleşmesinin amacı taraflardan birini köşeye sıkıştırmak değil, vaat edilen ürünün ne olduğunu ve nasıl devredileceğini aynı dilde tarif etmektir. MobiCraft ile görüşmeden önce mevcut gereksinimlerinizi, hedef mağazaları, entegrasyonları ve şirketinizin hesap yapısını paylaşın. Birlikte ekran listesini kabul edilebilir kullanıcı akışlarına, “kod teslimi” ifadesini yeniden üretilebilir teknik teslim envanterine dönüştürelim; hukuki metni ise kendi danışmanınız bu somut kapsam üzerinde güvenceye alsın.