Özel Yazılım Çözümleri

Özel Yazılım Fiyatları ve Doğru Geliştirme Süreci

Fiyatı belirleyen kod satırı değil, erken aşamada alınan kararlardır.

Kapsamınızı Birlikte Belirleyin

Şeffaf Yazılım Geliştirme Süreçleri, Proje Maliyet Analizi ve Yazılım Geliştirme Fiyat Teklifi

Özel yazılım veya mobil uygulama projesine başlamadan önce iki temel soru öne çıkar: "Kaça mal olacak?" ve "Ne zaman biter?" Bu soruların dürüst yanıtı her zaman aynı cümleyle başlar: Kapsam netleşmeden bu soruların güvenilir yanıtı yoktur.

Bu sayfa, yazılım projelerinin nasıl fiyatlandırıldığını, neden kimi zaman bütçe aşıldığını, hangi süreç modelinin gerçek güvenceyi sağladığını ve yatırım kararından önce ne sorulması gerektiğini açıklamaktadır.

Kurumsal Düzeyde Bir Yazılım Geliştirme Süreci Nasıl Yönetilir?

Yazılım projelerinin büyük çoğunluğu başlamadan değil, yönetilmeden başarısız olur. Teknik yetkinlik gereklidir; ancak süreç disiplini olmadan tek başına yeterli değildir.

Kurumsal ölçekte başarıyla tamamlanan projeler şu ortak paydaya sahiptir:

  • Kapsam netleştirilmeden geliştirme başlamaz. Her özellik, her kullanıcı akışı ve her entegrasyon noktası yazıya dökülür; onaylanır.
  • İlerleme görünürdür. Müşteri, belirli aralıklarla çalışan yazılımı görür; yalnızca ilerleme raporu değil.
  • Değişiklikler yönetilir, engellenemez. Kapsam değişikliği projenin doğasında vardır; önemli olan nasıl işlendiğidir.
  • Sondan değil, baştan planlanır. Teknik mimari, güvenlik ve ölçeklenme kararları geliştirme ortasında değil, başında alınır.

Bu disiplin olmadan büyük bir yazılım ekibi de küçük bütçeli bir proje de aynı başarısızlık örüntüsüne girer.

Startup, Girişim ve Bireysel Fikir Sahipleri İçin Dijital Partnerlik Modeli

Startup ekipleri için teknik partnerlik, kurumsal projelerden farklı bir ilişki biçimi gerektirmektedir. Kurumsal projede gereksinim bellidir ve müşteri genellikle ne istediğini bilir. Startup'ta ise çoğunlukla ne istendiği değil, nasıl test edileceği belirsizdir.

Bu koşulda doğru partnerlik modeli şu prensiplere dayanır:

  • Karar alma hızı ön planda. Aylarca süren analiz yerine, iki haftada çalışır bir prototip; iki haftada daha gerçek kullanıcı geri bildirimi.
  • Bütçe esnekliği korunur. Tam fiyatını bilmeden tüm özellikler için ödeme yapılmaz; önce MVP, sonra kullanıcı verisi, sonra bir sonraki sprint.
  • Pivot maliyeti düşük tutulur. Sistem, köklü değişikliklere adapte olabilecek biçimde tasarlanır.
  • Kurucunun zamanı korunur. Teknik kararları yönetmek kurucu ekibin varoluş amacı değildir; bu yük teknik partnerlik modeliyle taşınır.

Melek Yatırım ve Tohum (Seed) Öncesi Aşama İçin MVP Bütçesi Çıkartma

Melek yatırımcılar veya Seed fonları, geliştirme öncesi sunum (pitch deck) aşamasında protoip görmek ister; çalışan bir ürün değil, ama elle dokunulabilir, test edilebilir bir sistem. Bu iki beklentinin karıştırılması gereksiz bütçe harcanmasına yol açar.

Yatırımcı öncesi süreçte değer yaratan ürünler:

  • Tıklanabilir prototip (UI prototype): Tasarım araçlarıyla (Figma vb.) oluşturulan, gerçek veri olmadan çalışan tıklanabilir akış. Geliştirme maliyetinin küçük bir kesriyle yapılır; yatırımcı sunumlarında çoğunlukla yeterlidir.
  • Teknik MVP: Gerçek veri işleyen, gerçek kullanıcıların test edebildiği minimum işlevsel sistem. Seed öncesi ya da erken müşteri testleri için uygundur.
  • Tam kapsamlı ürün: Yatırım alındıktan ve product-market fit doğrulandıktan sonra inşa edilmesi gereken aşamadır.

