Özel Yazılım Fiyatları Nasıl Belirlenir? Maliyeti Ne Etkiler

Özel Yazılım Fiyatları Nasıl Belirlenir?

Özel yazılım fiyatı kullanıcı sayısı, modül kapsamı ve API entegrasyonuna göre belirlenir. Mobil/PWA ihtiyacı, raporlama, güvenlik ve bakım planı da toplamı doğrudan etkiler. Fiyat vermeden önce bu kalemleri tek tek netleştirir, teklifin nasıl oluştuğunu şeffaf biçimde gösteririz.

Kullanıcı sayısının bütçeye doğrudan etkisi

Sisteme aynı anda girecek kişi sayısı, yetki katmanları ve yoğunluğun hangi saatlerde artacağı ilk bakılan yerlerdir. Sabah 9’da 40 kişinin giriş yaptığı bir yapı ile gün içine yayılmış 8 kişilik bir kullanım aynı emekle kurulmaz. Oturum yönetimi, ekran yükü ve performans testi baştan değişir. Alt yapı yatırımını ve maliyetini büyük oranda aktif kullanıcı sayısı ve etkileşim sayıları belirler. Ayrıca CRM de tutulacak öngörülen data sayısı ve onunla bağlantılı dosya tipleri ve boyutları berliler. 

Kullanıcı sayısı artınca sadece lisans hesabı büyümez; veri modeli de genişler. Biz önce aktif kullanıcıyı, sonra aynı anda kaç kişinin çalışacağını sorarız. 

Modül kapsamı nasıl hesaplanır?

Modül dediğimiz parçayı sistem içinde kendi başına çalışan bir bölüm olarak ele alıyoruz. Sipariş, cari, stok, teklif, randevu, personel, sevkiyat ya da servis takibi ayrı ayrı iş mantığı ister. Tek ekran gibi görünen alanın arkasında filtre, kural ve onay akışı varsa iş uzar.

Modül sayısı çoğaldıkça analize ayırdığımız gün de doğal olarak uzuyor. Çünkü her parçanın diğerleriyle nasıl konuşacağı ayrıca belirleniyor. Bir stok hareketi cari hesabı etkiliyorsa, satış kaydı faturayı tetikliyorsa, süreçler birbirine bağlanmış demektir. Bağlantı sayısı çoğaldıkça ayırdığımız mesai de büyüyor.

Modül tipi	Genelde ne içerir	Fiyata etkisi
Basit modül	Tek ekran, sınırlı kayıt, az kural	Analiz ve geliştirme süresi daha kısa olur
Orta seviye modül	Listeleme, filtreleme, yetki, bildirim	Geliştirme yükü orta seviyeye çıkar
Karmaşık modül	Birden çok ekran, iş akışı, onay, entegrasyon	Test ve bakım yükü belirgin biçimde artar

API entegrasyonu neden ayrı yazılır?

Farklı yazılımlar arasında veri akışını API köprüleriyle kuruyoruz. Muhasebe programı, e-ticaret altyapısı, kargo servisi, SMS servisi, ödeme sistemi ya da CRM ile bağlantı gerekiyorsa işin içine entegrasyon giriyor. Sadece veri gönderip almak yetmiyor; hata kaydı, eşleme ve tekrar deneme senaryoları da gerekiyor.

Biz entegrasyonu tek bağlantı gibi görmüyoruz. Her sistemin veri yapısı farklı. Bir tarafta “müşteri adı” olan alan, diğer tarafta “ünvan” olabilir; tarih formatı da tutmayabilir. Bu ayrımlar ilk gün çözülmezse canlıda hata çıkar. Fiyat, bu temizliğin kapsamına göre değişir.

Hazır bağlantı varsa süre kısalır. Özel geliştirme gerekiyorsa analiz, test ve devreye alma uzar. API içeren işlerde bütçeyi çoğu zaman kod satırı değil, bağlanacak sistem sayısı ve teknik durumu belirler.

Mobil uygulama mı, PWA mı?

Bizim için cevap PWA. Çünkü PWA tarayıcıdan çalışan, telefonda ve birçok bilgisayarda uygulama gibi kullanılan yapıdır. Bildirim alabilir, ana ekrana eklenebilir.

