Özel Yazılım mı, Hazır Yazılım mı: Nasıl Karar Verilir

Özel yazılım mı, hazır yazılım mı kararı tek bir soruya dayanır: Yazılımla desteklemek istediğiniz süreç herkesinkiyle aynı mı, yoksa müşterilerin sizi tercih etme nedeni mi? Süreç standartsa satın alın. Sizi farklı kılan buysa ya da ekibiniz bir aracın eksiklerini telafi etmek için şimdiden aracın maliyetinden fazla mesai harcıyorsa, geliştirin. Çoğu şirket sonunda ikisini birden yapar. Pahalıya mal olan hata ise süreç yazıya dökülmeden bu çizgiyi çekmektir.

Kısa cevap bu ve pek çok yazı da burada biter. Bu yazı ise üç noktada daha ileri gidiyor. Önce, tüm varsayımları açıkça ortaya koyan beş yıllık bir maliyet modelini adım adım inceliyor; siz de kendi rakamlarınızı yerine koyabiliyorsunuz. Ardından, dikkatli olunmazsa tedarikçi bağımlılığının özel yazılımda da ortaya çıktığını gösteriyor. Son olarak, ekibinizle bir saatten kısa sürede doldurabileceğiniz bir puanlama tablosu sunuyor.

Farkın tek tabloda özeti

Hazır yazılım (COTS ya da bugünkü yaygın adıyla SaaS), binlerce şirkete aynı özelliklerle satılan tek bir üründür. Özel yazılım ise tek bir kuruluş için, o kuruluşun iş akışı, verileri ve kuralları temel alınarak geliştirilir. Kararı genellikle belirleyen konularda iki seçenek şöyle karşılaştırılabilir:

Son satırı iki kez okuyun. Çoğu karşılaştırma tedarikçi bağımlılığını yalnızca bir SaaS sorunu olarak ele alır. Oysa öyle değil; bu konuya aşağıda yeniden döneceğiz.

Hazır yazılım, ajansların kabul ettiğinden daha sık kazanır

İşimiz özel yazılım geliştirmek; buna rağmen görüştüğümüz pek çok şirkete hazır bir ürün satın almalarını öneriyoruz. Muhasebe, bordro, e-posta, mesajlaşma, standart bir CRM, destek talebi takibi ve e-imza çözülmüş sorunlardır. Tedarikçiler; vergi kuralı değişiklikleri, erişilebilirlik, denetim kayıtları ve SSO gibi henüz karşılaşmadığınız uç durumlar için yıllarını ve milyonlarca dolar harcadı. Bunlardan birini yeniden geliştirmek, kullanıcı başına birkaç dolara kiralayabileceğiniz bir şeyi baştan icat etmek için para ödemek demektir.

Süreç hâlâ değişiyorsa da satın almak daha doğru olur. Satış süreciniz geçen çeyrekte iki kez değiştiyse, yapılandırılabilir bir araç bu değişkenliği özel bir kod tabanından çok daha kolay karşılar. Henüz oturmamış bir süreç üzerine geliştirilen özel bir sistem, yanlış varsayımları veri modelinin içine gömer.

Hazır yazılım şu durumlarda doğru varsayılan seçimdir:

• bu işlev sizde de rakiplerinizde de aynı şekilde yürüyorsa (hiçbir müşteri sizi bordro süreciniz yüzünden seçmez);
• sistemin bu ay içinde çalışır durumda olması gerekiyorsa;
• tedarikçinin standart iş akışı işinizin en az %80’ini karşılıyorsa ve kalan %20 için kendi sürecinizi değiştirmeye hazırsanız;
• sistem yayına alındıktan sonra sahipliğini üstlenecek kimse yoksa.

Özel yazılım maliyetini ne zaman çıkarır

Özel yazılım, işletmeyi desteklemenin ötesine geçip şirketin gelir modelinin bir parçası olduğunda kendini amorti etmeye başlar. Sevkiyat kuralları doğrudan kâr marjını belirleyen bir lojistik firmasını, kredi değerlendirme akışı ürünün ta kendisi olan bir finans kuruluşunu ya da sattığı platformu kendisi geliştiren bir SaaS şirketini düşünün. Bunları genel amaçlı bir araca sığdırmaya çalışmak, onları farklı kılan şeyden vazgeçmek anlamına gelir.

İkinci tetikleyici daha az dikkat çeker ama çok daha yaygındır: geçici çözüm vergisi. Bu vergi; elektronik tablolara yapılan aktarımlar, iki sistem arasında kopyala-yapıştır, gayriresmî görevi CRM ile faturalama kayıtlarını eşleştirmek olan bir çalışan ve kırılgan otomasyonlarla birbirine bağlanmış üç ayrı araç olarak karşınıza çıkar. Bu noktada özel bir sistemin bedelini zaten ödüyorsunuz; yalnızca bunu personel saatleri, hatalar ve gecikmelerle ödüyorsunuz ve bunların hiçbiri yazılım faturasında görünmüyor.