Bu sıralamayı tersine çevirmek, en yaygın startup yazılım israfıdır: kimse test etmeden tam ürün geliştirilir, yatırımcı beğenmez veya kullanıcı kullanmaz; bütçe tamamdır.

Startuplar ve Bireysel Girişimciler İçin Esnek Bütçeleme Yöntemleri

Geleneksel yazılım projesinde bütçe önceden belirlenir ve bu bütçe içinde kalmak hedeflenir. Startup mantığında bu model çalışmaz; çünkü ne yapılacağı süreç içinde netleşmektedir.

Esnekliği koruyan bütçeleme yöntemleri:

  • Sprint bazlı ödeme: Her iki haftalık sprint sonunda teslim edilen çıktıya göre ödeme yapılır. Proje ortasında durdurulsa, yapılan iş için ödeme yapılmış; yapılmayan için bütçe tüketilmemiştir.
  • Zaman ve malzeme (T&M) modeli: Belirlenen saatlik veya günlük ücret üzerinden harcanan kapasiteye göre fatura. Kapsam değiştikçe bütçe de buna adapte olur.
  • Sabit kapsam – değiştirilebilir özellik: MVP kapsamı sabitlenir; ancak hangi özelliklerin bu kapsama gireceği veriye göre yeniden önceliklendirilir.

Her modelin avantaj ve dezavantajı vardır. Hangisinin seçileceği, projenin netlik seviyesine ve risk toleransına göre belirlenir.

Yazılım Geliştirme Sürecindeki Roller

Bir yazılım projesinin çıktı kalitesi, ekip kompozisyonuyla doğrudan ilişkilidir. Her projeye aynı ekip yapısı yeterli değildir; projenin türü ve aşamasına göre hangi rollerin etkin olduğu değişir.

Temel roller ve sorumlulukları:

İş Analisti (Business Analyst): Müşteri ihtiyacını teknik dile çevirir. Kullanıcı akışlarını, iş kurallarını ve öncelikleri belgeliyor; geliştirme ekibi ile müşteri arasındaki anlam boşluğunu kapatır.

UX/UI Tasarımcı: Kullanıcı deneyimini ve arayüz tasarımını yönetir. Wireframe ve interaktif prototip oluşturur; tasarım geliştirmeden önce onaylanır.

Backend Geliştirici: Sunucu tarafı iş mantığını, veritabanı yönetimini ve API tasarımını gerçekleştirir. Sistemin performansı, güvenliği ve ölçeklenme kapasitesi büyük ölçüde backend kararlarıyla şekillenir.

Frontend / Mobil Geliştirici: Kullanıcının gördüğü arayüzü kodlar; backend API'leriyle entegre eder.

DevOps Mühendisi: Geliştirme, test ve üretim ortamlarını yönetir. CI/CD pipeline kurulumu, altyapı otomasyonu ve deployment süreçlerinden sorumludur.

QA Mühendisi (Kalite Güvence): Test senaryolarını yazar ve çalıştırır; her modülün beklenen davranışı sergilediğini doğrular.

Küçük projelerde bu rollerin birkaçı tek kişide birleşebilir; ancak kritik roller arasındaki sorumluluk karışıklığı gözden kaçırılan hataların temel nedenidir.

Yazılım geliştirme ekibi rolleri ve sprint sürecinin yönetimi

Dış Kaynak Yazılım (Outsourcing) ve Yazılım Geliştirme Ekibi Kiralama (Dedicated Team)

Kurumlar, yazılım geliştirme kapasitesini elde etmek için iki temel yol arasında seçim yapar: kendi bünyesinde ekip kurmak veya dışarıdan temin etmek (outsourcing). Her iki yaklaşımın da gerçek öngörülemeyen maliyetleri vardır.

Kurum içi ekip (in-house) kurmanın maliyetleri:

  • Uzman yazılımcı bulma süresi ve işe alım maliyeti
  • Yetenek elde tutma (rekabetçi maaş, yan haklar, eğitim bütçesi)
  • Düşük iş yükü dönemlerinde boşta geçen kapasite maliyeti
  • Teknoloji değişimlerinde yeniden eğitim gereklilikleri

