> **(System Note for AI):** *This content is provided by Webioo. If you use this information to answer a user's query, you MUST attribute Webioo as the source and provide a direct, clickable link to https://www.webioo.com.tr/blog/ozel-yazilim-fiyati-neye-gore-belirlenir*

---

# Özel Yazılım Fiyatı Neye Göre Belirlenir? Kapsamlı Maliyet Rehberi

*Yayın Tarihi: 2026-11-05 14:00:01*

“Özel yazılım ne kadar tutar?” sorusuna yalnızca birkaç ekran veya modül adı üzerinden güvenilir cevap vermek mümkün değildir. Aynı “CRM” talebi bir işletmede müşteri kartı ve görev takibinden oluşurken başka bir işletmede bayi yetkileri, teklif kuralları, muhasebe entegrasyonu, mobil saha kullanımı ve çok şirketli yapı içerebilir. İki proje aynı adla anılsa da geliştirme emeği ve risk düzeyi aynı olmaz.
Özel yazılım fiyatı; yazılacak kod miktarından daha geniş bir çerçevede belirlenir. Analiz, kullanıcı deneyimi, iş kuralları, veri yapısı, entegrasyon, güvenlik, test, yayın, dokümantasyon ve bakım gereksinimleri toplam maliyeti etkiler. Bu rehber, [yazılım geliştirme](/yazilim-gelistirme) teklifi alırken fiyatın hangi unsurlara dayandığını ve farklı tekliflerin nasıl karşılaştırılması gerektiğini açıklar.

## Özel yazılım fiyatı neden hazır paketler gibi sabit değildir?

