Ortaksın
Rehbere dön
Teknik Ortaklık

Teknik Ortak Nedir? Görevleri, Sorumlulukları ve Ne Zaman Gereklidir?

Teknik ortağın yalnızca yazılım geliştiren kişi olmadığını; ürün, teknoloji, ekip, güvenlik ve uzun vadeli teknik kararlar açısından üstlendiği sorumlulukları öğrenin.

Ortaksın Editör Ekibi06 Ağu 202611 dk okumaGüncellendi: 06 Ağu 2026Kontrol: 06 Ağu 2026
Ürün ve teknoloji yol haritasını birlikte değerlendiren teknik ve iş tarafındaki iki kurucu

Teknik ortak, yalnızca ürünü kodlayan kişi değildir. Erken aşama bir girişimde teknolojiyle ilgili belirsizliği yönetir, ürün kararlarına katılır, teknik riskleri görünür hâle getirir ve geliştirme sorumluluğunu uzun vadeli iş hedefleriyle birlikte üstlenir.

Her yazılım ihtiyacı teknik ortak gerektirmez. Kapsamı belli bir site, entegrasyon veya mobil uygulama için freelancer ya da ajans daha uygun olabilir. Teknik ortak ihtiyacı; teknolojinin iş modelinin merkezinde olması, ürünün sürekli gelişmesi ve teknik kararların şirketin geleceğini doğrudan etkilemesi durumunda güçlenir.

Teknik ortak ile yazılımcı arasındaki fark nedir?

Bir yazılımcı belirli görevleri veya ürün parçalarını geliştirebilir. Teknik ortak ise görevlerin ötesinde şirket düzeyinde sorumluluk alır.

AlanYazılımcı veya hizmet sağlayıcıTeknik ortak
Temel ilişkiBelirli iş veya görevUzun vadeli ortaklık
Karar alanıVerilen teknik kapsamÜrün ve teknoloji stratejisi
RiskSözleşmeyle sınırlı iş riskiŞirket ve ortaklık riski
Zaman ufkuProje veya dönemBelirsiz ve uzun vadeli
EkipKendi görevini yürütürTeknik ekibi kurabilir ve yönetebilir
ÜrünGereksinimi uygularGereksinimin oluşmasına da katılır
KarşılıkÜcret ağırlıklıDuruma göre ücret, pay veya karma yapı
SorumlulukTeslimatSonuç, sürdürülebilirlik ve teknik yön

Bu tablo her ilişkiyi tamamen açıklamaz. Bazı kıdemli çalışanlar stratejik katkı verebilir; bazı teknik ortaklar başlangıçta yarı zamanlı olabilir. Belirleyici olan unvan değil, fiilen üstlenilen sorumluluktur.

Teknik ortağın temel görevleri

Ürün problemini teknik çözüme çevirmek

Teknik ortak “hangi teknolojiyi kullanalım?” sorusundan önce “kullanıcı için en küçük değerli çözüm nedir?” sorusuna katılır. Ürün kapsamını teknik zorluk, kullanıcı ihtiyacı ve öğrenme hedefiyle birlikte değerlendirir.

Mimari ve teknoloji kararları almak

Programlama dili veya veri tabanı seçimi tek başına strateji değildir. Teknik ortak şu konuları düşünür:

  • Ürünün kısa vadede nasıl doğrulanacağı
  • Hangi parçaların hazır hizmetlerle çözülebileceği
  • Hangi risklerin erken test edilmesi gerektiği
  • Güvenlik ve kişisel veri gereksinimleri
  • Gelecekte ölçekleme ihtimali
  • Teknik borcun ne zaman kabul edilebilir olduğu
  • Maliyetlerin nasıl izleneceği

Geliştirme kalitesini ve hızını dengelemek

Erken aşamada her şeyin kusursuz olması gerekmez. Ancak hızlı geliştirme adı altında kritik güvenlik, veri kaybı veya sürdürülemez altyapı riski oluşturulmamalıdır.

Teknik ortağın görevi, hangi kalite seviyesinin o aşama için yeterli olduğunu açıklayabilmektir.

Teknik riskleri görünür hâle getirmek

Kurucu ekip şu soruları duymalıdır:

  • Bu özellik beklenenden neden zor?
  • Hangi dış hizmete bağımlıyız?
  • Bir sağlayıcı kapanırsa ne olur?
  • Veri güvenliği açısından hangi yükümlülükler var?
  • Tahminin güven aralığı nedir?
  • Hangi varsayımı önce test etmeliyiz?

Riskleri saklamak değil, iş kararına çevirmek gerekir.