Mobil uygulama ise App Store ve Google Play süreçlerini, cihaz izinlerini ve ayrı sürüm yönetimini beraberinde getirir. Kamera, konum, barkod okuma, Bluetooth ya da cihaz donanımına erişim gerekiyorsa mobil uygulama öne çıkar. Seçilen altyapı maliyet tablosunu baştan kurar.

İhtiyaç	PWA	Mobil uygulama
Kurulum kolaylığı	Tarayıcıdan açılır, hızlı devreye alınır	Mağaza süreçleri gerekir
Cihaz özelliklerine erişim	Sınırlı	Daha geniş
Güncelleme yönetimi	Merkezden daha kolay yapılır	Yeni sürüm yayınlamak gerekir
Proje maliyeti	Genellikle daha düşük	Genellikle daha yüksek

Raporlama seviyesi nasıl fark yaratır?

Ekrana alt alta veri dizmekle iş çözülmüyor; filtreler ve grafikler geldikçe emek artıyor. Filtreler, tarih kıyasları, grafikler, dışa aktarma ve рол bazlı görünüm isteniyorsa iş genişliyor. Saha ekibi başka veri görür, yönetim başka veri görür, muhasebe başka alanlara bakar. Aynı tablo herkese yetmez.

Basit raporda toplamlar görünürken, gelişmiş yapıda dönem karşılaştırması ve uyarı eşikleri de yer alır. Bir müşterimiz 4 tablo yeter sanmıştı; toplantıda 11 ayrı rapor ihtiyacı çıktı. Bu fark, teklifteki geliştirme payını hemen yukarı çeker.

Güvenlik beklentisi hangi kalemleri değiştirir?

Güvenliği parola ekranıyla sınırlamıyoruz. Rol bazlı yetkilendirme, iki aşamalı doğrulama, işlem kayıtları, kritik işlem onayı, oturum süresi ve yedekleme planı birlikte düşünülüyor. Kullanıcı neyi görecek, neyi değiştirecek, hangi hareket kayda düşecek; bunlar netleşmeli.

KVKK uyumu, log takibi ve hassas veri koruması gerekiyorsa kapsam büyür. Sağlık, eğitim, finans ve personel verisi tutan projelerde bu katmanı hafif kurmuyoruz. Bizde güvenlik sonradan eklenen parça değil, mimarinin içinde yer alıyor.

Güvenlik ihtiyacı	İçerik	Etki
Temel güvenlik	Kullanıcı adı, parola, yetki sistemi	Standart geliştirme yükü
Orta seviye güvenlik	Oturum izleme, log kaydı, kritik işlem onayı	Ek analiz ve test gerektirir
Yüksek güvenlik	İleri yetkilendirme, şifreleme, yedekleme, denetim izi	Altyapı ve bakım maliyeti artar

Bakım ve destek neden teklifin parçasıdır?

Yazılım teslim edilince iş bitmiyor. Sunucu takibi, hata düzeltmeleri, güvenlik güncellemeleri, performans iyileştirmeleri ve küçük geliştirmeler devam ediyor. Güncellenmeyen yazılımlar kısa sürede tıkanıyor; kütüphane eskimesi ve sunucu uyumsuzluğu bunu hızlandırıyor.

Bakım planını ayrı kalem olarak konuşuyoruz. Her projede aynı destek düzeyi gerekmiyor. Bazı müşteriler saat bazlı destek istiyor, bazıları aylık paket seçiyor, bazı işlerde yalnız kritik müdahale yeterli oluyor. Bu fark özel yazılım fiyatını doğrudan değiştirir.

Teklif nasıl hesaplanır?

Teklif çıkarırken önce kapsamı parçalıyoruz. Hangi ekranlar yapılacak, hangi roller olacak, hangi entegrasyonlar kurulacak? Mobil gerekecek mi, raporlama ne kadar detaylı olacak, güvenlik seviyesi ne olmalı? Bakım süresi nasıl işleyecek; hepsi tek tek yazılıyor. Sonra her başlık için analiz, tasarım, geliştirme, test ve teslim süresi belirleniyor.

Kapsam netleşmeden kodlamaya başlamıyoruz. Eksik bilgi varsa varsayımla fiyat yazmıyoruz. Çünkü varsayım, sonra yeni maliyet doğuruyor. Teklif listesinde her modülün geliştirme saati ve teknik karşılığı ayrı görünmeli.

