Kısa cevap
Özel yazılımın maliyeti, yazılacak kodun miktarından çok kapsamına göre belirlenir. Modül ve ekran sayısı, iş kuralları, entegrasyonlar, kullanıcı rolleri, raporlama, çoklu dil, güvenlik gereksinimleri ve veri aktarımı geliştirme bedelini; sunucu, üçüncü taraf lisanslar ve bakım ise yayından sonraki düzenli gideri oluşturur. Süreç ihtiyaç analizi ve kapsam belgesiyle başlar; tasarım, geliştirme, test, yayın ve bakımla devam eder. Güvenilir bir teklif için önce ihtiyaçlarınızı yazılı hale getirip önceliklendirmeniz gerekir.
Son güncelleme: 17 Ekim 2026.
Tipik bir özel yazılım projesi altı aşamadan geçer: ihtiyaç analizi, tasarım ve prototip, geliştirme, test, yayın ve bakım. Hangi kararın hangi sırayla verileceğini web yazılım projesi nasıl planlanır yazımızda anlattık; burada her aşamanın bütçeye nasıl yansıdığına odaklanıyoruz.
Maliyetteki en büyük belirsizlik bu aşamada giderilir. Mevcut iş akışı incelenir; sistemi kimin hangi amaçla kullanacağı, hangi verilerin tutulacağı ve hangi işlemlerin otomatikleşeceği yazıya dökülür. Çıktı bir kapsam belgesidir: modüller, kullanıcı rolleri, temel ekranlar, iş kuralları, entegrasyonlar, kabul kriterleri ve kapsam dışı bırakılanlar. Kapsam dışı listesi en az kapsamın kendisi kadar önemlidir; belirsiz bırakılan her madde geliştirme sırasında ek iş olarak geri döner. Büyük projelerde analiz, ayrı ücretlendirilen bir keşif çalışması olarak da yürütülebilir.
Ekran taslakları ve gerekirse tıklanabilir bir prototip, kod yazılmadan önce iş akışının doğru anlaşılıp anlaşılmadığını gösterir. Bir ekranı prototipte değiştirmek, kodlandıktan sonra değiştirmekten çok daha az emek ister; tasarım onayı bu yüzden bütçeyi koruyan bir adımdır. Bu aşamanın maliyetini ekran sayısı, özgün arayüz tasarımı istenip istenmediği ve mobil kullanım ihtiyacı belirler.
Kullanıcının gördüğü ekranlar, sunucu tarafındaki iş mantığı, veritabanı, diğer sistemlerle konuşan arayüzler (API) ve oturum yönetimi bu aşamada yazılır. İşin küçük paketlere bölünüp belirli aralıklarla çalışan bir sürümün gösterilmesi, yanlış anlaşılmaları erken yakalar. Süreyi en çok iş kurallarının karmaşıklığı uzatır: "teklif tutarına göre farklı yöneticiye onaya gitsin, reddedilirse gerekçesiyle geri dönsün" gibi bir kural, basit bir kayıt formundan çok daha fazla geliştirme ve test gerektirir.
Fonksiyon, yetki, entegrasyon, performans ve güvenlik testleri ile sizin yürüteceğiniz kullanıcı kabul testi bu aşamadadır. Test kapsamı teklifte yazmıyorsa teklif eksiktir. Personel, müşteri veya finans verisi işleyen sistemlerde "bu kullanıcı yalnızca kendi kayıtlarını mı görüyor?" sorusunu sınayan yetki testleri ihmal edilmemelidir. Kabul testinin hangi senaryolarla yapılacağı ve işin hangi koşulda teslim alınmış sayılacağı sözleşmede tanımlanmalıdır.
Yazılım canlı sunucuya kurulur; alan adı veya alt alan adı, SSL sertifikası, yedekleme ve erişim ayarları yapılır. Eski bir programdan ya da Excel dosyalarından veri taşınacaksa alan eşleştirme, veri temizliği ve deneme aktarımı ayrı bir iş kalemidir ve tekliflerde en sık unutulan kalemlerden biridir. Canlıya geçişte sorun çıkarsa eski düzene nasıl dönüleceği de önceden planlanmalıdır.
Yayından sonra güvenlik güncellemeleri, kullanılan kütüphanelerin sürüm takibi, hata düzeltmeleri ve yedek kontrolü devam eder. Bakım ile yeni özellik geliştirmek farklı işlerdir. Sözleşme hangi işlerin bakım kapsamında olduğunu, destek taleplerinin nasıl iletileceğini ve acil bir arızada nasıl hareket edileceğini açıkça yazmalıdır.
Maliyet, projenin gerektirdiği toplam emekle ve yayından sonraki işletim giderleriyle belirlenir. Aşağıdaki tablo her kalemin hangi durumda bütçeyi büyüttüğünü ve tek seferlik mi, düzenli mi olduğunu gösteriyor.
| Kalem | Bütçeyi büyüten durum | Gider türü |
|---|---|---|
| Modül ve ekran sayısı | Her modülün kendi ekranları, kuralları ve testleri olur; modüller birbirine veri aktardıkça iş artar. | Tek seferlik |
| İş kuralları | Çok adımlı onay akışları, koşula bağlı hesaplamalar, istisna senaryoları. | Tek seferlik |
| Entegrasyonlar | Muhasebe/ERP programı, e-fatura entegratörü, SMS ve e-posta servisleri; belgesi zayıf ya da API'si olmayan sistemler. | Tek seferlik; servis ücretliyse düzenli |
| Roller ve yetkiler | Rol sayısının artması; kayıt düzeyinde yetki (örneğin her şubenin yalnızca kendi verisini görmesi). | Tek seferlik |
| Raporlama | Filtreli listeler, Excel/PDF dışa aktarma, gösterge panelleri, özel hesaplamalar. | Tek seferlik |
| Çoklu dil | Arayüz çevirisi, dile göre içerik, tarih ve para birimi biçimleri; sağdan sola yazılan diller. | Tek seferlik; çeviri güncellemeleri düzenli |
| Güvenlik ve veri koruma | Kişisel veya hassas veri, işlem kayıtları (log), iki adımlı doğrulama, bağımsız güvenlik testi. | Tek seferlik; kontroller periyodik |
| Veri aktarımı | Eski sistemden veya tablolardan veri taşıma, temizleme, deneme aktarımı. | Tek seferlik |
| Sunucu ve barındırma | Kullanıcı sayısı, dosya depolama, yedekleme, ayrı bir test ortamı ihtiyacı. | Düzenli |
| Üçüncü taraf lisanslar | Ücretli bileşenler, harita, SMS ve e-posta gönderim servisleri, kullanım başına ücretlenen API'ler. | Düzenli |
| Bakım ve destek | Güncellemeler, hata düzeltme, izleme, destek kapsamı ve süresi. | Düzenli |
Bu yazıda tutar vermiyoruz, çünkü aynı adı taşıyan iki "müşteri paneli" bu kalemlere göre çok farklı iş yükü çıkarabilir. Fiyat ancak kapsam yazıya döküldükten sonra anlamlı biçimde hesaplanır.
Yazılım kişisel veri işliyorsa işletmeniz veri sorumlusu olarak 6698 sayılı KVKK'nın 12. maddesindeki veri güvenliği yükümlülüklerine tabidir. Erişim yetkileri, işlem kayıtları ve yedekleme bu yükümlülüğün teknik tarafını karşılar. Sunucunun yurt dışında olması ya da yurt dışındaki bir servise veri gönderilmesi, Kanun'un yurt dışına aktarım hükümlerini gündeme getirebilir. Bu gereksinimler baştan yazılırsa tasarıma dahil edilir; sonradan eklenmeleri daha pahalıdır. Web tarafındaki temel önlemleri web sitesi güvenliği sayfamızda özetledik.
Teklifleri yalnızca geliştirme bedeline bakarak karşılaştırmak yanıltır. Toplam sahip olma maliyeti; ilk geliştirme, kurulum, barındırma, lisanslar, bakım ve sonradan gelecek değişiklikleri birlikte kapsar. Teklifte tek seferlik ve düzenli kalemlerin ayrı satırlarda yazılmasını isteyin. Barındırma seçeneklerini web hosting sayfamızda inceleyebilirsiniz.
Kapsam net ve değişme ihtimali düşükse sabit fiyat; gereksinimler kullanım sırasında şekillenecekse zaman-malzeme modeli daha uygundur.
| Ölçüt | Sabit fiyat | Zaman-malzeme |
|---|---|---|
| Uygun olduğu durum | Kapsamı ve kabul kriterleri yazılı, değişiklik ihtimali sınırlı işler | Keşif gerektiren, önceliklerin kullanımla netleşeceği işler |
| Bütçe öngörülebilirliği | Yüksek; belirsizlik payı fiyata yansır | Harcanan emeğe göre değişir; üst sınır konabilir |
| Değişiklik | Her yeni istek ayrı değerlendirilir | Öncelikler dönemler arasında değiştirilebilir |
| Sizden beklenen | Başta ayrıntılı kapsam ve hızlı onay | Düzenli öncelik kararı vermek ve çalışma raporlarını takip etmek |
Pratikte ikisinin birleşimi sık görülür: analiz ayrı yürütülür, netleşen ilk sürüm sabit fiyatla yapılır, sonraki geliştirmeler zaman-malzeme ya da yeni tekliflerle ilerler. Hangi model seçilirse seçilsin, sözleşmede bir değişiklik talebi süreci olmalıdır: yeni istek yazılı iletilir, süreye ve bedele etkisi yazılı bildirilir, onaydan sonra işe başlanır.
MVP (minimum uygulanabilir ürün), ana iş akışını uçtan uca çalıştıran en küçük sürümdür. Her şeyi bir kerede yaptırmak yerine önce bunu yayınlamak, bütçeyi gerçekten kullanılan özelliklere harcamanızı sağlar.
Kurgusal örnek: bir teknik servis firması için ilk sürümde müşteri kaydı, servis talebi açma, teknisyene atama ve durum takibi yer alabilir. SMS bildirimi, muhasebe entegrasyonu, gelişmiş raporlar ve teknisyen mobil uygulaması sonraki sürümlere kalır. Önceliklendirmede her özelliği üç gruptan birine koymak işe yarar:
MVP; güvenlikten, yedeklemeden ya da veri yapısının doğru kurulmasından kısmak demek değildir. Bunlar ilk sürümde sağlam kurulmazsa sonraki her sürüm daha pahalıya gelir.
Bedeli ödemek, yazılım üzerindeki hakların kendiliğinden size geçtiği anlamına gelmez; devir ya da lisans sözleşmede açıkça yazılmalıdır. 5846 sayılı Fikir ve Sanat Eserleri Kanunu, bilgisayar programlarını ilim ve edebiyat eseri olarak korur. Kanunun 52. maddesine göre mali haklara ilişkin sözleşmelerin yazılı yapılması ve konu olan hakların (işleme, çoğaltma, yayma gibi) ayrı ayrı gösterilmesi şarttır. Sözleşmede şu başlıkları arayın:
Bu bölüm bilgilendirme amaçlıdır, hukuki danışmanlık değildir; özellikle kapsamlı projelerde sözleşmeyi imzalamadan önce bir hukukçuya inceletin.
Hazır bir ürün iş akışınızı küçük uyarlamalarla karşılıyorsa çoğu zaman daha hızlı ve ekonomik bir başlangıçtır. Özel yazılım, kritik bir süreç hazır ürünlerle yönetilemiyorsa ya da lisans ve uyarlama giderleri zamanla özel geliştirmeye yaklaşıyorsa anlam kazanır. İki yolun avantajlarını ve risklerini özel yazılım mı, hazır script mi yazımızda karşılaştırdık. Maliyet açısından tek ek not: hazır ürünün kullanıcı başı veya aylık lisans bedelini birkaç yıllık süreyle hesaplayın ve özel yazılımın bakım ile barındırma gideriyle aynı süre üzerinden kıyaslayın.
Karşılaştırılabilir teklif almak için tüm firmalara aynı ihtiyaç belgesini gönderin. Teknik dil gerekmez; aşağıdaki başlıkları kendi cümlelerinizle doldurmanız yeterlidir.
Gelen tekliflerde şu soruların cevabını arayın:
Teklifleri yan yana koyarken kullanabileceğiniz yöntem için teklif nasıl karşılaştırılır rehberimize bakabilirsiniz; web sitesi için yazılmış olsa da kapsamı eşitleme mantığı yazılım teklifleri için de geçerlidir.
Süre; modül sayısına, iş kurallarının karmaşıklığına, entegrasyonlara ve test kapsamına bağlıdır. Gerçekçi bir takvim ancak ihtiyaç analizinden sonra çıkarılabilir. İlk sürümü MVP olarak sınırlamak, yayına çıkış süresini kısaltmanın en doğrudan yoludur.
Çoğu zaman firmalar aynı işi fiyatlamıyordur. Bir teklifte test, veri aktarımı, kaynak kod teslimi veya bakım dahilken diğerinde olmayabilir. Hepsine aynı ihtiyaç belgesini gönderip kapsam dışı bırakılan maddeleri sorarsanız karşılaştırma anlamlı hale gelir.
Paylaşmanız genellikle işe yarar. Firma, bu aralıkta hangi özelliklerin ilk sürüme sığacağını ve neyin sonraya kalacağını önerebilir. Bütçe aralığı vermek, o tutarın tamamının harcanacağı anlamına gelmez.
Hayır, fiziksel sunucu zorunlu değildir. Web tabanlı uygulamalar kiralık bir sunucuda veya ihtiyaca uygun bir barındırma paketinde çalışabilir. Seçimi kullanıcı sayısı, depolanacak dosya miktarı, verinin nerede tutulacağı ve yedekleme ihtiyacı belirler.
Sözleşmede işleme ve çoğaltma gibi mali hakların devri ya da yeterli kapsamda lisansı, ayrıca dokümantasyon teslimi varsa evet. Yeni firmanın kodu inceleyip devralması yine de zaman alır; okunabilir kod ve güncel dokümantasyon bu süreyi kısaltır.
Tuba Yazılım olarak özel yazılım geliştirme hizmeti veriyor, 81 ile uzaktan çalışıyoruz. İhtiyacınızı yukarıdaki şablonla ya da kendi cümlelerinizle teklif formuna ekleyin; kapsamı birlikte netleştirelim ve tek seferlik ile düzenli kalemleri ayrı gösteren bir teklif hazırlayalım.