Teknik ekip kurmak

Ürün büyüdükçe teknik ortak:

  • İşe alınacak rolleri belirleyebilir
  • Adayları değerlendirebilir
  • Kod inceleme ve geliştirme standartları oluşturabilir
  • Bilginin tek kişide toplanmasını engelleyebilir
  • Dış kaynaklarla iç ekip arasındaki koordinasyonu sağlayabilir

İş hedeflerine katılmak

Teknik ortak yalnızca mühendislik toplantılarına katılan kişi değildir. Müşteri, maliyet, gelir modeli ve büyüme hedeflerini anlamalıdır. Teknik önceliklerin iş sonuçlarına nasıl bağlandığını açıklayabilmelidir.

CTO ile teknik ortak aynı şey mi?

Her teknik ortak CTO unvanını kullanmak zorunda değildir. CTO bir görev ve yetki unvanıdır; teknik ortak ise şirketin kuruluşu veya erken aşamasındaki ortaklık rolünü anlatır.

Şu durumlar mümkündür:

  • Teknik ortak aynı zamanda CTO olabilir.
  • Teknik ortak ürün odaklı çalışırken daha deneyimli bir CTO sonradan gelebilir.
  • Şirketin erken aşamasında CTO unvanı kullanılmadan teknik sorumluluk paylaşılabilir.
  • Maaşlı bir CTO, kurucu ortak olmayabilir.

Unvanı erken dağıtmak yerine şu soruları cevaplayın:

  • Teknik kararların sahibi kim?
  • Ürün kapsamına kim katkı veriyor?
  • Ekip kurma sorumluluğu kimde?
  • Güvenlik ve sürdürülebilirlik kararlarını kim takip ediyor?
  • Son teknik kararda hangi mekanizma kullanılıyor?

Ne zaman teknik ortağa ihtiyaç duyabilirsiniz?

Aşağıdaki durumların birkaçı aynı anda varsa teknik ortak ihtimali güçlenir:

  • Ürün, sürekli yazılım geliştirmeye dayanıyor.
  • Teknoloji yalnızca destek işlevi değil temel rekabet avantajı.
  • Teknik kararlar iş modelini belirliyor.
  • Ürün henüz belirsiz ve sık deney gerektiriyor.
  • Kurucu ekibin teknik kararları değerlendirecek yeterliliği yok.
  • Güvenlik, veri veya entegrasyon riski yüksek.
  • Uzun vadede teknik ekip kurulması gerekecek.
  • Teknik geliştirme ile müşteri geri bildirimi sürekli birlikte ilerlemeli.

Ne zaman teknik ortak şart olmayabilir?

Şu durumlarda önce başka model değerlendirilebilir:

  • Basit bir tanıtım sitesi gerekiyor.
  • Kapsamı net ve tek seferlik bir proje var.
  • Hazır no-code veya SaaS araçlarıyla doğrulama yapılabilir.
  • Sorun henüz kullanıcılarla doğrulanmadı.
  • Aranan şey stratejik ortaklık değil belirli uzmanlık.
  • Teknik kararlar şirketin temel farklılaşmasını oluşturmuyor.
  • Kurucu, yalnızca ücretsiz geliştirme kaynağı arıyor.

Özellikle fikir henüz araştırılmadıysa önce kullanıcı görüşmesi ve basit prototip yapmak, teknik ortak aramasını daha anlamlı hâle getirir.

Teknik ortak rol tanımı şablonu

Ürün: Hangi kullanıcı için hangi problemi çözüyor?

Mevcut aşama: Fikir, prototip, çalışan ürün, ilk kullanıcı veya büyüme?

Teknik sorumluluk alanı: Ürün geliştirme, veri, mobil, yapay zekâ, altyapı, güvenlik veya başka bir alan?

İlk 90 günlük çıktılar:

  • Teknik risk değerlendirmesi
  • MVP kapsamı
  • Mimari karar kaydı
  • İlk çalışan sürüm
  • Ölçüm ve geri bildirim altyapısı

Karar yetkileri:

  • Teknik standartlar
  • Araç ve sağlayıcı seçimi
  • Güvenlik kararları
  • Teknik işe alım
  • Dış kaynak kullanımı

Kurucunun diğer katkıları:

  • Kullanıcı araştırması
  • Satış
  • Ürün gereksinimleri
  • Operasyon
  • Finansman

Zaman beklentisi: Haftalık süre, toplantı düzeni ve tam zamanlı geçiş ihtimali.

Ortaklık değerlendirme süreci: Tanışma, teknik inceleme, sınırlı deneme çalışması ve karşılıklı referans kontrolü.