1. İşe doğrudan kapsamlı bir ihtiyaç analiziyle başlarız.
2. Kapsamı ekranlara, modüllere ve iş akışlarına böleriz.
3. Entegrasyon gereksinimleri listelenir.
4. Teknik mimari seçilir.
5. Test ve yayına alma adımları planlanır.
6. Bakım ve destek modeli tanımlanır.

Fiyatı yükselten ya da düşüren durumlar

Birbirine benzeyen iki proje arasında ciddi fiyat farkı çıkabiliyor. Sebep çoğu zaman detaylarda. Kullanıcı sayısı az olsa da çok sayıda yetki seviyesi varsa iş büyür. Ekran sayısı az görünse de her ekranın ayrı onay akışı varsa maliyet artar. Yapı sade ve veri akışı kısa ise teklif aşağı iner.

Mevcut sistemin durumu da belirleyici. Sıfırdan geliştirme ile eski yazılımın üstüne ekleme yapmak aynı değil. Eski veriyi taşımak, uyumsuz alanları eşleştirmek ve işleyişi bozmadan geçiş yapmak ekstra plan istiyor. Böyle projelerde fiyat, yalnız yeni kod miktarıyla okunmaz.

Durum	Fiyatı nasıl etkiler?
Sıfırdan proje	Analiz ve kurulum net ama kapsam büyüdükçe maliyet artar
Mevcut sisteme ek geliştirme	Var olan yapıyı çözmek için ek zaman gerekir
Veri taşıma olan proje	Temizleme, eşleme ve kontrol aşamaları ek yük getirir
Çoklu entegrasyon	Her dış sistem ayrı test ve hata yönetimi ister

Teklifte hangi bilgiler net olmalıdır?

Net bir bütçe çıkarmak istiyorsak masadaki işin sınırlarını baştan çizmeliyiz. Biz müşterilerle konuşurken önce işin ne yaptığını, sonra neyi neden yaptığını sorarız. Aynı isimle anılan iki süreç pratikte farklı olabilir. “Sipariş takibi” denildiğinde bazen yalnız kayıt tutulur, bazen stok, fatura, kargo ve bildirim de işin içine girer.

En az şu bilgiler netleşmelidir:

• Kullanıcı sayısı ve kullanıcı rolleri
• Yapılacak ekran ve modül sayısı
• API ya da dış sistem bağlantıları
• Mobil uygulama ya da PWA ihtiyacı
• Raporlama ve dışa aktarma beklentisi
• Güvenlik, yetki ve kayıt tutma gereksinimi
• Bakım, destek ve güncelleme süresi
• Veri taşıma veya mevcut sisteme entegrasyon durumu

Aynı proje neden farklı teklif alır?

İki müşteri aynı işi istediğini söyler; ama biri süreci yalnız içeride kullanacak, diğeri dış müşteriye açacak olabilir. Biri haftada bir rapor isteyecek, diğeri anlık panel talep edecek olabilir. Biri tek dille çalışacak, diğeri çok dilli yapı gerektirebilir. Bu ayrımlar tasarım ve geliştirme süresini değiştirir.

Fiyat farkını keyfimizce değil, arkadaki teknik işin boyutuna bakarak belirliyoruz. Biz ilk görüşmede talebi genel çerçevede dinler, sonra işi parçalara ayırırız. Fiyat bu parçaların toplamından çıkar. Sonradan sürpriz maliyet çıkmaması için bunu tercih ediyoruz.

Hazır yazılım ile özel yazılım arasındaki fark

Hazır paketler daha hızlı kurulur; ama herkese aynı mantıkla çalışır. Özel geliştirme ise işletmenin akışına göre şekillenir. Süreç tek düze ise hazır paket yeterli olabilir. Akış dallanıyor, onay mekanizması değişiyor, farklı departmanlar aynı veri üzerinde çalışıyorsa özel yazılım gerekir.

Kriter	Hazır yazılım	Özel yazılım
Kurulum süresi	Daha kısa	Analize bağlı
İş uyumu	Sınırlı	İşleyişe göre kurulur
İlk maliyet	Genelde daha düşük	İhtiyaca göre değişir
Uzun vadeli esneklik	Kısıtlı olabilir	Yüksek olabilir

