Özel Yazılım Geliştirme Nedir? Süreç, Avantajları ve Maliyeti (2026)

Özel yazılım, tek bir kurum için sıfırdan geliştirilen yazılımdır. Hazır bir üründen satın alınmaz; kurumun kendi iş akışına göre tasarlanır ve yalnızca o akışın gerektirdiği işleri yapar.

Amacı mevcut bir soruna birebir çözüm üretmektir. Bu yüzden gereksiz özellik taşımaz — ama aynı sebeple, çözeceği sorun net tanımlanmadan başlanan bir özel yazılım projesi hedefini kaybeder.

Hazır yazılım herkes için üretilir. Başlangıç maliyeti düşüktür, hızlı devreye girer, ama esnek değildir: süreçlerinizi yazılımın çalışma biçimine uydurursunuz.

Özel yazılım bunun tersini yapar. Yazılım sizin süreçlerinize uyar. Başta daha çok yatırım ister, karşılığında uzun vadede verim ve ölçek kazandırır.

Bu ayrımın pratik sonuçları şunlar:

• Uyum. Hazır üründe süreç değişir, özel yazılımda ürün değişir.
• Ölçeklenme. Kurum büyüdükçe özel yazılım ihtiyaca göre genişletilebilir; hazır üründe genişleme paketin sınırlarıyla belirlenir.
• Maliyet eğrisi. Hazır ürün başta ucuz, uzun vadede lisans ve kullanılmayan modül maliyeti taşır. Özel yazılım başta pahalı, uzun vadede lisanssızdır ama bakım maliyeti size aittir.
• Farklılaşma. Rakiplerinizin de kullandığı bir üründe ürettiğiniz deneyim de benzer olur.

Fark ile karar aynı şey değil. Karar vermek için dört soruyu yazılı olarak cevaplayın.

1. Hazır ürünlerde bu işi yapan var mı ve gerçekten denediniz mi? Çoğu projede bu soru gerçek bir araştırmayla değil, varsayımla geçilir. Piyasada işi karşılayan bir ürün varsa özel yazılım pahalı bir tercihtir.
2. Süreciniz gerçekten farklı mı, yoksa alışkanlık mı? Bir sürecin sizde farklı işlemesi, öyle işlemesi gerektiği anlamına gelmiyor. Bazen doğru karar, süreci sadeleştirip hazır ürüne uydurmaktır.
3. Bu işi kaç kişi, ne sıklıkta yapıyor? Ayda birkaç kez, iki kişinin yaptığı bir iş için yazılım geliştirmenin karşılığı genellikle çıkmaz.
4. İki yıl sonra kim bakacak? Cevabı olmayan proje, birkaç ay sonra dokunulmayan bir sistem üretir.

Bunu baştan söylemek işimizi zorlaştırıyor ama doğru olan bu. Dört durumda özel yazılım yanlış karardır.

İhtiyaç standartsa. Muhasebe, e-posta, dosya paylaşımı gibi her kurumda aynı işleyen süreçlerde hazır ürünler yıllardır olgunlaşmıştır. Bunları yeniden yazmak, çözülmüş bir sorunu pahalıya çözmektir.

Süreç henüz oturmamışsa. Yazılım, bir süreci dondurur. Hâlâ değişmekte olan bir süreci koda gömmek, altı ay sonra yeniden yazılacak bir sistem üretir. Önce süreci netleştirin.

Bakımı üstlenecek kimse yoksa. Özel yazılım teslim edilince bitmez. Kurum içinde ya da ajans tarafında sahibi olmayan bir sistem, ilk güncelleme ihtiyacında durur.

Bütçe yalnız ilk yapımı karşılıyorsa. Geliştirme bütçesinin tamamını yayına harcayıp bakıma pay ayırmamak, projeyi yayın gününde bitirmek demektir.

Özel yazılım en sık şu ihtiyaçlarda tercih edilir:

• Kurumsal kaynak yönetimi (ERP)
• Müşteri ilişkileri yönetimi (CRM)
• Bayi, müşteri veya çalışan portalları
• Farklı sistemleri birbirine bağlayan entegrasyonlar
• Sektöre özgü iş uygulamaları

Ortak noktaları şu: hepsinde kurumun kendine has bir iş kuralı var ve hazır paketler o kuralı ya hiç desteklemiyor ya da zorlama bir çözümle destekliyor.

Sağlıklı bir proje beş aşamada ilerler ve aşamaların sırası maliyeti doğrudan belirler.

1. Analiz. Önce ihtiyaç anlaşılır, süreçler ve hedefler çıkarılır. Kapsamın burada yazılı olarak sabitlenmesi, sonraki her tartışmayı önler. Bu aşamayı ihtiyaç analizi yazımızda ayrıntılı ele aldık.
2. Tasarım. Kullanıcı deneyimi ve mimari planlanır, ekranlar ve akışlar çıkarılır. Onay alınmadan koda geçilmez; bu aşamadan sonra değişikliğin maliyeti hızla artar.
3. Geliştirme. Yazılım parça parça kodlanır, her parça test edilir ve çalışan sürüm düzenli olarak gösterilir. Uzun süre kimsenin çalışan bir sürüm görmediği projeler, sonunda beklenenden farklı bir ürün teslim etme eğilimindedir.
4. Test. Hatalar yayından önce bulunur; işlev, güvenlik ve performans ayrı ayrı sınanır.
5. Yayın ve bakım. Sistem canlıya alınır, ardından bakım ve destek devreye girer.

Kurumsal projelerde işin zor kısmı genellikle yazılımın kendisi değil, bağlanacağı yerlerdir. Entegrasyon konuşulurken dört şey netleşmeli:

• Hangi sistemler ve hangi yönde? Veri sadece okunacak mı, yazılacak mı, iki yönlü mü akacak?
• Bağlantı noktası var mı? Karşı sistemin bir arayüzü ve dokümantasyonu var mı, yoksa üretilmesi mi gerekiyor? Eski sistemlerde bu çoğu zaman projenin en belirsiz kalemidir.
• Gerçek zamanlı mı, toplu mu? Anlık senkronizasyon ile günde bir kez toplu aktarım çok farklı maliyetlerdir ve çoğu ihtiyaç ikincisiyle karşılanır.
• Karşı taraf kimin sorumluluğunda? Erişim, izin ve değişiklik yetkisi kimdeyse takvim de büyük ölçüde ona bağlıdır.

Bu dört başlık netleşmeden verilen entegrasyon tahminleri sonradan düzeltilmek zorunda kalır.

Güvenlik yayın öncesi yapılan bir kontrol değil, geliştirmenin her aşamasında gözetilen bir başlıktır. Kurumsal bir projede en az şunlar konuşulmalı:

• Veri koruma. Hassas bilgiler hem saklanırken hem iletilirken şifrelenmeli.
• Bağımlılık güncelliği. Kullanılan kütüphaneler ve çerçeveler düzenli güncellenmeli; bilinen açıkların büyük kısmı bu yolla kapanır.
• Kimlik doğrulama. Yetkili kullanıcılar için iki aşamalı doğrulama seçeneği bulunmalı.
• Girdi denetimi. Kullanıcıdan gelen her veri denetlenmeli; enjeksiyon saldırılarının çıkış noktası burasıdır.
• Düzenli test. Zafiyet taraması ve gerektiğinde sızma testi, açıkları kötü niyetli birinden önce bulmanın yoludur.
• Olay planı. Bir ihlal durumunda kimin ne yapacağı önceden yazılı olmalı. Bu plan olay anında yazılamaz.

Bu maddeleri teklif aşamasında sormak, sonradan öğrenmekten ucuzdur.

Tek bir sabit fiyat yoktur. Maliyeti belirleyen başlıca etkenler şunlardır:

• Projenin kapsamı ve özellik sayısı
• Entegrasyon gereken sistem sayısı ve karşı sistemlerin durumu
• Tasarımın özgünlüğü
• Güvenlik ve ölçeklenebilirlik ihtiyacı
• Bakım ve destek süresi

Kapsam büyüdükçe maliyet artar. Bu yüzden net bir ihtiyaç analizi doğru bütçenin ön koşuludur; analiz olmadan alınan teklifler karşılaştırılabilir bile değildir.

Sağlıklı bir teklif neyin dahil olmadığını da yazar. İlk fiyat yerine toplam sahip olma maliyetini karşılaştırın.

Bakım, projenin en çok atlanan kalemidir. Dört ayrı başlıktan oluşur ve karıştırılmamaları gerekir:

• İşletim. Sunucu, sertifika, yedekleme, izleme. Sabit ve öngörülebilir.
• Güncelleme. Kütüphane sürümleri ve güvenlik yamaları. Düzenli ama düşük yoğunluklu.
• Değişiklik talepleri. İş değiştikçe yazılım da değişir. Bu kalem öngörülemez ve genellikle bütçelenmez.
• Destek. Kullanıcı soruları ve arıza müdahalesi. Kullanıcı sayısına göre değişir.

Sözleşme yapılırken bu dördünün hangisinin kapsamda olduğu ayrı ayrı yazılmalı. "Bakım dahildir" cümlesi tek başına hiçbir şey ifade etmez.

Kurumsal alımda en sık atlanan ve en pahalıya mal olan soru budur. Cevabı yasadan değil sözleşmeden gelir, yani baştan konuşulmadıysa sonradan pazarlık konusu olur.

Üç yaygın model var: kodun tamamının kuruma devri, kuruma süresiz kullanım lisansı verilmesi, ya da kodun geliştiricide kalıp hizmetin abonelik gibi sürmesi. Üçü de meşrudur; sorun hangisinin seçildiğinin yazılı olmamasıdır.

Bir uyarı: kod devredilse bile onu çalıştırabilecek bir ekip ve dokümantasyon yoksa devir kâğıt üstünde kalır. Kaynak kod teslimi isteniyorsa kurulum belgeleri, mimari açıklaması ve ortam bilgileri de aynı pakette istenmelidir.

Süre projenin büyüklüğüne bağlıdır. Küçük bir modül birkaç haftada biter, kapsamlı bir sistem birkaç ay sürebilir.

Takvimi uzatan etkenler genellikle teknik değildir: içeriğin ve verinin geç hazırlanması, onay zincirinin uzunluğu ve kapsamın yazılı sabitlenmemiş olması. Üç kişilik bir onay zinciri ile yedi kişilik bir onay zinciri aynı projeyi çok farklı sürelerde bitirir.

Net bir plan süreyi öngörülebilir kılar; belirsiz bir kapsam ise hiçbir planın tutmasına izin vermez.

Doğru firma projeyi kurtarır, yanlışı geciktirir. Seçerken şunlara bakın:

• Benzer ölçekte ve benzer entegrasyon yüküyle tamamlanmış projeler
• Şeffaf süreç, yazılı kapsam ve düzenli iletişim
• Teknik yetkinlik ve eski sistemlerle çalışma tecrübesi
• Yayın sonrası bakım ve destek kapsamının teklifte yazılı olması
• Kaynak kod ve dokümantasyon konusunda net bir cevap

Referanslar en güçlü kanıttır; firmanın geçmiş işlerini mutlaka inceleyin. Web sitesi tarafında süreç, maliyet ve ajans seçimi başlıklarını kurumsal web tasarım ve yazılım yazımızda ayrıca ele aldık.

Bigfil Project House, kurumsal firmalar için özel yazılım, web ve mobil çözümler geliştirir. İGA, İş Bankası ve OPET gibi markalarla çalıştık. Projeniz için teklif almak isterseniz bizimle iletişime geçebilirsiniz.