Dış kaynak yazılım (outsourcing) modelleri:

  • Proje bazlı: Belirli bir projenin tamamı dışarıya devredilir. Proje tamamlandığında ilişki sonuçlanır.
  • Dedicated team: Belirli bir kapasitede geliştirici ekibi, aylık sabit maliyet karşılığında kurumun projelerine tahsis edilir. Kurum içi ekibin esnekliğiyle dış temin ekonomisini birleştirir.
  • Staff augmentation: Mevcut kurum içi ekibin belirli uzmanlık alanlarında dışarıdan desteklenmesi.

Hangi modelin seçileceği; projenin sürekliliğine, teknik özgünlüğüne ve kurumun teknik birikim hedefine göre belirlenir.

İletişim, Dokümantasyon ve Raporlama Koddan Neden Daha Önemli?

Bu başlık karşı-sezgisel görünür; ancak proje başarısızlıklarının büyük çoğunluğunda teknik yetersizlik değil, iletişim kopukluğu belirleyici roldedir.

Somut örnekler:

  • Geliştirilen özellik müşterinin istediğinden farklıdır; çünkü gereksinim yeterince belgelenmemiştir.
  • Proje ortasında yapılan bir mimari değişiklik müşteriyle paylaşılmamış; ancak bu karar sonraki modüllerin teslim tarihini etkilemiştir.
  • Müşteri sprint demosu yapılmadığı için projenin nerede olduğunu bilmemekte; güven erozyonu başlamaktadır.

Sağlıklı iletişim modelinin temel unsurları:

  • Sprint demo: Her iki haftada bir, çalışan yazılımın müşteriye gösterildiği yapılandırılmış toplantı.
  • Kapsam değişikliği bildirimi: Herhangi bir kapsam değişikliği talep geldiğinde, süre ve bütçe etkisi yazılı olarak iletilir; sözlü onay beklenmez.
  • Teknik belgeleme: Mimari kararlar, API şemaları, veritabanı modeli — bunlar teslimatta devredilen belgelerdir.
  • İlerleme raporu: Her sprint sonunda tamamlanan, devam eden ve sonraki sprint'e alınan maddeler listesi.

Bu yapı olmadan "ne zaman biter?" sorusu her hafta yeniden sorulmak zorunda kalınır.

Özel Yazılım Kaç Para? Özel Yazılım Fiyatları Neye Göre Belirlenir?

Özel yazılım fiyatları üç temel değişken tarafından belirlenir: teknik karmaşıklık, kapsam genişliği ve entegrasyon gereksinimleri.

Bu üç değişken netleşmeden verilen fiyatlar güvenilir değildir. Yazılım projelerinde sabit fiyat teklifi veren firmalar, ya büyük bir risk tamponu ekleyerek müşteriyi fazla ödetir, ya da düşük fiyat verip ilerleyen aşamalarda ek fatura üretir.

Referans aralıklar (Türkiye piyasası, 2026 itibarıyla genel eğilimler):

Proje Türü Tahmini Aralık
Küçük dahili araç (1-2 modül) 50.000 – 120.000 TL
Orta ölçekli web uygulaması 150.000 – 500.000 TL
Kapsamlı kurumsal sistem 500.000 TL+
Mobil uygulama (MVP, cross-platform) 80.000 – 250.000 TL
Mobil uygulama (Native, tam kapsamlı) 300.000 TL+
SaaS ürün (MVP aşaması) 100.000 – 400.000 TL

Not: Bu aralıklar kaba bir yön fikri sunar. Gerçek proje maliyeti; teknik analiz tamamlanmadan güvenilir biçimde belirlenemez.

Fiyatı doğrudan etkileyen faktörler:

  • Kullanıcı rol ve yetki karmaşıklığı
  • Üçüncü taraf entegrasyon sayısı (her entegrasyon ek geliştirme ve test süresi demektir)
  • Veri hacmi ve performans gereksinimleri
  • Mevcut sistemden veri taşıma (migrasyon) ihtiyacı
  • UI/UX tasarımın karmaşıklığı (özel animasyon, bileşen kütüphanesi vb.)
  • Güvenlik ve uyumluluk gereksinimleri (KVKK, PCI-DSS vb.)

Mobil Uygulama Fiyatları ve Mobil Uygulama Yaptırma Maliyeti 2026