Bakım kapsamı içinde neler olabilir?

Bakım yalnız hata düzeltme değildir. Küçük geliştirmeler, sürüm uyarlamaları, yedek kontrolü, performans izleme ve güvenlik yamaları da bu pakete girebilir. Hangi kalemlerin dahil olduğu baştan yazılmalı. Aksi halde “bakım var” cümlesi iki taraf için farklı şeyler anlatır.

Bakım anlaşmasını açık tutuyoruz. Müdahale süresi, destek kanalı, aylık sınır, ek işlerin nasıl fiyatlanacağı ve acil durum prosedürü önceden belirlenir. Böylece proje yayına geçtikten sonra iletişim tarafında boşluk kalmaz.

Şeffaf teklif neden güven sağlar?

Şeffaf teklif sadece rakam göstermek değildir. Hangi iş için hangi süre ayrıldığı, hangi kalemin neden yer aldığı ve nelerin kapsam dışında bırakıldığı açık yazılır. Müşteri neyi satın aldığını, biz de neyi teslim edeceğimizi baştan biliriz.

Teklifi pazarlık aracı değil, işin yol haritası olarak hazırlıyoruz. Kullanıcı sayısı, modül kapsamı, API entegrasyonu, mobil ya da PWA ihtiyacı netleşmeden verilen rakam eksik kalır. Raporlama, güvenlik ve bakım planı da netleşmeden verilen rakam eksik kalır. Özel yazılım fiyatı ancak bu başlıklarla doğru okunur.

Veri migrasyonu ve temizleme çalışmaları

Mevcut sistemden yeni yapıya veri taşınacaksa, fiyat doğrudan etkilenir. Çünkü iş yalnızca kayıtları aktarmak değildir; alan eşleme, eksik veriyi tamamlama, tekrar eden kayıtları ayıklama ve tarih formatlarını düzeltme gerekir. Beş bin satırla yarım milyon satırın işi aynı sürmez.

Biz bu aşamada önce verinin yapısını kontrol ediyoruz. Müşteri kartları, sipariş geçmişi, stok hareketleri, kullanıcı rolleri ve ek dosyalar ayrı ayrı değerlendirilir. Eski sistemde tek alanın farklı amaçlarla kullanıldığı çok olur. “Telefon” alanına cep telefonu, sabit hat ve not girilmişse temizlik uzar.

Basit aktarım ile kontrollü temizleme arasında ciddi fark vardır:

İş tipi	Ne yapılır?	Fiyat etkisi
Basit aktarım	Veri olduğu gibi yeni sisteme taşınır	Düşük
Alan eşleştirmeli aktarım	Eski alanlar yeni yapıya bağlanır	Orta
Temizlemeli aktarım	Eksik, hatalı ve tekrar eden kayıtlar ayıklanır	Yüksek

Özellikle muhasebe, sağlık ve eğitim projelerinde veri temizliği kritik olur. Yanlış aktarılmış tarih ya da hatalı bağlanmış müşteri kaydı, sonra raporu bozar. Bu yüzden veri migrasyonunu ayrı test senaryolarıyla ele alıyoruz. Deneme aktarımı yapılmadan canlı geçişe çıkmıyoruz.

Tasarım sistemi ve kullanıcı deneyimi beklentisi

Arayüzün kaç ekran olduğu kadar hangi düzeni istediğiniz de bütçeyi değiştirir. Hazır şablonla ilerlenen işlerde süre kısalır. Kuruma özel tasarım sistemi kurulduğunda buton davranışları, renk seti, tipografi ve ekran geçişleri tek tek ele alınır. Bu kalem çoğu zaman hafife alınıyor.

Biz kullanıcı deneyimini yalnız görsellik olarak görmüyoruz. Bir formda hangi alanın önce geldiği, hata mesajının nasıl yazıldığı, mobilde menünün nasıl açıldığı çalışma süresini belirliyor. Masaüstünde ne kadar yoğun bilgi gösterileceği de çalışma süresini belirliyor. Bir yönetici panelinde 8 tıklamayla yapılan iş, iyi kurgulanırsa 3 tıklamaya iner. Fark orada.

Standart arayüz ile özel arayüz arasındaki fark

