İç araç yazmak mı, hazır ürün almak mı?

"Bunu bir haftada yazarım" cümlesi, yazılım ekiplerinde en pahalı cümlelerden biri. Genelde doğrudur — ilk sürüm gerçekten bir hafta sürer. Yanlış olan kısım, bir haftalık şeyin bir haftalık kalacağı varsayımı.

Aynı şekilde "hazır alalım, uğraşmayalım" da tek başına gerekçe değil: satın alınan her sistem bir entegrasyon, bir veri modeli ve bir çıkış maliyeti getiriyor.

Kararı netleştiren çerçeve şu.

Önce sınıflandır: bu iş çekirdek mi, destek mi?

Çekirdek: Müşterinizin size para ödemesinin sebebi olan şey. Rakibinizden farklı yaptığınız yer.

Destek: Yapmanız gereken ama kimsenin sizi bunun için seçmediği şey. Muhasebe, İK, bordro, fatura, izin takibi, stok, CRM.

Kural basit ama sık ihlal ediliyor: çekirdeği yaz, desteği satın al.

Ekipler bu kuralı genelde ikinci yönde ihlal ediyor — destek işini yazmaya başlıyorlar, çünkü teknik olarak ilgi çekici ve "bizim ihtiyacımız özel". Neredeyse hiçbir zaman özel değil.

Beş yıllık maliyeti hesapla, bir haftalık değil

Kendi yazdığınız bir iç aracın gerçek maliyeti:

Kalem	Sıklık
İlk geliştirme	bir kez
Hata düzeltme	sürekli
Kullanıcı desteği (ekip içi)	sürekli
Bağımlılık ve güvenlik güncellemeleri	sürekli
Mevzuat değişiklikleri	yılda 1-3 kez
Yazan kişi ayrıldığında devir	belirsiz
Yeni ihtiyaçlar için genişletme	sürekli

Son iki satır kararın büyük kısmını belirliyor ve hesaba neredeyse hiç katılmıyor. Bir iç aracı yazan tek kişi ekipten ayrıldığında, o araç ya donuyor ya çöpe gidiyor.

Satın alınan bir ürünün maliyeti ise: abonelik + entegrasyon + eğitim + çıkış maliyeti. Bunlar daha görünür olduğu için genelde abartılıyor; iç aracın maliyeti görünmez olduğu için küçümseniyor.

Mevzuata bağlı işleri yazmayın

Bu, en net kural. Fatura, e-belge, bordro, vergi hesabı gibi alanlarda kurallar yıllık olarak değişiyor ve değiştiğinde sizin takviminizi sormuyor.

Bunları kendi yazdığınızda, ekibinizin bir kısmı her yıl mevzuat takip eden bir birime dönüşüyor. Bu alandaki hazır sistemlerin — Logo, Mikro, Netsis, Paraşüt, Dia, Labyra, ya da Odoo/ERPNext için hazırlanan Türkiye eklentileri — sattığı asıl şey özellik değil, o takibi sizin yapmıyor olmanız. Aralarındaki fark da özellik listesinde değil, tebliğ çıktıktan kaç gün sonra güncelleme yayınladıklarında; satıcıya sorulacak soru budur.

"Ama bizim ihtiyacımız özel"

Bu cümle çoğu zaman şu üçünden birini gizliyor:

1. Süreç gerçekten tuhaf ve tuhaflık değer üretmiyor. Bu durumda doğru hamle aracı yazmak değil, süreci düzeltmek.
2. Hazır ürün araştırması yeterince yapılmamış. Üç ürüne bakıp "hiçbiri uymuyor" demek, otuz ürünün olduğu bir kategoride yeterli bir araştırma değil.
3. Gerçekten özel. Bu durumda muhtemelen bu iş sizin çekirdeğiniz ve zaten yazmanız gerekiyor.

Ayırt etmek için pratik test: bu süreci rakibinize anlatsanız, "biz de aynısını yapıyoruz" mu derdi? Derse, özel değil.

Melez yaklaşım genelde doğru olan

Çoğu durumda cevap "hepsini yaz" ya da "hepsini al" değil:

• Temeli satın al, çekirdeğe dokunan ince bir katmanı kendin yaz.
• Satın alınan ürünü API'si üzerinden kullan, arayüzüne bağımlı kalma.
• Kendi verini kendi tarafında da tut — satıcının sisteminde biriken veriyi düzenli olarak dışarı al.

Bu üçüncü madde, çıkış maliyetini yönetmenin tek gerçek yolu. Verisi elinizde olan bir sistemi değiştirmek zor ama mümkün; verisi elinizde olmayanı değiştiremezsiniz.

Karar için üç soru

1. Bu iş, müşterimizin bize ödeme yapma sebebiyle ilgili mi?
2. Bu alanın kuralları bizim dışımızda ve düzenli olarak değişiyor mu?
3. Bunu yazan kişi ayrılırsa ne olur?

Sırasıyla: hayır / evet / iş durur → satın alın. Evet / hayır / ekipte birden fazla kişi biliyor → yazın.

Diğer kombinasyonlarda melez yaklaşım doğru cevaptır.

Son not

Yazma kararı verdiğinizde, yazdığınız şeyi bir ürün gibi ele alın: sahibi olsun, dokümantasyonu olsun, sürüm notu olsun. Bunu yapmayacaksanız, aslında yazma kararı vermemişsiniz — sadece kararı ertelemişsiniz demektir.