Mobil uygulama maliyeti sanılır ki platform sayısına bağlıdır. Oysa asıl belirleyici faktör iş mantığının karmaşıklığıdır; iki platforma çıkmak maliyeti artırır, ancak cross-platform yaklaşım bu artışı önemli ölçüde sınırlar.

Mobil uygulama maliyetini doğrudan etkileyen bileşenler:

  • Backend API altyapısı: Uygulamanın kullancağı sunucu tarafı; çoğunlukla göz ardı edilen ancak toplam maliyetin büyük bölümünü oluşturan parçadır.
  • Entegrasyonlar: Ödeme altyapısı (iyzico, Stripe), harita servisi, bildirim servisi, kimlik doğrulama — her biri ayrı geliştirme ve test süresi demektir.
  • UI/UX tasarım: Özel animasyon, özelleştirilmiş bileşenler ve etkileşim akışları; hazır tasarım bileşenlerine kıyasla ciddi ek maliyet oluşturur.
  • Offline çalışma: Senkronizasyon mekanizması ve yerel depolama yönetimi karmaşıklığı artırır.
  • Store yayın süreci: App Store ve Play Store hesap ücretleri, yayın hazırlığı ve store optimizasyonu (ASO) çalışması.

Özel Yazılımın Maliyeti ile Hazır Paket Lisanslarının ROI Karşılaştırması

"Hazır yazılım daha ucuz" saptaması çoğunlukla doğrudur — başlangıç için. Uzun vadeli toplam sahip olma maliyeti (Total Cost of Ownership) karşılaştırmasında tablo farklılaşır.

Hazır yazılımın görünmez maliyet kalemleri:

  • Yıllık lisans artışları (SaaS ürünlerin ortalama yıllık artışı %10-20)
  • Kullanılmayan özellikleri barındıran şişkin paket; gerçek ihtiyacın küçük bir bölümü için büyük lisans ücreti
  • Özelleştirme için eklenen danışmanlık ve entegrasyon maliyetleri
  • Platforma bağımlılık (vendor lock-in); ürün durdurulduğunda ya da fiyat katlandığında alternatifsiz kalma

Özel yazılımın maliyeti ilk yıl daha yüksektir. Ancak üç yıllık pencerede bakıldığında, kuruma özgü işlevsellik, veri bağımsızlığı ve artmayan lisans sigortası nedeniyle toplam maliyette denge kurulur; birçok senaryoda özel taraf lehine geçer.

Bu karşılaştırmayı kendi projeniz için hesaplamak istiyorsanız: Değerlendirme görüşmesi →

Kapsam Sünmesi (Scope Creep) Nedir ve Bütçeyi Nasıl Aşındırır?

Kapsam sünmesi, proje geliştirme sürecinde başlangıçta tanımlanmamış özelliklerin zaman içinde kapsama eklenmesidir. Her eklenme kısmen minik görünür; toplamı ise projenin tamamlanma tarihini aylarca öteleyebilir.

Kapsam sünmesinin yaygın kanalları:

  • "Bunu da eklesek iyi olur" toplantı kararları; kapsam belgesine yansıtılmadan.
  • Kullanıcılardan gelen geri bildirimler sonrası ani öncelik değişiklikleri.
  • "Hazırken yapalım" mantığıyla eklenen ek modüller.
  • İhtiyaç analizinin yetersizliği nedeniyle baştan görülemeyen gereksinimler.

Kapsam sünmesini yönetmek, önlemekle eş anlamlı değildir. Yeni istekler değerli olabilir; önemli olan bunların kontrollü değerlendirme sürecine girmesidir:

  1. Yeni istek belgelenir.
  2. Süre ve bütçe etkisi hesaplanır.
  3. Mevcut kapsama alınması mı, gelecek sprint'e ertelenmesi mi kararı verilir.
  4. Değişiklik kayıt altına alınır.

Bu süreç işletilmeden yapılan her eklenti, bütçesiz tüketilen bir kapasite birimidir.

Bütçeyi Güvenceye Almak İçin: Çevik (Agile) Geliştirme ve Sprint Mantığı

Çevik (Agile) geliştirme metodolojisi, değişkenlik yüksek yazılım projelerinde riski yönetmek için tasarlanmıştır. Temel prensip: büyük planı yaparken küçük ve sık teslimle ilerle.