• Standart arayüz: Mevcut kalıp üzerinden birkaç renk ve logo uyarlaması yapılır.
• Özel arayüz: Ekran akışı iş sürecine göre yeniden kurulur.
• Çok dilli arayüz: Metin uzunlukları ve yerleşimler ayrıca test edilir.
• Erişilebilirlik odaklı arayüz: Renk kontrastı, klavye kullanımı ve okunabilirlik kontrol edilir.

Erişilebilirlik için yapılan ek çalışmalar da bütçeyi etkiler. Görme zorluğu yaşayan kullanıcılar için yüksek kontrast kurmak ve ekran okuyucuyla uyumu sağlamak ekstra test demektir. Klavye ile gezinmeyi sorunsuz hale getirmek de ekstra test demektir. Büyük kurumlarda bu başlık çoğu zaman zorunlu olur.

Test süreci, hata düzeltme döngüleri ve kalite kontrol

Yazılımın geliştirilmesi ile teslim edilmesi arasında test süresi var. Bu süre kısa tutulursa ilk bakışta maliyet düşer gibi görünür; ama canlıda çıkan hata daha pahalıya gelir. Fiyat içinde test kaleminin yer alması boşuna değil. Kodun çalışması başka, doğru davranması başka.

Biz bir projede “çalışıyor” demekle yetinmiyoruz. Farklı tarayıcılar, farklı cihazlar, farklı kullanıcı rolleri ve farklı veri senaryoları ile kontrol ediyoruz. Aynı ekran yöneticiye açıkken operasyon personeline kapalı olabilir. Bu ayrımda hata çıkarsa süreç aksar. Test süresi, projeye göre birkaç günden birkaç haftaya uzayabiliyor.

Genel olarak üç test katmanını ayrı ele alıyoruz:

1. Birim testi: Küçük fonksiyonların beklenen sonucu verip vermediği kontrol edilir.
2. Bütünleşik test: Modüllerin ve servislerin birlikte doğru çalışıp çalışmadığına bakılır.
3. Kullanıcı kabul testi: Müşteri tarafı, gerçek iş akışına göre sistemi dener.

Katmanların her biri emek ister. Özellikle kullanıcı kabul testinde revizyon artarsa takvim uzar. Bazen tek bir alanın yeri değiştiğinde ekran, doğrulama, rapor ve bildirim tarafını yeniden kontrol ediyoruz. Küçük değişiklik zincirleme etki yapabiliyor.

Rol yönetimi ve yetkilendirme kurgusu

Sistemi herkesin her şeye eriştiği bir yapıda kurmak kolaydır; doğru olan bu değildir. Yetki matrisi oluşturmak, kullanıcı gruplarını tanımlamak, saha personeli ile yönetici ekranlarını ayırmak ve işlem bazlı izinleri kurgulamak ayrı bir iştir. Bu yüzden fiyat içinde rol yönetimi önemli bir bileşen olur.

Örneğin satış ekibinde temsilciler sadece kendi müşterilerini görsün, yöneticiler tüm portföye erişsin. Finans ekibi ödeme kayıtlarını düzenleyebilsin, ama sipariş silme işlemi yalnız üst düzey yöneticide kalsın. Bu tip ayrımlar net değilse güvenlik düşer. Ekran erişimi, veri görünürlüğü ve işlem izni ayrı ayrı düşünülür.

Yetkilendirmede sık görülen ihtiyaçlar

• Kullanıcı rolüne göre menü gizleme
• Departman bazlı veri filtreleme
• İşlem onayı gerektiren akışlar
• Log kayıtlarının kim tarafından tutulacağı
• Geçici yetki verme ve geri alma

Bu yapı küçük projede birkaç saatlik iş gibi görünür; orta ölçekte tablo büyür. Tek bir rol değişikliği, ekran görünürlüğünden raporlamaya kadar birçok yeri etkileyebilir. Sağlam yetkilendirme kurulmadığında müşteri sonradan “neden herkes bunu görebiliyor?” diye sorar. O noktada iş yeniden açılır.

İçerik, metin ve çok dilli yapı ihtiyaçları

Yazılım yalnız ekranlardan oluşmaz; içerik de işin parçasıdır. Kategori metinleri, form açıklamaları, hata mesajları, e-posta şablonları, bildirim başlıkları ve çok dilli alanlar ayrı çalışma ister. Kurumsal projelerde metinleri teknik ekibin rastgele bırakması doğru olmaz.