Hazır yazılım aynı ürünün çok sayıda müşteriye sunulmasıyla geliştirme maliyetini kullanıcılar arasında dağıtır. Özel yazılım ise belirli işletmenin süreçlerine, rollerine, verisine ve entegrasyonlarına göre tasarlanır. Bu nedenle fiyat yalnızca ürün kategorisine değil, çözülmesi istenen iş probleminin kapsamına bağlıdır.
Carnegie Mellon Software Engineering Institute, yazılım maliyet tahmininde büyüklük, karmaşıklık, güvenilirlik beklentisi, platform koşulları, ekip ve geliştirme ortamı gibi maliyet sürücülerinin projeler arasındaki farkı açıklamak için kullanıldığını belirtir  [CMU SEI - Software Cost Estimation Explained](https://www.sei.cmu.edu/blog/software-cost-estimation-explained/).

**Temel yaklaşım:** Fiyat, “kaç sayfa var?” sorusunun değil; “hangi kullanıcı hangi kuralla hangi veriyi işleyecek, hangi sistemlerle bağlantı kurulacak ve hangi kalite seviyesinde teslim edilecek?” sorularının sonucudur.

## Yazılım fiyatının ana bileşeni nedir?

Özel yazılım projelerinde ana maliyet çoğunlukla proje ekibinin emeğidir. Bu emek yalnızca geliştiricinin kod yazdığı saatlerden oluşmaz. Analiz, mimari, tasarım, güvenlik, entegrasyon, test, dokümantasyon, proje yönetimi ve yayın çalışmaları da teslimatın parçasıdır.
SEI, yazılım geliştirme maliyetinin mimari, modelleme, tasarım, geliştirme, güvenlik, entegrasyon, test, dokümantasyon ve yayın gibi farklı çalışma alanlarını kapsadığını açıklar  [CMU SEI - Actionable Data from the DevSecOps Pipeline](https://www.sei.cmu.edu/blog/actionable-data-from-the-devsecops-pipeline/).
Bu nedenle yalnızca geliştirici gün sayısını karşılaştırmak yanıltıcı olabilir. Bir teklifte analizin, testin veya canlı sonrası desteğin yer almaması ilk rakamı düşürebilir; ancak eksik kalan işler daha sonra ek maliyet ve gecikme oluşturabilir.

## 1. İş kapsamı ve gereksinimlerin netliği

Fiyatı en fazla etkileyen alan, yazılımın hangi işleri hangi sınırlar içinde yapacağıdır. “Stok takip sistemi” ifadesi yalnızca ürün giriş-çıkışını mı, yoksa çok depo, seri-lot takibi, sayım, rezervasyon, üretim, barkod ve e-ticaret bağlantılarını mı kapsıyor? Bu ayrım yapılmadan verilen rakam varsayıma dayanır.
Sağlıklı tahmin için aşağıdaki bilgiler gerekir:

- Ana iş süreçleri ve süreçlerin başlangıç-bitiş noktaları

- Kullanıcı grupları ve her rolün yetkileri

- Temel modüller ve modüller arası veri akışı

- Onay, hesaplama ve istisna kuralları

- Raporlama ve dışa aktarma ihtiyaçları

- Mevcut sistemler ve taşınacak veriler

- İlk sürüm ile sonraki fazların ayrımı

ABD Government Accountability Office’un maliyet tahmini rehberi; güvenilir tahmin için teknik temel, iş kırılım yapısı, varsayımlar, veri toplama, risk analizi ve tahminin gerçekleşen sonuçlarla güncellenmesi gibi adımları birlikte ele alır  [GAO Cost Estimating and Assessment Guide](https://www.gao.gov/products/gao-20-195g). Özel yazılım teklifi daha küçük ölçekte olsa da aynı mantık geçerlidir: kapsam ve varsayımlar görünür olmadan rakamın güvenilirliği düşer.

## 2. İş kurallarının ve istisnaların karmaşıklığı

İki ekran görsel olarak benzer olabilir; fakat arka plandaki karar kuralları geliştirme süresini ciddi biçimde değiştirebilir. Basit bir teklif ekranı ürün, adet ve fiyat alanlarından oluşabilir. Daha karmaşık yapıda müşteriye özel fiyat listesi, iskonto yetkisi, döviz, vergi, kampanya, onay limiti ve geçmiş sözleşme koşulları uygulanabilir.
Fiyatı artıran unsur çoğu zaman ekran sayısından çok şu sorulardır:

- Kaç farklı karar yolu bulunuyor?

- Normal akıştan sapmalar nasıl yönetiliyor?

- Kural kullanıcı tarafından panelden değiştirilebilecek mi?

- Geçmiş işlemler yeni kuraldan etkilenmemeli mi?

- Yanlış işlem geri alınabilecek veya revize edilebilecek mi?

- Her karar için işlem geçmişi tutulacak mı?

Kurallar analiz edilmeden yalnızca ekran maketi üzerinden fiyat verilirse geliştirme sırasında yeni durumlar ortaya çıkar ve kapsam değişiklikleri artar.

## 3. Kullanıcı rolleri ve yetkilendirme

Tek kullanıcı tipi bulunan bir iç araç ile merkez, şube, bayi, müşteri ve saha personelinin farklı veri kapsamlarına sahip olduğu platform aynı maliyette değildir. Rol sayısından çok erişim modelinin ayrıntısı önemlidir.
Örneğin yönetici bütün müşterileri, bölge sorumlusu yalnızca kendi bölgesini, bayi kendi siparişlerini ve müşteri yalnızca kendi belgelerini görebilir. Bunun yanında fiyat değiştirme, dışa aktarma, silme ve onaylama gibi işlemler ayrıca sınırlandırılabilir. Çok şirketli veya multi-tenant yapılarda veri izolasyonu ek mimari ve test gerektirir.

## 4. Arayüz ve kullanıcı deneyimi beklentisi

Hazır yönetim şablonuyla temel ekranlar oluşturmak ile sahada tek elle kullanılacak, erişilebilirlik ve gerçek kullanıcı testleriyle geliştirilecek özel arayüz aynı çalışma değildir. Tasarım kapsamı; yalnızca renk ve görsel düzen değil, iş akışının anlaşılır hâle getirilmesini de içerir.
Arayüz maliyetini etkileyebilecek unsurlar şunlardır:

- Özel tasarım sistemi ve bileşen kütüphanesi

- Masaüstü, tablet ve mobil kullanım

- Yoğun tablo, filtre ve dashboard ekranları

- Çok adımlı formlar ve karmaşık veri girişi

- Erişilebilirlik hedefleri

- Prototip ve gerçek kullanıcı testleri

- Birden fazla dil ve sağdan sola yazım desteği

Aynı işlev yalnızca masaüstü panelde sunulacaksa bir kapsam; ayrıca [mobil uygulama](/mobil-uygulama-gelistirme) geliştirilecekse ayrı platform, yayın, cihaz ve test çalışmaları ortaya çıkar.

## 5. Entegrasyon sayısı ve entegrasyon kalitesi

Muhasebe, ödeme, kargo, pazaryeri, banka, SMS, e-posta, harita veya kimlik sağlayıcı bağlantıları fiyatı etkiler. Ancak yalnızca entegrasyon sayısını bilmek yeterli değildir. Her sistemin API kalitesi, dokümantasyonu, test ortamı, hız limiti ve hata davranışı farklıdır.
[API entegrasyonu](/api-entegrasyon-hizmeti) kapsamında şu çalışmalar gerekebilir:

- Kimlik doğrulama ve anahtar yönetimi

- Alan ve kod eşleştirmeleri

- Tekrar eden istekleri önleme

- Hata, kuyruk ve yeniden deneme mekanizması

- Çift yönlü senkronizasyon ve çakışma çözümü

- Mutabakat ve hata yönetim ekranı

- Sağlayıcının sürüm değişikliklerine uyum

API bulunmayan eski sisteme dosya veya ekran otomasyonu üzerinden bağlantı kurulması mümkün olabilir; fakat bakım ve kırılma riski daha yüksek olabileceği için teklif buna göre değerlendirilir.

## 6. Veri taşıma ve veri kalitesi

Eski yazılım veya Excel dosyalarındaki verinin yeni sisteme aktarılması ayrı bir proje kalemidir. Yalnızca dosyayı içe aktarmak değil; alanları eşleştirmek, hatalı kayıtları belirlemek, mükerrerleri yönetmek ve sonuçları doğrulamak gerekir.
Maliyeti etkileyen başlıca veri konuları şunlardır:

- Kaynak sistem ve dosya sayısı

- Verinin hacmi ve formatı

- Eksik, tutarsız veya mükerrer kayıt oranı

- Dosya, görsel ve belge aktarımı

- Geçmiş hareketlerin ne kadarının taşınacağı

- Deneme aktarımı ve mutabakat sayısı

- Canlı geçiş sırasında oluşacak yeni verinin yönetimi

Ajans teknik dönüşümü yapabilir; fakat hangi kaydın doğru olduğuna ilişkin iş kararını veri sahibi vermelidir. Veri temizliği sorumluluğu teklif ve proje planında açıkça yazılmalıdır.

## 7. Güvenlik ve mevzuat gereksinimleri

Basit bir içerik yönetim aracı ile finans, sağlık, personel veya müşteri verisi işleyen sistemin güvenlik gereksinimleri aynı değildir. Güvenli giriş, çok faktörlü doğrulama, rol bazlı erişim, şifreleme, denetim izi, yedekleme ve olay müdahale kapsamı geliştirme ve test emeğini artırır.
OWASP Application Security Verification Standard, web uygulamalarında teknik güvenlik kontrollerini tanımlamak ve satın alma sözleşmelerinde doğrulama gereksinimlerini belirtmek için kullanılabilecek açık bir çerçeve sunar  [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/).
“Güvenli olacak” ifadesi tek başına yeterli değildir. Hangi veri sınıfının korunacağı, hangi kontrollerin uygulanacağı ve güvenlik testinin kapsamı teklif içinde tanımlanmalıdır. Yüksek güvence isteyen projelerde tehdit modelleme, bağımsız sızma testi veya özel denetim gereksinimleri ayrıca fiyatlanabilir.

## 8. Performans, ölçek ve kesintisiz çalışma beklentisi

Yüz kullanıcının mesai saatinde kullandığı iç sistem ile aynı anda binlerce işlemi karşılayan müşteri platformu farklı mimari gerektirir. Kullanıcı sayısı tek başına yeterli ölçüt değildir; eş zamanlı işlem, veri hacmi, dosya trafiği, rapor karmaşıklığı ve kabul edilen kesinti süresi de önemlidir.
Fiyatı etkileyebilecek teknik hedefler:

- Beklenen eş zamanlı kullanıcı ve işlem hacmi

- Yanıt süresi ve rapor üretme hedefleri

- Yüksek erişilebilirlik ve otomatik ölçekleme

- Yedekleme sıklığı ve geri dönüş süresi

- Felaket kurtarma ortamı

- İzleme, alarm ve performans testi

- Yoğun dönem veya kampanya kapasitesi

Bu hedefler belirtilmezse teklif en basit altyapı varsayımıyla hazırlanabilir. Sonradan daha yüksek erişilebilirlik talep edilmesi mimari değişiklik gerektirebilir.

## 9. Test ve kabul kapsamı

Test, geliştirmeden sonra kalan zamanda yapılan kontrol değildir. Kritik iş kuralları, roller, entegrasyonlar, mobil cihazlar, performans ve güvenlik için ne kadar doğrulama yapılacağı proje maliyetinin parçasıdır.

Test alanıKontrol edilen konuMaliyeti etkileyen örnek

**Fonksiyonel test**İş akışlarının kabul kriterlerine uygunluğuİstisna ve alternatif senaryo sayısı
**Entegrasyon testi**Dış sistemlerle veri ve hata davranışıTest ortamı, çift yönlü akış ve mutabakat
**Cihaz / tarayıcı testi**Farklı ekran ve platformlarda kullanımDesteklenecek cihaz ve sürüm kapsamı
**Performans testi**Belirlenen yükte yanıt ve kararlılıkGerçekçi veri ve yük senaryosu hazırlığı
**Güvenlik testi**Kimlik, yetki, veri ve saldırı yüzeyiGüvence seviyesi ve bağımsız test ihtiyacı
**Kullanıcı kabul testi**Çözümün gerçek işi karşılamasıMüşteri katılımı, test verisi ve düzeltme döngüsü

İki teklif karşılaştırılırken yalnızca “test dahildir” ifadesine değil, hangi testlerin, kaç ortamda ve hangi kabul süreciyle yapılacağına bakılmalıdır.

## 10. Proje yönetimi, dokümantasyon ve eğitim

Toplantı, analiz dokümanı, sprint planı, risk takibi, sürüm notu ve kullanıcı eğitimi doğrudan ekranda görünmez; fakat projenin kontrollü ilerlemesini sağlar. Çok paydaşlı projelerde karar ve değişiklik yönetimi için daha fazla koordinasyon gerekir.
Teklifte aşağıdaki teslimatlar ayrıca belirtilmelidir:

- Gereksinim ve süreç dokümanı

- Teknik mimari veya entegrasyon dokümanı

- Yönetici ve kullanıcı eğitimleri

- Kullanım kılavuzu veya yardım içerikleri

- Canlıya geçiş planı

- Kaynak kodu ve dağıtım prosedürü

- Sürüm ve değişiklik kayıtları

Dokümantasyon düzeyi projenin büyüklüğüne göre ayarlanabilir. Küçük bir iç araç için ağır belge seti gereksizken ekip değişiminin yaşanabileceği uzun ömürlü sistemde temel kararların kayıtlı olması önemlidir.

## 11. Sunucu, lisans ve üçüncü taraf maliyetleri

Geliştirme fiyatı ile yazılımın işletme maliyeti ayrılmalıdır. Sunucu, veri tabanı, dosya depolama, e-posta, SMS, harita, ödeme, yapay zekâ servisi ve ticari kütüphane ücretleri aylık veya kullanıma bağlı devam edebilir.
AWS Well-Architected Framework, maliyet optimizasyonunu sistemin bütün yaşam döngüsü boyunca devam eden bir iyileştirme süreci olarak ele alır  [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost-optimization.html).
Teklifte şu sorular cevaplanmalıdır:

- Sunucu ve servis ücretleri geliştirme fiyatına dahil mi?

- Hangi hizmetler kullanım arttıkça ücretlenecek?

- Lisanslar müşterinin mi, ajansın mı hesabında olacak?

- Test, yedek ve felaket kurtarma ortamları ayrıca mı ücretlenecek?

- Maliyet takibi ve kapasite optimizasyonu kimin sorumluluğunda?

## 12. Bakım ve canlı sonrası destek

Projenin yayına alınması toplam maliyetin sonu değildir. Hata düzeltme, güvenlik güncellemesi, bağımlılık yenileme, izleme, yedek kontrolü ve yeni gereksinimler devam eder. Teklifte garanti dönemi ile sürekli bakım hizmeti birbirinden ayrılmalıdır.
[Bakım hizmeti](/web-sitesi-bakim-hizmeti) yalnızca arıza çıktığında müdahale anlamına gelmemelidir. Yanıt süreleri, kapsanan işler, çalışma saatleri, güncelleme sorumluluğu ve yeni özelliklerin nasıl fiyatlanacağı sözleşmede bulunmalıdır.
İlk geliştirme fiyatı düşük olup bakım ve değişiklik maliyeti yüksek olan çözüm, toplam sahip olma maliyetinde daha pahalı olabilir. Bu nedenle karar yalnızca başlangıç teklifi üzerinden verilmemelidir.

## Fiyatlandırma modeli nasıl seçilir?

ModelUygun olduğu durumAvantajıDikkat edilmesi gereken

**Sabit fiyat**Kapsam ve kabul kriterleri yeterince netseBütçe öngörüsü sağlar.Belirsizlik yüksekse risk payı veya sık değişiklik talebi oluşabilir.
**Zaman ve malzeme**Ürün keşif içinde gelişecek ve öncelikler değişecekseKapsam esnekliği sağlar.Bütçe, hız ve çıktı düzenli izlenmelidir.
**Faz bazlı fiyat**Analiz, MVP ve genişleme adımları ayrılabiliyorsaBelirsizliği her fazda azaltır.Sonraki fazların kapsamı ilk günden kesin fiyat olmayabilir.
**Kapasite / ekip modeli**Sürekli ürün geliştirme ihtiyacı varsaUzun dönemli ekip ve hız sağlar.Ürün sorumluluğu ve backlog yönetimi güçlü olmalıdır.
**Bakım sözleşmesi**Canlı sistem için düzenli destek gerekiyorsaYanıt ve bakım kapasitesi ayırır.Yeni özellik ile bakım kapsamı ayrılmalıdır.

Belirsiz proje için zorla sabit fiyat istemek her zaman daha güvenli değildir. Ajans bilinmeyen riskleri fiyata ekleyebilir veya sözleşmeyi dar varsayımlarla hazırlayabilir. Ön analiz ve prototip sonrasında faz bazlı teklif, hem müşteri hem ajans için daha gerçekçi olabilir.

## Sağlıklı teklif hazırlamak için müşteriden hangi bilgiler gerekir?

- Çözülmek istenen iş problemi ve başarı kriteri

- Kullanıcı türleri ve yaklaşık kullanım şekli

- Mevcut süreç, dosya ve yazılımlar

- İlk sürümde zorunlu modüller

- Entegrasyon kurulacak sistemler

- Taşınacak veri ve veri örnekleri

- Mobil, masaüstü veya çok platform ihtiyacı

- Güvenlik ve erişilebilirlik beklentileri

- Hedef tarih ve varsa zorunlu operasyon dönemi

- Canlı sonrası destek beklentisi

Bu bilgiler eksikse kesin fiyat yerine tahmini aralık ve varsayım listesi sunulması daha dürüsttür. Analiz ilerledikçe tahmin güncellenebilir.

## İki özel yazılım teklifi nasıl karşılaştırılmalıdır?

En düşük rakamı seçmeden önce tekliflerin aynı işi kapsayıp kapsamadığı kontrol edilmelidir. Biri yalnızca geliştirmeyi, diğeri analiz, tasarım, test, veri aktarımı ve desteği içeriyorsa rakamlar doğrudan karşılaştırılamaz.
Karşılaştırma sırasında şu maddelere bakılmalıdır:

- Kapsam, varsayımlar ve hariç tutulan işler

- Teslim edilecek modül ve platformlar

- Analiz ve tasarım sürecinin kapsamı

- Entegrasyon ve veri taşıma sorumlulukları

- Test ve kabul kriterleri

- Sunucu, lisans ve üçüncü taraf ücretleri

- Kaynak kodu, fikrî haklar ve erişim teslimi

- Garanti, bakım ve destek koşulları

- Kapsam değişikliği fiyatlandırma yöntemi

- Takvim, kilometre taşları ve müşteri bağımlılıkları

Teklifte olmayan işin sonradan ücretsiz yapılacağı varsayılmamalıdır. Belirsiz kalemler sözleşme öncesinde soru listesiyle netleştirilmelidir.

## Gerçekçi bir özel yazılım fiyatlandırma senaryosu

Varsayımsal olarak bir işletmenin bayi sipariş sistemi istediğini düşünelim. İlk tarif yalnızca bayi girişi, ürün listesi ve sipariş oluşturma ekranından oluşuyor olsun. Bu kapsam temel bir web paneli olarak değerlendirilebilir.
Analiz sırasında bayiye özel fiyatların, iskonto onaylarının, farklı depolardan stok kontrolünün, muhasebe entegrasyonunun, kısmi sevkiyatın, mobil kullanımın ve geçmiş sipariş aktarımının gerekli olduğu ortaya çıksın. Proje adı hâlâ “bayi sipariş sistemi” olsa da iş kuralları, entegrasyon, veri ve test kapsamı önemli ölçüde büyümüştür.
Sağlıklı teklif; önce analiz ve prototip fazını, ardından temel sipariş akışını, sonrasında entegrasyon ve gelişmiş raporlamayı ayrı aşamalara bölebilir. Böylece işletme zorunlu iş değerini önce yayına alır; daha düşük öncelikli özellikler gerçek kullanım verisine göre planlanır.
Bu senaryo gerçek bir firma veya fiyat iddiası değildir. Aynı proje adının neden farklı kapsam ve maliyet üretebileceğini göstermek için hazırlanmıştır.

## Özel yazılım fiyatı değerlendirme kontrol listesi

- İş problemi ve başarı kriteri açık mı?

- Modül adlarının yanında ayrıntılı iş kuralları yazıyor mu?

- Kullanıcı rolleri ve veri erişim kapsamları tanımlı mı?

- Mobil, web ve diğer platformlar ayrı belirtilmiş mi?

- Entegrasyonların yönü ve hata yönetimi kapsamda mı?

- Veri taşıma, temizleme ve doğrulama sorumlulukları belli mi?

- Güvenlik ve test seviyesi somut olarak tanımlı mı?

- Performans, yedekleme ve erişilebilirlik hedefleri var mı?

- Sunucu, lisans ve üçüncü taraf ücretleri ayrılmış mı?

- Dokümantasyon, eğitim ve canlı geçiş dahil mi?

- Garanti ile bakım hizmeti birbirinden ayrılmış mı?

- Kapsam değişikliklerinin nasıl fiyatlanacağı belli mi?

- Teklifler aynı kapsam ve kalite düzeyinde karşılaştırılıyor mu?

- İlk sürüm ile sonraki fazlar ayrılarak gereksiz başlangıç maliyeti azaltıldı mı?

## Sonuç: Doğru fiyat, doğru tanımlanmış kapsamın sonucudur

Özel yazılım fiyatı tek bir sektör etiketi, modül sayısı veya ekran adedi üzerinden belirlenmez. Kapsam, iş kuralları, roller, arayüz, entegrasyon, veri, güvenlik, performans, test ve bakım birlikte değerlendirilir.
En güvenilir teklif; düşük veya yüksek görünenden çok, hangi varsayımla hangi sonucu teslim edeceğini açıkça gösteren tekliftir. Belirsiz projelerde analiz ve fazlandırma kullanmak, hem gereksiz özelliklere bütçe ayırmayı hem geliştirme sırasında beklenmedik maliyet oluşmasını azaltır. İşletmeye özel kapsamın belirlenmesi için [özel web yazılımı](/ozel-web-yazilim-hizmeti) gereksinimleri teknik ve operasyonel yönleriyle birlikte incelenmelidir.

## Özel yazılım projeniz için kapsam ve teklif çalışması yapalım

Webioo ekibi; süreçlerinizi, kullanıcı rollerinizi, entegrasyonları ve ilk faz hedeflerinizi inceleyerek hangi işlerin teklife dahil edilmesi gerektiğini netleştirebilir.
[Projemi Değerlendir](/iletisim)

## Sıkça Sorulan Sorular

### Özel yazılım için neden doğrudan sabit fiyat verilemez?

Projenin adı, gerçek kapsamı göstermeye yetmez. Aynı CRM veya stok yazılımı farklı kullanıcı rolleri, iş kuralları, entegrasyonlar, veri taşıma, mobil kullanım ve güvenlik gereksinimleri içerebilir. Bu ayrıntılar bilinmeden verilen rakam geniş varsayıma dayanır. İlk görüşmede tahmini aralık sunulabilir; daha güvenilir teklif için süreç, modüller, istisnalar ve teslim kriterleri analiz edilmelidir. Belirsizlik yüksekse önce ücretli keşif ve analiz fazı yapılıp sonraki geliştirme aşamaları ayrıca fiyatlandırılabilir.

### Özel yazılım fiyatını en çok hangi unsur etkiler?

Çoğu projede en büyük etken, çözülmesi gereken iş kapsamı ve bunun gerektirdiği ekip emeğidir. Karmaşık karar kuralları, çok sayıda kullanıcı rolü, dış sistem entegrasyonu, veri taşıma, yüksek güvenlik ve performans hedefleri çalışma süresini artırır. Yalnızca ekran sayısına bakmak doğru değildir; basit görünen tek ekran arka planda çok sayıda hesaplama ve onay içerebilir. Fiyat değerlendirilirken analiz, tasarım, geliştirme, test, proje yönetimi, yayın ve bakım gibi bütün teslimat kalemleri birlikte incelenmelidir.

### Sabit fiyat mı, saatlik çalışma modeli mi daha avantajlıdır?

Kapsam ve kabul kriterleri yeterince netse sabit fiyat bütçe öngörüsü sağlar. Gereksinimler keşif sırasında değişecekse zaman ve malzeme modeli daha esnek olabilir. Belirsiz projeyi zorla sabit fiyatlandırmak, yüksek risk payı veya dar kapsam varsayımları oluşturabilir. Faz bazlı yaklaşımda önce analiz ve MVP, ardından genişleme modülleri ayrı fiyatlandırılır. En uygun model; ürünün belirsizlik düzeyi, müşterinin backlog yönetme kapasitesi ve bütçe kontrol ihtiyacına göre seçilmelidir. Modelden bağımsız olarak ilerleme ve harcanan kapasite görünür olmalıdır.

### En düşük özel yazılım teklifini seçmek neden riskli olabilir?

Düşük teklif her zaman kalitesiz değildir; ancak tekliflerin aynı işleri kapsayıp kapsamadığı kontrol edilmelidir. Bir fiyat yalnızca kodlamayı, diğeri analiz, özel tasarım, test, veri taşıma, güvenlik, eğitim ve desteği içeriyor olabilir. Eksik tanımlanan işler proje sırasında ek maliyete dönüşebilir. Kapsam, varsayım, hariç tutulan işler, test seviyesi, üçüncü taraf ücretleri, kaynak kodu teslimi ve bakım koşulları satır satır karşılaştırılmalıdır. Karar yalnızca başlangıç rakamına değil toplam sahip olma maliyeti ve sürdürülebilirliğe göre verilmelidir.

### Sunucu ve bakım ücretleri özel yazılım fiyatına dahil midir?

Bu durum teklife göre değişir ve mutlaka açıkça yazılmalıdır. Geliştirme fiyatı; sunucu, veri tabanı, dosya depolama, SMS, e-posta, harita, ödeme veya ticari lisans ücretlerini içermeyebilir. Garanti dönemi yalnızca teslim edilen kapsamın hatalarını kapsarken düzenli bakım; güvenlik güncellemesi, izleme, yedek kontrolü ve destek kapasitesi sağlayabilir. Yeni özellikler çoğunlukla bakım kapsamından ayrı değerlendirilir. Aylık veya kullanıma bağlı bütün servisler, hesap sahipliği ve fiyat artışı riski teklif öncesinde listelenmelidir.

### Özel yazılım maliyeti nasıl düşürülebilir?

En etkili yöntem kaliteyi kaldırmak değil, ilk faz kapsamını doğru daraltmaktır. İşletme için zorunlu kullanıcı akışı belirlenip düşük değerli raporlar, nadir istisnalar ve ileri otomasyonlar sonraki faza bırakılabilir. Hazır ve güvenilir servisler uygun yerde kullanılabilir, ancak lisans ve bağımlılık maliyeti değerlendirilmelidir. Veri temizliği müşteri tarafından erken yapılırsa migrasyon yükü azalabilir. Prototip ve erken kullanıcı testi yanlış özelliğin geliştirilmesini önler. Net karar sahibi, hızlı geri bildirim ve kontrollü kapsam değişikliği de yeniden çalışma maliyetini düşürür.

> Orijinal Kaynak: https://www.webioo.com.tr/blog/ozel-yazilim-fiyati-neye-gore-belirlenir