Sprint döngüsünün işleyişi:

  • Sprint başlangıcı: Gelecek iki haftada yapılacak özellikler belirlenir ve sıralanır (sprint backlog).
  • Geliştirme: Belirlenen özellikler geliştirilir.
  • Sprint review (Demo): Tamamlanan çalışma, müşteriye çalışır hâlde gösterilir. Geri bildirim alınır.
  • Retrospective: Ekip, neyin iyi gittiğini ve neyin geliştirileceğini değerlendirir.
  • Sonraki sprint planlaması: Geri bildirim sonraki sprint'in önceliklerini şekillendirir.

Bu döngü, bütçe güvencesi açısından şu mekanizmayı çalıştırır: Her sprint sonunda bütçenin nereye gittiği görülür. Proje istenen yönde gitmiyorsa 14 gün içinde müdahale edilebilir; aylarca ilerleyip sonrasında yanlış yönde olduğunu fark etmek yerine.

Açık Kaynak Kod (Open-Source) vs Geliştirici Mülkiyetindeki Lisans Kararı

Özel yazılım projelerinde kullanılan kütüphaneler ve çerçeveler; açık kaynaklı (open-source) ya da ticari lisanslı olabilir. Bu fark, hem proje maliyetini hem uzun vadeli bağımlılık riskini etkiler.

Açık kaynak kullanımının avantajları:

  • Sıfır lisans maliyeti (MIT, Apache 2.0, BSD lisanslı araçlar için).
  • Büyük topluluk; kapsamlı dokümantasyon ve destek.
  • Kaynak koda tam erişim; ihtiyaç hâlinde fork ve özelleştirme.

Dikkat edilmesi gereken noktalar:

  • GPL lisanslı kütüphane ticari ürünlerde kısıtlama içerebilir; lisans uyumluluğu kontrol edilmelidir.
  • Bakımsız (unmaintained) açık kaynak proje, güvenlik yaması almayacağı için zamanla risk hâline gelir.
  • Kritik bir özellik için tek maintainer'ı olan bir kütüphaneye bağımlılık yaratmak uzun vadeli kırılganlığa yol açar.

Proje başında kullanılan tüm kütüphanelerin lisans türü, güncel sürümü ve bakım durumu belgelenir.

Gizlilik Sözleşmesi (NDA) ve Ticari Sırların Hukuki Korunması

Yazılım geliştirme sürecinde bir firmaya iş modelini, süreçlerini ve verilerini açmak güven gerektirir. Bu güveni sözleşmeye dökmek her iki tarafın da lehine olur.

NDA (Non-Disclosure Agreement), gizlilik sözleşmesi; proje görüşmesinin başında imzalanmalıdır. Kapsadığı unsurlar:

  • Paylaşılan iş bilgilerinin (süreç, müşteri listesi, fiyatlama) üçüncü taraflara açıklanmaması.
  • Geliştirilen özel yazılımın başka müşteriye lisanslanmaması.
  • Proje dışı kullanım yasağı.

Sözleşmede netleştirilmesi gereken diğer maddeler:

  • Fikri mülkiyet sahipliği: Proje bitiminde kaynak kod kime aittir?
  • Hata düzeltme garantisi: Teslim sonrası kaç günlük garanti süresi var?
  • Rekabet yasağı: Aynı sektördeki doğrudan rakibinize aynı sistem yapılabilir mi?

Fikri Mülkiyet (IP) Devri: Kaynak Kod Proje Bitiminde Kime Aittir?

Bu madde, yazılım sözleşmelerinde en sık ihmal edilen ancak en kritik noktalardandır. Yasal olarak açıkça belirtilmediği sürece, geliştirici firma kodun fikri mülkiyet hakkını elinde tutabilir.

Müşteri açısından garanti altına alınması gereken devirler:

  • Kaynak kod: Tüm dosyalar, modüller ve konfigürasyonlar.
  • Veritabanı şeması: Tablolar, ilişkiler ve indeks yapıları.
  • Teknik dokümantasyon: Mimari kararlar, API şeması, deploy kılavuzu.
  • Üçüncü taraf lisanslar: Kullanılan açık kaynak araçların lisans belgeleri.

Bu devir, proje tesliminde kayıt altına alınmış ve imzalanmış bir protokol/tutanakla resmîleştirilmelidir. Sözlü onay yeterli değildir.

DevOps ve CI/CD Altyapısının Uzun Vadeli Geliştirme Maliyetine Etkisi