Biz çoğu projede metinlerin de revize edildiğini görüyoruz. Kullanıcıya görünen uyarı cümlesi yanlış yazıldığında destek yükü artar. “Hata oluştu” ile “Tarih alanı boş bırakılamaz” aynı şey değildir. İlki genel kalır; ikincisi kullanıcıyı yönlendirir.

Çok dilli projelerde maliyet daha da artar. Sadece çeviri yapılmıyor; uzunluk farkı, sağdan sola yazılan diller, para birimi gösterimleri ve tarih formatları da test ediliyor. İngilizce, Türkçe ve Arapça aynı ekran yerleşimine sığmayabilir. O zaman her dil için ayrı düzenleme gerekir.

Sunucu, lisans ve altyapı giderleri

Teklif yalnız geliştirme emeğini değil, altyapı giderlerini de içerebilir. Sunucu kiralama, yedekleme alanı, e-posta servisleri, harita API’leri, SMS entegrasyonları ve üçüncü parti lisanslar bu gruptadır. 

Biz lisanslı bir servisi projeye eklerken iki şeyi ayırıyoruz: yazılım geliştirme bedeli ve dış servis bedeli. Aylık kullanılan bir e-posta gönderim servisi varsa, bu hizmetin maliyeti yazılım firmasına değil, servisi sağlayan kuruma ödenir. Müşteri bunu bilmezse teklif yükseldi sanabilir; artışın sebebi dış maliyet de olabilir.

Kalem	Kime aittir?	Not
Geliştirme	Yazılım ekibi	Analiz, kodlama, test
Sunucu	Müşteri veya proje sahibi	Aylık/yıllık ücretli olabilir
Üçüncü parti lisans	Kullanıma göre değişir	Kimi zaman zorunlu, kimi zaman isteğe bağlı
SMS / e-posta servisi	Genelde müşteri	Kullanım miktarına göre fiyat değişir

Ucuz görünen altyapı çözümü büyüyen projede pahalıya dönebilir. Düşük kapasiteli sunucu yoğun kullanımda yavaşlar; yedekleme yoksa risk artar. Biz yalnız geliştirme maliyetine değil, işletme maliyetine de bakıyoruz. Canlıdaki masraf ilk teklif kadar önemlidir.

Değişiklik talepleri ve kapsam dışı işler

Proje başında konuşulmayan her yeni istek maliyeti değiştirir. Çünkü değişiklik tek satır kod eklemek değildir; bazen ekran, test, rapor ve entegrasyon tarafında da iş çıkar. Bu yüzden kapsam dışı maddeleri baştan yazıyoruz. Kapsamı net olmayan proje bütçeyi de net tutmaz.

Değişiklik taleplerini biz genelde üç grupta topluyoruz:

• Küçük revizyon: Metin değişimi, alan sırası, renk güncellemesi.
• Orta ölçekli revizyon: Yeni filtre, ek alan, yeni bildirim.
• Yeni kapsam: Ayrı modül, yeni entegrasyon, yeni iş akışı.

İlk grup çoğu projede hızlı çözülür. İkinci grup yeniden analiz ister. Üçüncü grup ise ayrı teklif gerektirir. Örneğin “kampanya alanı eklensin” talebi bazen teklifin içine sığar. Ama kampanyaya bağlı kupon, stok kuralı, muhasebe kaydı ve rapor beklentisi de varsa konu büyür.

Özel yazılım fiyatları için gerçekçi bütçe aralıkları nasıl okunur?

Tek rakam çoğu zaman yanıltır. Proje tipi, ekip büyüklüğü, iş takvimi, entegrasyon sayısı ve test kapsamı değiştikçe bütçe de değişir. Yine de aralık okumak mümkündür. Az ekranlı bir kurumsal panel ile çok modüllü, entegrasyonlu ve mobil destekli bir sistem aynı seviyede fiyatlanmaz.

Biz teklif görüşmelerinde bütçeyi üç seviyede düşünürüz:

Seviye	Proje yapısı	Tipik etkiler
Başlangıç	Az ekran, sınırlı rol, tek entegrasyon	Daha kısa analiz ve test süresi
Orta	Birden fazla modül, raporlama, orta düzey güvenlik	Daha fazla toplantı ve revizyon
Gelişmiş	Yüksek trafik, çoklu entegrasyon, mobil destek, yoğun yetkilendirme	Daha uzun geliştirme ve bakım ihtiyacı