Özel yazılım şu durumlarda da mantıklıdır:

• verileriniz uyumluluk gerekçesiyle belirli bir bölgenin ya da sistemin dışına çıkamıyorsa ve hiçbir tedarikçi bunu makul bir paket fiyatıyla sunmuyorsa;
• tedarikçinin desteklemediği ve yakın zamanda desteklemeyi planlamadığı bir entegrasyona ihtiyacınız varsa;
• kullanıcı başı fiyatlandırma iş modelinizi bozuyorsa (örneğin müşteriler, sürücüler ya da saha personeli gibi sistemi ara sıra kullanan binlerce dış kullanıcınız varsa);
• kendi içinizde kullanacağınız bir araç değil, satacağınız bir ürün geliştiriyorsanız.

İlk karşılaştırmada gözden kaçan maliyetler

İlk karşılaştırmada genellikle bir abonelik fiyatı ile bir geliştirme teklifi yan yana konur. Oysa iki rakam da eksiktir.

Hazır yazılım tarafında abonelik gideri zamanla büyür. Müşterilerinin yazılım satın alımlarını takip eden Vertice, SaaS fiyat enflasyonunu Haziran 2026’da %16,4 olarak ölçtü; bu, şirketin kayıtlarındaki en yüksek aylık oran. Bu veri piyasanın tamamını kapsayan bir endeks değil, tek bir platformun işlem verisidir; ancak eğilim, finans ekiplerinin sözleşme yenilemelerinde gözlemledikleriyle örtüşüyor. Aynı kaynak, 2025’in son çeyreğinde yenilenen SaaS sözleşmelerinin %28’inin fiyat düşmeden daha az değer sunduğunu tespit etti; çünkü bazı özellikler daha üst paketlere ya da ücretli eklentilere taşınmıştı.

Bir de hiç kullanılmayan lisanslar var. Zylo’nun 40 milyondan fazla lisansı kapsayan analizi, kuruluşların önerilen kullanım düzeyine göre SaaS lisanslarının ortalama %36’sını kullanmadığını ortaya koydu. Bu kaybın bir kısmı daha iyi lisans yönetimiyle giderilebilir; bir kısmı ise lisansları paketler hâlinde satın almanın kaçınılmaz bedelidir.

En büyük gizli maliyet ise entegrasyondur. 2025 MuleSoft Bağlantı Karşılaştırma Raporu, ortalama bir kurumsal şirketin 897 uygulama kullandığını, bunların yalnızca %29’unun birbirine entegre olduğunu ve BT ekiplerinin zamanlarının %39’unu özel entegrasyonlar geliştirmeye harcadığını ortaya koydu. Yani bir araç satın almak geliştirme ihtiyacını nadiren ortadan kaldırır; bu işi, görülmesi ve bakımı daha zor olan uç noktalara taşır.

Özel yazılım tarafında ise yayından sonrası için plan yapılmazsa, geliştirme teklifi uzun vadeli toplam maliyetin yalnızca küçük bir kalemi olarak kalır. Canlıda çalışan bir sistem; barındırma, izleme, güvenlik yamaları, kütüphane güncellemeleri, gerçekten test edilmiş yedekler ve bir sorun çıktığında kodu anlayan birini gerektirir. Yaygın bir planlama varsayımına göre, yeni özellikler hariç sistemi sağlıklı tutmanın yıllık maliyeti ilk geliştirme bedelinin %15-20’si kadardır. Bunu kesin bir kural değil, sorgulanması gereken bir başlangıç tahmini olarak görün.

Bir de insan faktörü var. Sistemi tek bir serbest geliştirici yazdıysa ve kodu yalnızca o kişi anlıyorsa, bir tedarikçiye bağımlılığı tek bir kişiye bağımlılıkla değiştirmiş olursunuz. Üstelik bir kişi, bir tedarikçiden çok daha hızlı ayrılabilir.

Kendi rakamlarınıza uyarlayabileceğiniz 5 yıllık maliyet modeli

Fiyat karşılaştırmaları genellikle yalnızca ilk yılı birbiriyle kıyasladığı için yanıltıcıdır. Sağlıklı bir karşılaştırma üç ila beş yıllık bir dönemi kapsar ve yalnızca faturaları değil, harcanan zamanı da hesaba katar. Aşağıda adım adım hesaplanmış bir örnek bulacaksınız. Her rakam örnek amaçlı bir varsayımdır, teklif değildir. Kendi rakamlarınızı yerine koyun.