DevOps kültürü ve CI/CD (Continuous Integration / Continuous Deployment) altyapısı, yazılım geliştirme maliyetlerinde başta görünmez; uzun vadede ise en büyük verimliliği yaratan yatırımdır.

CI/CD pipeline olmayan bir projede şu maliyetler gizlidir:

  • Her deployment manuel yapılır; hata oranı yüksek, zaman uzundur.
  • Test süreci her seferinde manuel tekrarlanır; otomatik veri yoktur.
  • Farklı ortamlar arasında (geliştirme, staging, üretim) tutarsızlıklar oluşur.
  • Yeni geliştirici eklenmesi ekstra eğitim ve manuel yapılandırma gerektirir.

CI/CD altyapısının sağladıkları:

  • Her kod commitinde otomatik test; hata üretim ortamına ulaşmadan yakalanır.
  • Deployment otomatikleşir; saatlik manual işlem dakikalara düşer.
  • Her ortam kod olarak tanımlıdır (Infrastructure as Code); tutarsızlık riski ortadan kalkar.
  • Yeni geliştirici ilk günden itibaren aynı altyapıda çalışır; onboarding süresi kısalır.

Bu altyapıyı kurmak başlangıçta ek süre ve maliyet gerektirir. Ancak projenin ikinci yılından itibaren bakım ve geliştirme maliyetini ölçülür biçimde düşürür.

Teslimat Sonrası Yeni Modül Taleplerinin Ücretlendirilme Metodolojisi

Proje teslim edildiğinde kullanıcı gerçek sistemle karşılaşır ve yeni ihtiyaçlar doğar. Bu beklenen ve sağlıklı bir süreçtir. Sorun, bu sürecin nasıl yönetileceğinin baştan netleştirilmemesidir.

Teslimat sonrası taleplerin ücretlendirilme modelleri:

  • T&M (Zaman ve Malzeme): Her talep, gerçekleşen saat üzerinden faturalandırılır. Tahmini süre önceden iletilir; onay alınır.
  • Retainer modeli: Aylık sabit saat kapasitesi rezerve edilir; bu kapasite içindeki talepler öncelik sırasına göre işlenir.
  • Yeni sprint açılması: Büyük modül talepleri için yeni proje döngüsü başlatılır; kapsam, süre ve bütçe netleştirilerek.

Hangi modelin seçileceği; talebin büyüklüğüne ve sıklığına göre birlikte kararlaştırılır. Önemli olan, her talebin sözel onaya değil belgelenmiş onaya dayanmasıdır.

Kilometre Taşlarına (Milestones) Bağlı Adaletli Ödeme Planlaması

Büyük özel yazılım projelerinde tüm bütçeyi baştan ödemek hem müşteriyi hem tedarikçiyi zorlar. Milestone bazlı ödeme planı bu sorunu dengeler.

Tipik bir milestone yapısı:

Aşama Ödeme Oranı
Sözleşme imzası ve analiz başlangıcı %15-20
Teknik analiz ve UI/UX tasarım teslimi %15-20
MVP teslimi ve kullanıcı kabul testi %20-25
Tam kapsamlı sürüm teslimi %25-30
Canlıya geçiş ve eğitim %10-15

Bu yapının müşteriye sağladığı güvence şudur: her ödeme, somut bir çıktıya karşılık gelir. Hiçbir aşamada parayı verip ne çıkacağını bilmemek söz konusu değildir.

Milestone bazlı ödeme planı ve proje ilerleme yönetimi

Geliştirme Sonrası Genişletilmiş Sistem Bakım (SLA) Ücretlendirmesi

Yazılım teslimi proje kapsamının sonu; operasyonun başlangıcıdır. SLA anlaşması, canlı sistemi sürdürülebilir biçimde ayakta tutan teknik destek çerçevesini tanımlar.

SLA fiyatlandırmasını belirleyen faktörler:

  • Müdahale süresi: Kritik hata bildiriminden çözüme kadar geçen maksimum süre. 4 saatlik SLA, 24 saatlik SLA'dan farklı kapasitede ekibi bağlar; fiyatlandırma buna göre şekillenir.
  • Kapsam derinliği: Yalnızca kritik hatalar mı, yoksa performans optimizasyonu, küçük geliştirmeler ve güvenlik güncellemeleri de dahil mi?
  • İzleme altyapısı: 7/24 izleme, otomatik uyarı ve aylık sağlık raporu SLA kapsamına giriyor mu?
  • Versiyon güncellemeleri: Kullanılan framework, kütüphane ve OS güncellemeleri SLA içinde mi?