Buradaki amaç sabit rakam vermek değil, fiyatın hangi zeminde oluştuğunu göstermek. Aynı özellik listesi farklı ekiplerde farklı süre ister. Kimi proje hızlı kararlarla ilerler; kimi projede her aşama onaya bağlıdır. Biz bütçeyi değerlendirirken bu çalışma biçimini de hesaba katıyoruz.

Analiz ve keşif toplantıları neden ayrı emek ister?

İyi görünen tekliflerin bir kısmı, analizin eksik tutulmasından sonra büyür. İhtiyaç toplama toplantılarında sadece “ne istiyoruz” sorusuna değil, “hangi durumda nasıl çalışmalı” sorusuna da cevap arıyoruz. Bu aşama kısa görünür; proje omurgasını ise burası belirler.

Keşif sürecinde süreç akışı, kullanıcı rolleri, kritik ekranlar ve hata senaryoları netleşir. Sipariş onayının tek adım mı olacağı, yoksa yöneticiden ek onay gerektirip gerektirmeyeceği burada belirlenir. Bu kararlar ekran sayısını, test süresini ve revizyon sayısını doğrudan etkiler.

Bizde detaylı analiz yapılmayan projelerde teklif sonra yeniden açılır. Eksik bırakılan her madde, geliştirme sırasında ayrı iş kalemi olur. Bu yüzden analiz süresi, fiyat içinde ayrı bir satır gibi düşünülmeli.

Analizde netleşmesi gereken başlıklar

• Kaç farklı kullanıcı türü olacak?
• Her kullanıcı hangi ekranları görecek?
• Onay mekanizması olacak mı?
• Raporlar anlık mı, günlük mü, aylık mı üretilecek?
• Mevcut sistemden veri taşınacak mı?
• Proje kaç dilde çalışacak?

Revizyon sayısı teklifin içinde nasıl okunur?

Teklifte revizyon sınırı açık yazılmadığında sorun çıkıyor. Tasarım ve iş mantığı onaylandıktan sonra gelen her yeni istek takvimi uzatır. Küçük bir metin değişikliği ile yeni bir iş akışı eklemek aynı şey değil; biri birkaç dakika, diğeri saatler sürer.

Biz revizyonu ikiye ayırıyoruz: görsel revizyon ve fonksiyonel revizyon. Görsel revizyon; renk, konum, boşluk, etiket gibi detaylarla ilgilidir. Fonksiyonel revizyon ise buton davranışı, veri akışı, otomatik işlem ve kurallarla ilgilidir. Maliyet tarafında asıl farkı ikinci grup yaratır.

Revizyon türü	Örnek	Süreye etkisi	Fiyat etkisi
Görsel	Butonun yeri değişsin	Düşük	Genelde sınırlı
İşlevsel	Butona basınca ek kontrol çalışsın	Orta	Belirgin
Akış değişikliği	Onay sırası yeniden kurulsun	Yüksek	Yüksek

Revizyon sınırı yoksa bütçe kağıt üzerinde düşük görünür ama gerçek işte büyür. Teklifte “kaç tur revizyon dahil” sorusunun cevabı fiyatı okumayı kolaylaştırır.

Ekip yapısı ve uzmanlık dağılımı neden önemlidir?

Aynı proje iki kişilik çekirdek ekiple de yürür; altı kişilik uzman ekiple de. Fark, işin hangi hızda ve hangi kalite düzeyinde ilerlediğidir. 

Basit otomasyon işinde tek geliştirici yeterli olabilir. Ama özel raporlama, mobil kullanım, çoklu entegrasyon ve güvenlik kontrolü varsa ekip büyür. Ekip büyüdükçe koordinasyon maliyeti de eklenir. Bu maliyet bazen görünmez, ama teklifin toplamına yansır.

Projeyi yalnız kod yazma işi olarak görmüyoruz. Teknik kararların zamanında alınması, testin düzenli ilerlemesi ve müşteri tarafındaki onayların gecikmemesi de ekip yapısının parçası. Fiyat, sadece geliştirici sayısıyla değil, organizasyon düzeniyle de oluşur.