Ortak varsayımlar

• Hazır yazılım: 30 kullanıcı için kullanıcı başına aylık 55 $ ve buna ek olarak yıllık 7.200 $ tutarında bir entegrasyon ara katmanı. Birinci yıl toplamı 27.000 $’dır ve her yıllık yenilemede %10 artar.
• Özel yazılım: beş ay süren, 120.000 $ tutarında bir geliştirme; bu süre boyunca SaaS kullanımı devam eder. Barındırma, izleme ve bakımı kapsayan yıllık işletme maliyeti, geliştirme bedelinin %18’i (21.600 $) olarak alınmıştır.
• Özel sistem, elle yürütülen geçici çözümlere harcanan sürenin %80’ini ortadan kaldırır; tamamını değil.
• Personel zamanı, yılda 48 çalışma haftası üzerinden saatlik 45 $ olarak hesaplanır.

İki senaryo arasındaki tek fark, mevcut aracın ne kadar elle yapılan iş yarattığıdır.

Burada abonelik fiyatının neredeyse hiçbir önemi yok: SaaS her iki senaryoda da beş yılda yaklaşık 165.000 $’a mal oluyor. Kararı değiştiren, faturada hiç görünmeyen geçici çözüm süresi, yani harcanan saatler.

Bu yüzden tedarikçilerle görüşmeden ya da geliştirme teklifi istemeden önce iki hafta boyunca tek bir şeyi ölçün: Mevcut araç ihtiyacınızı karşılamadığı için çalışanlarınız haftada kaç saatini veri dışa aktarmaya, verileri yeniden girmeye, kayıtları eşleştirmeye ve hataları düzeltmeye harcıyor? Bunu ölçemiyorsanız, tahmini yöneticilerle değil, işi bizzat yapan kişilerle birlikte yapın.

Modeli gerçekçi tutan iki uyarı var. Birincisi, özel yazılımda ilk yıl açık ara en pahalı yıldır. Nakit, tasarruflar başlamadan önce çıkar ve geliştirmede %20’lik bir bütçe aşımı, başa baş noktasını bir yıl ya da daha fazla öteler. İkincisi, model geliştirme kapsamının iyi belirlendiğini varsayar. Özel yazılım sütunundaki rakamı bir umut olmaktan çıkarıp güvenilir bir sayıya dönüştüren şey, sabit ve yazılı bir kapsamdır.

Kendi yazılımınızı geliştirmek bağımlılığı ortadan kaldırmaz, yalnızca yerini değiştirir

SaaS’ta tedarikçi bağımlılığı iyi bilinir. Verileriniz başka birinin veri yapısında durur, dışa aktarım eksik olabilir, sözleşmeler otomatik olarak yenilenir ve yenileme fiyatı, tedarikçinin ayrılma maliyetinizi göz önünde bulundurarak katlanabileceğinizi düşündüğü kadardır.

Özel yazılımdaki bağımlılıktan daha az söz edilir, ancak daha ciddi olabilir. Kod deposu ajansın hesabında durduğunda, canlı ortam altyapısı ajans adına faturalandığında, dokümantasyon bulunmadığında ya da kullanılan teknolojiler yalnızca ilk ekibin eleman bulabileceği kadar sıra dışı olduğunda ortaya çıkar. Kâğıt üzerinde yazılımın sahibi sizsinizdir, ancak pratikte ona dokunamazsınız.

Hangi yolu seçerseniz seçin, şu soruları sorun:

Bu nedenle kendi projelerimizde kod deposunu, altyapıyı ve dokümantasyonu size teslim ediyoruz; yayından sonraki işletme anlaşmasını da 30 gün önceden bildirerek sonlandırabiliyorsunuz. Müşterilerimizin bizimle ayrılmak zor olduğu için değil, sistem iyi çalıştığı için devam etmesini isteriz. Kiminle çalışırsanız çalışın, ilk satır kod yazılmadan önce bu şartları yazılı olarak alın.

Çoğu karşılaştırmanın atladığı ara seçenekler

“Geliştirmek mi, satın almak mı?” sorusu yalnızca iki seçenek varmış gibi bir izlenim yaratır. Pratikte en az dört seçenek vardır:

1. 01Yapılandırın. Hazır aracın kendi ayarlarını, özel alanlarını ve iş akışı kurallarını kullanın. Ucuzdur ve geri alınabilir. İşe buradan başlayın.
2. 02Genişletin. Tedarikçinin API’si ya da düşük kodlu araçlarla ürünün üzerine küçük eklemeler yapın: bir veri eşitleme işi, özel bir rapor ya da bir onay adımı gibi. Bir ya da iki iş akışındaki eksikliği gidermek için uygundur.
3. 03Çekirdeği satın alın, ucu geliştirin. Muhasebe ya da CRM gibi standart bir ana kayıt sistemini koruyun; sizi farklı kılan kısmı ise bu sistemle entegre çalışan ayrı bir uygulama olarak geliştirin. Büyüyen şirketler için çoğu zaman en doğru yanıt budur.
4. 04Çekirdeği geliştirin. Ana kayıt sistemini tamamen değiştirin. Çekirdek sistem ürünün kendisiyse ya da işinizi kısıtlıyorsa mantıklıdır.

Her basamak bir öncekinden daha pahalıdır ve daha fazla kontrol sağlar. Bir üst basamağa ancak alttaki basamak açıkça yetersiz kaldığında ve bunun maliyetini saat ya da gelir olarak gösterebildiğinizde geçin.

Cevap “şimdilik ikisi de değil” olduğunda

Bazen doğru hamle, kararı bilinçli olarak ertelemektir. Süreç hâlâ her ay değişiyorsa, onu yalnızca bir avuç kişi kullanıyorsa ya da iyi düzenlenmiş bir elektronik tablo işi gerçekten görüyorsa, ne bir platform satın alın ne de geliştirme siparişi verin. Süreci yazıya dökün, bir çeyrek boyunca elle yürütün ve zamanın nereye harcandığını ölçün. Bu veriyle çok daha sağlıklı bir karar verirsiniz; ileride zaten ihtiyaç duyacağınız gereksinim dokümanı da hazır olur.

Ekibiniz için puanlama tablosu

Bu tabloyu yalnızca bütçeyi onaylayan kişilerle değil, süreci fiilen yürüten çalışanlarla birlikte doldurun. Her satırı 1 ile 5 arasında puanlayın, puanı ağırlıkla çarpın ve sonuçları toplayın.

Alınabilecek en yüksek puan 70’tir. 30’un altı: satın alın ve özelleştirmeden önce yapılandırın. 30 ile 45 arası: hibrit yaklaşım; çekirdeği satın alın, ucu geliştirin. 45’in üzeri: özel geliştirme, kapsamının düzgünce belirlenmesine değer. “Sürecin istikrarı” ya da “sahiplenme kapasitesi” 1 puan aldıysa, toplam puan ne olursa olsun geliştirmeye başlamadan önce bu sorunu çözün.

Teklif istemeden önce hazırlamanız gerekenler

Keşif yapılmadan verilen her teklif, ister bir tedarikçinin kurulum tahmini ister bir ajansın geliştirme fiyatı olsun, yalnızca bir tahmindir. Rakamları karşılaştırmadan önce aşağıdakileri hazırlayın ya da hazırlaması için birini görevlendirin:

• sürecin bugün, geçici çözümler dahil, fiilen nasıl işlediğini gösteren yazılı bir harita;
• sürecin dokunduğu sistemlerin listesi ve bu sistemler arasında hangi verilerin aktığı;
• sistemi kimlerin, hangi yetkilerle kullandığı;
• geçerli tüm uyumluluk, veri saklama ve veri konumu kuralları;
• “tamamlandı” demenin ölçülebilir karşılığı: kazanılan saat, azalan hata sayısı ya da kısalan teslim süresi gibi.

Bu, projelerimizi nasıl yürüttüğümüzü anlatan sürecin ilk adımı olan keşif aşamasının özüdür: Tek satır kod yazılmadan önce ortaya bir gereksinim dokümanı, yazılı bir kapsam ve sabit bir bütçe çıkar. Sonunda bir SaaS ürünü satın almaya karar verseniz bile bu doküman, demoları değerlendirmenize ve tedarikçilere doğru soruları sormanıza yardımcı olur. Abonelik yolunu seçerseniz, SaaS’ın işletme maliyetlerini nasıl değiştirdiğini anlattığımız yazı nelere hazırlıklı olmanız gerektiğini ele alıyor.

Karar kuralı

Standart olanı satın alın ve özelleştirmeden önce yapılandırın. Sizi farklı kılan ya da size lisans bedelinden fazla mesaiye mal olan süreci geliştirin. Hangisini seçerseniz seçin, verilerinizin ve çıkış şartlarınızın kontrolünü ilk günden elinizde tutun.

Puanlama tablosunu doldurduysanız ve sonuç hibrit ya da geliştirme aralığına düştüyse, sürecinizi ve değerlendirdiğiniz seçenekleri bize gönderin. Hangi yolu seçeceğimizi gerekçesiyle birlikte söyleriz; cevabımız “satın alın” olsa bile. Ayrıca geliştirdiğimiz sistemlere ve uçtan uca sunduğumuz hizmetlere göz atabilirsiniz.