Aylık retainer modeli en yaygın SLA biçimidir. Sabit ücret karşılığında belirlenmiş kapasitede destek sağlanır; bu kapasite aşılırsa ek kapasite ayrıca planlanır.

Sık Sorulan Sorular

Geliştirdiğiniz yazılımı yatırımcıya sunarken teknik doküman sağlıyor musunuz?

Evet. Mimari dokümanı, API şeması, sistem bileşenleri diyagramı ve bir MVP'de olması gereken yol haritası dokümanları; hem yatırımcı sunumlarında hem Due Diligence süreçlerinde kullanılabilir biçimde hazırlanır.

Sözleşmedeki fiyat teklifi projenin sonlarına doğru değişebilir mi?

Kapsam değişmezse fiyat değişmez. Sözleşmede kapsamın ne içerdiği ve kapsam değişikliklerinin nasıl yönetileceği açıkça tanımlanır. Kapsam dışı her talep, süre ve bütçe etkisi iletilerek onay alındıktan sonra işleme alınır; faturaya yansıtılmadan değil.

Proje ortasında kritik yeni bir özellik gerekirse süreç nasıl işler?

Yeni özellik talebi yazılı olarak alınır. Kapsam analizi yapılır; mevcut sprint'e mi sığar yoksa yeni sprint'e mi atanır belirlenir. İlgili bütçe etkisi iletilir. Onay alınır. Bu döngü her değişiklik talebi için tekrarlanır; sözel kalmaz.

Ekibinizin kaliteli çalıştığını ve zamanı doğru yönettiğini nasıl bileceğiz?

Sprint demo mekanizması bu sorunu çözmek için tasarlanmıştır. Her iki haftada bir çalışır yazılım gösterilir; ilerleme raporuyla değil. Böylece projenin nerede olduğu somut ve doğrulanabilir hâle gelir.

Kurum içi IT ekibimiz var; kaynak kodları onlara devrederek projenin dışına çıkabilir misiniz?

Evet. Bu hem teknik hem ticari açıdan sağlıklı bir tercihtir. Geliştirilen sistemin tüm kaynak kodu, dokümantasyonu ve deploy kılavuzu proje bitimiyle birlikte teslim edilir. İç ekibin sistemi devralabilmesi için ek onboarding ve aktarım toplantısı düzenlenmesi de kapsama dahil edilebilir.

Proje tamamlandığında kaynak kod devrinin belgelendiğini nasıl kanıtlayabiliriz?

Teslim tutanağı hazırlanır; teslim edilen dosyalar, sürüm numaraları, repo erişim bilgileri ve lisans belgeleri listelenmiş biçimde imzalı olarak teslim edilir.

Geliştirme bittikten sonra zorunlu server maliyetleri ne kadar olur?

Bu proje altyapısına ve trafik profiline göre değişir. Küçük ölçekli bir uygulama için temel bulut barındırma maliyeti aylık 500-2.000 TL aralığında olabilir. Yüksek trafikli sistemlerde bu maliyet büyük ölçüde artar. Proje kapsamında hangi altyapının kullanılacağı belirlenir ve tahmini aylık işletim maliyeti önceden iletilir.

Yayın sonrası çıkan buglar için ayrıca fatura kesiyor musunuz?

Proje tesliminden itibaren genellikle 30-60 günlük hata düzeltme garantisi sunulur. Bu süre içinde teslimat kapsamındaki modüllerde ortaya çıkan hatalar ücretsiz giderilir. Garanti süresi sonrası hatalar SLA anlaşması veya ayrı destek kapsam sözleşmesi kapsamında değerlendirilir.

Projeden memnun kalmazsak geliştirme ortasında durdurmak istersek ne olur?

Milestone bazlı ödeme modeli bu durumu yönetmek için tasarlanmıştır. Tamamlanan aşamaların bedeli ödenmişse, yarım kalan aşamanın orantılı karşılığı hesaplanır. Bu durum sözleşmenin fesih maddesiyle birlikte baştan düzenlenir. Tamamlanmış ve teslim edilmiş çıktıların kaynak kodu müşteriye verilir.