Teknik ortağı değerlendirirken nelere bakılmalı?

Ürün düşüncesi

Aday kullanıcı problemini anlamadan doğrudan teknoloji önermeye mi başlıyor? Gereksiz kapsamı azaltabiliyor mu?

Teknik yargı

Her yeni aracı kullanmak yerine bağlama uygun ve sürdürülebilir karar verebiliyor mu? Kararlarının avantaj ve maliyetini açıklayabiliyor mu?

İletişim

Teknik konuyu teknik olmayan kurucuya anlaşılır biçimde anlatabiliyor mu? Belirsizliği kesinmiş gibi sunuyor mu?

Uygulama

Konuştuğu işleri küçük adımlara bölüp tamamlayabiliyor mu? Çalışan bir çıktı üretebiliyor mu?

Güvenlik ve sorumluluk

Parola, erişim, veri, yedekleme ve fikrî mülkiyet konularını ciddiye alıyor mu?

Ekip yaklaşımı

Her şeyi tek başına kontrol etmek yerine dokümantasyon, kod inceleme ve bilgi paylaşımına önem veriyor mu?

Teknik değerlendirme için teknik uzman desteği

Teknik olmayan kurucu, adayın bütün teknik iddialarını tek başına doğrulamak zorunda değildir. Gerekirse bağımsız ve güvenilir bir teknik danışmandan sınırlı değerlendirme alınabilir.

Değerlendirilebilecek alanlar:

  • Önceki proje veya kod örnekleri
  • Mimari düşünme
  • Güvenlik farkındalığı
  • Kapsam ve tahmin yaklaşımı
  • Teknik borç konusundaki yargı
  • Dokümantasyon ve test alışkanlığı

Amaç en karmaşık kodu yazanı bulmak değil, projenin aşamasına uygun teknik liderliği gösterebilen kişiyi anlamaktır.

İki haftalık teknik ortak deneme planı

Amaç: Ürünün en önemli teknik belirsizliğini birlikte çözmek.

1. gün: Problem, kullanıcı ve mevcut prototip incelemesi 2–3. gün: Teknik risk ve seçeneklerin çıkarılması 4. gün: MVP kapsamının ortak kararı 5–10. gün: Küçük bir prototip veya teknik kanıt 11. gün: Kullanıcı veya ekip geri bildirimi 12–13. gün: Revizyon ve dokümantasyon 14. gün: Çalışma biçimi değerlendirmesi

Değerlendirme soruları:

  • Aday sorunu doğru anladı mı?
  • Kapsamı gerçekçi tuttu mu?
  • Riskleri açıkça iletti mi?
  • Çalışan bir çıktı üretti mi?
  • Geri bildirimle ilerleyebildi mi?
  • Bilgiyi paylaşılabilir bıraktı mı?
  • Birlikte karar verme biçiminiz sağlıklı mıydı?

Yaygın yanlış anlamalar

“Teknik ortak bütün ürünü ücretsiz yapar”

Ortaklık, ücretsiz hizmet alımı değildir. Her iki tarafın devam eden sorumluluğu ve riski olmalıdır.

“En iyi teknik kişi en iyi ortaktır”

Teknik güç önemlidir; ancak iletişim, güven, kullanıcı odaklılık ve zaman ayırma kapasitesi olmadan ortaklık sürdürülemeyebilir.

“Fikir hazırsa geriye yalnızca kod kalır”

Ürün geliştirme sırasında problem, kapsam ve iş modeli değişebilir. Teknik ortak ürün keşfine de katkı verir.

“CTO unvanı verirsek rol netleşir”

Unvan, karar yetkisi ve sorumluluk yazılmadığında belirsizliği çözmez.

Sonuç

Teknik ortak, teknoloji üretimini iş hedefleriyle birleştiren uzun vadeli sorumluluk sahibidir. Her yazılım ihtiyacında teknik ortak aranmaz; önce ihtiyacın proje işi mi, ekip rolü mü yoksa gerçek ortaklık mı olduğunu belirlemek gerekir.

Teknik ortak aramaya karar verdiyseniz rolü yalnızca kullanılan teknolojilerle değil, ilk 90 günde sahiplenilecek sonuçlarla tanımlayın. Ortaksın’daki teknik ortak ilanlarını inceleyebilir veya projenizin aşamasını ve beklediğiniz teknik sorumluluğu anlatan bir ilan oluşturabilirsiniz.

Kaynaklar

3 kaynak

İlgili rehberler

Editörün önerdiği devam okumaları

Tüm rehbere dön