Teknoloji yığını: hangi dille yazıldığı değil, kim taşıyabildiği

Bir yatırım incelemesinde sizden kod okumanız beklenmiyor. Okusanız bile, erken aşamada gördüğünüz kodun çoğu altı ay sonra orada olmayacak. Teknoloji yığınına bakmanın amacı kaliteyi puanlamak değil, şirketin bugünkü teknik kararlarının hedeflediği büyüklükte ne kadara mal olacağını tahmin etmektir. Bu, mühendis olmadan da yapılabilir; birkaç doğru soru yeter.

Seçim mi, alışkanlık mı

İlk soru her zaman aynı: bu teknolojiyi neden seçtiniz. İki tür cevap gelir. Birincisi bir gerekçedir — şu kısıt vardı, şu alternatifi denedik, şu sebeple bunda karar kıldık. İkincisi bir alışkanlıktır: ekibin bildiği buydu.

İkinci cevap tek başına kötü değildir. Erken aşamada bildiğiniz araçla hızlı gitmek çoğu zaman doğru karardır. Kötü olan, kurucunun bunun bir tercih olduğunu fark etmemesidir; fark etmiyorsa, o tercihin faturası geldiğinde de fark etmeyecektir.

Bugünkü sayıyla değil, on katıyla sorun

Ölçeklenme konuşması soyut yapıldığında hiçbir işe yaramaz. Somutlaştırmanın yolu, şirketin kendi rakamını onla çarpıp sormaktır: bugün 5.000 kullanıcınız var, 50.000 olduğunda ilk ne kırılır.

Haziran 2012’de Udemy’ye beşinci mühendis olarak girdim. Kurs feed’ini şirket 100 bin kullanıcıdayken, kullanıcı başına kalıcı toplulaştırmayla kurdum; aynı sistem Udemy 4 milyon kullanıcıya ulaştığında ciddi bir değişiklik görmeden çalışıyordu. Bildirimlerde de durum benzerdi: tek bir kurstaki tek bir duyuru yüz binlerce arka plan işi tetikleyebiliyordu ve kullanıcı tabanı 40 kat büyüdükten sonra sistem yerinde durdu. Aynı dönemde Memcache önbellek katmanını ve feed ile bildirim için Redis tabanlı arka ucu kurduk; API yanıt süresi %50 düştü.

Bu üç örneğin ortak yanı teknoloji seçimi değil, sorunun ne zaman sorulduğudur. Üçünde de büyüme gelmeden önce düşünülmüştü. Kurucu “o köprüye geldiğimizde geçeriz” diyorsa cevabı not edin: yatırımdan sonraki ilk yılın mühendislik bütçesini belirleyecek olan cümle budur, ve yakma oranına doğrudan yazılır.

Sistem kaç kişinin kafasında duruyor

Erken aşamada en gerçek teknik risk, mimarinin yanlış olması değil, tek kişiye bağlı olmasıdır.

Kivi Video’yu Haziran 2021’de Ankara’da kurdum. Video sunucusunu, önbellekleme sistemini, video kodlama sistemini ve sitenin neredeyse tamamını tek başıma yazdım. En kalabalık anımızda sekiz kişiydik. Bu, hız açısından iyiydi; ama o sistemle ilgili her sorunun tek bir cevaplayıcısı vardı ve ben iki hafta kaybolsam şirketin ürün tarafı duracaktı.

Sorulacak soru nazikçe sorulur ama net olmalıdır: ekipteki hangi kişi iki hafta ulaşılamaz olsa hangi iş durur. Kurucu bir isim söylüyorsa risk oradadır ve azaltılabilir — devir belgesi, ikinci bir mühendis, çalışan bir kurulum betiği. Kurucu “kimse, her şey belgeli” diyorsa belgeyi isteyin; on dakikada gelmeyen belge yoktur.

Yeniden yazmanın fiyatı vardır

Kurucular sıklıkla “turdan sonra bunu düzgünce yeniden yazacağız” der. Bu cümle bir plan değil, bir maliyet kalemidir ve fiyatı sorulabilir.

Kasım 2024 – Ocak 2025 arasında LeanScale için Ankara’dan uzaktan çalıştım. JavaScript ile yazılmış 35.000 satırlık bir sistemi Rust’a çevirdim; sonuçta 60 kat daha bellek verimli hale geldi. Cursor’dan yardım alarak 40–50 dosyayı çevirdim, sonra üretilen kodu üç büyük parçaya bölüp ayıkladım ve birleştirdim. Toplam altı-yedi hafta sürdü ve işi bilen tek bir kişiyle yapıldı.

Bu rakamı bir ölçek olarak kullanabilirsiniz. Kurucu benzer büyüklükte bir yeniden yazmadan bahsedip “iki haftada hallederiz” diyorsa ya iş küçük ya tahmin yanlıştır; hangisi olduğunu sormak sizin işiniz. Aynı hesap piyasaya sürme süresini de etkiler: yeniden yazılan aylarda yeni özellik çıkmaz.

Veri nerede duruyor, kim erişebiliyor

Müşteri verisi tutan her üründe teknik yığının bir de hukuki yüzü var. Sorulacak üç şey basit: veri hangi ülkedeki hangi sağlayıcıda duruyor, şirket içinde kaç kişi üretim verisine erişebiliyor, ve son yedek ne zaman geri yüklenerek denendi.

Üçüncü soru en çok atlanandır. Yedeği olmayan şirket azdır; yedeğini geri yükleyip denemiş şirket çoktur denemez. Kişisel veri işleyen bir işte bu sorular, KVKK uyumu tarafında da aynı dosyanın içine düşer ve özenli nitelikli incelemenin teknik değil hukuki kısmına bağlanır.

Korunan şey tescilde değil, birikende

Fikri mülkiyet tarafında iki ayrı soru var ve karıştırılıyorlar. Birincisi mülkiyet zinciridir — kodun ve markanın hukuken şirkete ait olup olmadığı; onu ayrı bir başlıkta, fikri mülkiyetin korunması bölümünde ele aldım. İkincisi, teknolojinin gerçekten bir üstünlük taşıyıp taşımadığıdır.

Erken aşamada yazılımın kendisi nadiren korunur. Bir ürünü altı ayda kopyalamak mümkünse, o ürünün teknolojisi rekabetçi hendek değildir. Kopyalanması zor olan şey genellikle koddan sonra gelir: birikmiş ve etiketlenmiş veri, kurulmuş entegrasyonlar, müşterinin taşımak istemediği geçmiş. Kurucuya sorulacak son teknik soru budur — yarın kaynak kodunuzu rakibinize versem, sizi yakalaması ne kadar sürer. Cevap “birkaç ay” ise, yatırım kararınızı teknolojiye değil, hıza ve dağıtıma dayandırıyorsunuz demektir. Bu da bir karardır, ama bilerek verilmesi gerekir.