CTO as a Service Nedir, Kimler İçin Uygun? Dış Kaynak CTO Rehberi

CTO as a Service (dış kaynak CTO, fractional CTO ya da part-time CTO), bir şirketin tam zamanlı bir teknoloji yöneticisi işe almadan, deneyimli bir teknik liderden belirli saatler veya belirli bir dönem boyunca teknik karar desteği almasıdır. Bu rol kod yazan ekibin yerine geçmez; mimari, teknoloji seçimi, tedarikçi değerlendirmesi, işe alım ve güvenlik gibi geri dönüşü pahalı kararları alır, gerekçesiyle yazar ve kaydı şirkette bırakır. En çok teknik kurucusu olmayan girişimlere, ilk teknik alımını henüz yapmamış şirketlere ve yazılımını dışarıya geliştirten KOBİ'lere uygundur.

CTO as a Service tam olarak nedir?

"Fractional CTO", "part-time CTO", "dış kaynak CTO" ve "CTO as a Service" aynı modelin farklı adlarıdır. Ortak fikir şudur: şirketin teknik liderlik ihtiyacı gerçektir ama tam zamanlı bir yöneticiyi dolduracak kadar sürekli değildir. Kararlar yığın halinde gelir: yatırım turundan önce, ilk ajansı seçerken, ürün canlıya çıkmadan önce, tedarikçi değiştirirken. Aralarında haftalarca uygulama ve ölçüm dönemi olur.

Hizmeti somut kılan şey çıktılarıdır. İyi yürütülen bir dış kaynak CTO çalışmasının sonunda şirketin elinde mimari karar kayıtları (ADR), mevcut durum tespiti, teknik borç envanteri, tedarikçi değerlendirme notları ve sahipleri yazılı bir hesap ve erişim listesi olur. Toplantıda söylenip unutulan tavsiye bu hizmetin çıktısı sayılmaz.

CTO as a Service ne değildir?

• Kiralık yazılımcı değildir. Ekibe bir geliştirici eklemek kapasite sorununu çözer, karar sorununu çözmez. Hangi işin yapılacağına kimse karar vermiyorsa ek geliştirici yalnızca yanlış yöne daha hızlı gidilmesini sağlar.
• Tek seferlik danışmanlık raporu değildir. Bir kez gelip rapor bırakan danışman, rapor uygulanırken çıkan soruları görmez. Dış kaynak CTO'nun değeri, kararın sonucunu izleyip gerekirse yeniden açabilmesindedir.
• Şirketin resmi yöneticisi değildir. Genellikle imza yetkisi taşımaz, kadrodaki mühendislerin hukuki amiri olmaz. Bütçe, işe alım ve tedarikçi seçimi kararı şirkette kalır; dış kaynak CTO tavsiyeyi gerekçesiyle yazar.
• Proje yöneticisi değildir. Günlük görev dağılımı ve sprint takibi mevcut ekipte veya ajansta kalır.

Kimler dış kaynak CTO'ya ihtiyaç duyar?

MVP öncesindeki teknik olmayan kurucular

Fikir hazır, bütçe sınırlı ve ilk yazılım ortağı seçilecek. Bu aşamada alınan kararların bir kısmı sonradan geri alınamaz: bulut ve alan adı hesaplarının kimin adına açılacağı, verinin nerede tutulacağı, kapsamın ne kadar dar tutulacağı. Teknik bir göz, ajans tekliflerini karşılaştırırken sorulması gereken soruları netleştirir; bu soruların listesini MVP ajansı seçerken sorulacak sorular yazımızda topladık.

Tohum yatırım ile ilk teknik alım arasındaki girişimler

Yatırım alınmış, ürün çalışıyor ama şirkette teknik kararı sahiplenen kimse yok. İlk mühendislerin kim olacağı, mülakat çıtası ve bir sonraki turda yatırımcının teknik incelemesine hazırlık bu dönemin işidir.

Yazılımını dışarıda geliştiren KOBİ'ler

Ajans veya serbest çalışan ekiple ürün geliştiren şirketlerde kod üretiliyor ama kimse "bu doğru mu" diye sormuyor. Dış kaynak CTO, müşteri tarafında teknik muhatap olur: teklifleri okur, teslimleri kontrol eder, hesap sahipliğini güvenceye alır.

Vibe-code ile yapılmış ürünü canlıya taşıyan şirketler

Yapay zeka araçlarıyla hızla çıkarılmış bir prototip gerçek kullanıcıya açılmadan önce kimlik doğrulama, yetkilendirme, sır yönetimi ve yedekleme açısından gözden geçirilmelidir. Bu geçişin teknik tarafını Vibe-Code to Production hizmet sayfamızda anlattık.

Tedarikçi veya ajans değerlendiren şirketler

Mevcut ajansla devam edip etmemeye ya da yeni bir yazılım ortağı seçmeye karar vermek teknik bilgi ister. Genel seçim ölçütlerini yazılım geliştirme şirketi nasıl seçilir rehberimizde bulabilirsiniz; dış kaynak CTO bu ölçütleri sizin projenize uygular ve kodu fiilen inceler.

Dış kaynak CTO'nun sorumlulukları nelerdir?

Kapsam her şirkette aynı değildir, ama tipik bir CTO as a Service çalışması şu başlıkları içerir:

• Mimari kararlar ve ADR: Her önemli karar tek sayfada yazılır: cevaplanan soru, değerlendirilen seçenekler, seçilen yol, gerekçe ve kararı yeniden açmayı gerektirecek koşul. Mimarinin temel ilkelerini ölçeklenebilir ve sürdürülebilir yazılım mimarisi yazımızda ele aldık.
• Geri alınamaz kararların gözden geçirilmesi: Kullanıcı kimliği ve müşteri verisi ayrımının nerede kurulduğu, verinin hangi ülkede durduğu, hesapların kimin adına açıldığı, ödeme ve fatura mantığının veriye nasıl gömüldüğü, dışarıya açılan ilk API sözleşmesi. Bunlar yazılı gerekçe ister; geri alınabilir kararlar için aynı yükü getirmek gerekmez.
• Teknik borç envanteri: Kod tabanındaki teknik borç, ekip ile kod arasındaki bilgi borcu ve gerekçesi yazılmamış kararlardan doğan niyet borcu ayrı ayrı listelenir. Her madde "büyümeden önce değişmeli", "olduğu gibi yaşayabilir" ve "dokunulmayacak" kutularından birine girer.
• Tedarikçi ve ajans değerlendirmesi, kod denetimi: Deponun tüm geçmişiyle sizin hesabınızda olup olmadığı, projenin temiz bir makinede ayağa kalkıp kalkmadığı, kararların yazılı olup olmadığı kontrol edilir.
• İşe alım desteği: Mülakatın teknik bölümüne katılmak ve değerlendirme ölçütünü yazmak. İşe alma kararı şirkettedir.
• Güvenlik ve KVKK duruşu: Sırların depoda durup durmadığı, kimin üretime erişebildiği, yedekten geri yüklemenin hiç denenip denenmediği ve kişisel verinin KVKK açısından nerede, nasıl tutulduğu.
• Yol haritası ve bütçe girdisi: Teknik durumu yönetim kurulunun ve yatırımcının okuyabileceği dile çevirmek: risk ne, bedeli ne, ne zaman ödenecek.

Hangi çalışma modelleri var?

Piyasada üç model yaygındır ve çoğu anlaşma bunların bir karışımıdır:

• Dönemsel saat bazlı model (retainer): Belirli bir dönem için ayrılmış düzenli bir zaman. Kararların sürekli ama seyrek geldiği şirketler için uygundur.
• Kilometre taşı bazlı model: Belirli bir hedefe bağlı çalışma, örneğin yatırım öncesi teknik inceleme, ajans değişikliği ya da canlıya çıkış öncesi kontrol. Hedef tamamlanınca çalışma kapanır.
• Geçici (interim) CTO: Kalıcı CTO işe alınana kadar rolü daha yoğun biçimde üstlenmek. Burada sınırı baştan yazmak önemlidir: imza yetkisi, personel amirliği ve bütçe onayı kimde kalacak?

Maliyeti belirleyen şey modelden çok karar yoğunluğudur: ekip, tedarikçi ve entegrasyon sayısı arttıkça karar sayısı artar. Sistemin mevcut durumu (hesaplar dağınık mı, dokümantasyon var mı) ve düzenli toplantı ihtiyacı da kapsamı etkiler. Bu yüzden kapsamın ilk görüşmede yazılı olarak çizilmesi gerekir.

Tam zamanlı CTO, dış kaynak CTO ve ajansın lead developer'ı arasındaki fark nedir?

CTO as a Service sağlayıcısı nasıl seçilir?

Kontrol listesi

1. Çalışmanın sonunda hangi belgeler teslim edilecek? ADR, borç envanteri, erişim listesi gibi somut çıktılar isteyin.
2. Belgeler kimin erişiminde duracak? Doğru cevap: sizin.
3. Bulut, alan adı ve depo hesapları kimin adına açılacak? Sağlayıcı adına açılan hesap, ayrılıkta hukuki bir sorun demektir.
4. Tavsiyeler seçeneklerle birlikte mi yazılıyor? Adı konmuş bir alternatif ve iki tarafın maliyeti olmalı.
5. Rolün sınırı yazılı mı? İmza yetkisi, işe alım kararı ve bütçe kimde?
6. Çıkış nasıl tanımlanmış? Başarı ölçüsü, anlaşmanın yenilenmesi değil gereksiz hale gelmesi olmalı.
7. Sizin sektörünüzdeki düzenlemeleri (KVKK, ödeme, sağlık verisi gibi) konuşabiliyor mu?

Kırmızı bayraklar

• Her tavsiyenin sağlayıcının kendi geliştirme hizmetine çıkması.
• Çalışan bir sistemi gerekçesiz yeniden yazma önerisi.
• Kararların yalnızca toplantıda ve mesajlaşmada kalması, yazıya dökülmemesi.
• Hesapların ve erişimlerin sağlayıcı adına tutulması.
• "Her şeyi biz hallederiz" diyerek rolün sınırını çizmekten kaçınmak.

Aynı firma hem tavsiye verip hem uygulama yapıyorsa çıkar çatışması nasıl yönetilir?

Tavsiyeyi ve teslimatı aynı firmadan almak gerçek bir çıkar çatışmasıdır: firma kendi işini değerlendirmiş olur. Bu tek başına reddetme sebebi değildir, çünkü bağlamı bilen biri daha hızlı ilerler, ama yönetilmesi gerekir. Pratik önlemler şunlardır: her tavsiyede adı konmuş bir alternatif ve iki tarafın maliyeti yazılsın; karar kayıtları sizin erişiminizde dursun ki sonradan denetlenebilsin; kritik kararlarda (yeniden yazım, teknoloji değişikliği, büyük bütçe) bağımsız ikinci bir görüş alma hakkınız sözleşmede açık olsun; mevcut kodun denetimini, o kodu yazmamış biri yapsın.

Tam zamanlı CTO'ya ne zaman geçilmeli?

Dış kaynak CTO'nun hedefi kalıcı olmak değil, kendini gereksiz kılmaktır. Şu işaretler tam zamanlı bir teknik yöneticinin vaktinin geldiğini gösterir:

• Mimariyi etkileyen yeni bir soru artık her hafta çıkıyor.
• Mühendislik ekibi büyüdü ve günlük insan yönetimi gerektiriyor.
• Teknoloji ürünün ana farkı haline geldi ve yatırımcılar kurucu ekipte bir teknik lider bekliyor.
• Birden fazla ürün ve ekip arasında sürekli koordinasyon gerekiyor.

Geçişin temiz olması için dış kaynak CTO'nun biriktirdiği her şey (karar kaydı, borç envanteri, erişim listesi) yeni gelen kişiye hazır teslim edilebilmelidir. İyi bir sağlayıcı yeni CTO'nun mülakatına da destek verebilir.

Detartech'te CTO as a Service nasıl çalışıyor?

Biz işe mevcut durum tespitiyle başlıyoruz: projenin temiz bir makinede ayağa kalkıp kalkmadığı, hesapların kimin adına olduğu, yedeğin geri yüklenip yüklenemediği. Bu tespit ayrı fiyatlanıyor ve çıktısı olan maliyet ve etkiye göre sıralanmış listeyi alıp kendi ekibinize vermek de meşru bir sonuç. Sonrasında çalışma açık bir karar listesi üzerinden dönemsel olarak yürüyor; tavsiyeyi her zaman adı konmuş bir alternatif ve iki tarafın maliyetiyle yazıyoruz. İmza yetkilisi olmuyoruz, hesaplarınızı kendi adımıza tutmuyoruz ve çıkışta karar kaydı, durum tespiti, teknik borç envanteri, erişim listesi ve tedarikçi notlarını teslim ediyoruz. Tegoly, Finteo ve Terazzi gibi işlerimizde çalışan teknolojiyi değiştirmedik; çalışan sistemde varsayılan cevabımız değiştirmemek. Ayrıntılar CTO as a Service hizmet sayfamızda.

Şirketinizde teknik kararları kimin sahiplendiğinden emin değilseniz, kısa bir görüşmeyle durumu birlikte netleştirebiliriz. Hızlı teklif formunu doldurun, ücretsiz ön görüşme için 24 saat içinde dönüş yapalım.

Sıkça Sorulan Sorular

Fractional CTO ile CTO as a Service aynı şey mi?

Pratikte evet. İkisi de tam zamanlı istihdam olmadan, belirli saat veya dönem için teknik liderlik almayı anlatır. "Fractional CTO" daha çok bireysel çalışan uzmanlar için, "CTO as a Service" ise bir ekip veya firma tarafından sunulan hizmet için kullanılır.

Dış kaynak CTO kod yazar mı?

Ana işi kod yazmak değil, karar vermek ve kararı yazılı hale getirmektir. Bazı sağlayıcılar uygulama da yapar; bu durumda tavsiye ile teslimat arasındaki çıkar çatışmasının yazılı alternatiflerle ve bağımsız ikinci görüş hakkıyla yönetilmesi gerekir.

Zaten bir yazılım ajansımız varken dış kaynak CTO almak mantıklı mı?

Çoğu zaman en çok fayda bu durumda görülür. Ajans kodu üretir; dış kaynak CTO sizin tarafınızda durup teklifleri, teslimleri ve hesap sahipliğini kontrol eder. Günlük görev yönetimi ajansta kalır, dış kaynak CTO ekibin üstüne değil kararların önüne konumlanır.

Anlaşma bittiğinde elimizde ne kalır?

İyi kurulmuş bir çalışmada karar kaydı, mevcut durum tespiti, teknik borç envanteri, sahipleri yazılı erişim listesi ve tedarikçi değerlendirme notları sizde kalır. Bu belgeler çalışma boyunca zaten sizin erişiminizde birikiyorsa erken ayrılık da ayrı bir devir projesine dönüşmez.

CTO as a Service hizmeti veren firmaları nasıl karşılaştırmalıyım?

Referans listesinden çok teslim edilecek belgelere, hesap sahipliği kuralına, rolün yazılı sınırına ve çıkar çatışmasını nasıl yönettiklerine bakın. Aynı soruları her adaya sorun: ADR yazıyor musunuz, hesaplar kimin adına açılır, tavsiyeleriniz alternatif içeriyor mu, çıkış nasıl tanımlı?