Bu yazı, yatırım sürecinde yatırımcıların yaptığı teknik incelemeye (tech due diligence) hazırlanmak için uygulanabilir bir çerçeve sunar. Yatırımcı tarafında kritik beklenti, yalnızca ürünün “çalışması” değil; ürünün ölçeklenebilir, güvenli, operasyonel olarak sürdürülebilir ve maliyetleri yönetilebilir olmasıdır. Bu nedenle şirketin; mimari netliği (diyagram + karar kayıtları), güvenlik/KVKK kontrollerini, test ve release disiplinini, izleme/olay yönetimini (observability + incident), felaket kurtarma planını (DR) ve FinOps metriklerini (run rate, birim maliyet, kapasite planı) yatırımcıya kanıt olarak sunması gerekir.
Yazıda, teknik hazırlığın en etkili çıktısı olan “Technical Data Room / Kanıt Paketi” tanımlanır; bu paketin hangi dokümanlardan ve metriklerden oluşacağı, hangi soruları cevaplayacağı ve görüşmelerde nasıl kullanılacağı anlatılır. Son bölümde, 14 günlük bir aksiyon planı ile şirketin yatırımcı görüşmesine “hazır” hale gelmesi için pratik bir yol haritası verilir.
Fatih Kemer ·
1) Yatırımcılar teknik tarafta neyi satın alır?
Yatırımcılar yalnızca bugünkü ürünü değil, yarın büyüyebilecek bir teknoloji organizasyonunu satın alır. Bu yüzden teknik due diligence, “kod güzel mi?” kontrolünden çok daha fazlasıdır. Tipik olarak şu 6 soruya net cevap ararlar:
Ölçeklenebilirlik: Trafik/işlem büyüdüğünde sistem nerede zorlanır?
Güvenlik ve regülasyon: Veri korunuyor mu? KVKK/GDPR riskleri yönetiliyor mu?
Operasyonel dayanıklılık: Sistem arıza verdiğinde ekip ne kadar hızlı toparlar (MTTR)?
Teslimat hızı: Takım büyüdüğünde teslimat hızı artacak mı, yoksa teknik borç nedeniyle düşecek mi?
Maliyet disiplini: Büyüme maliyetleri kontrol altında mı? Birim maliyet izleniyor mu?
Gelecek planı: Roadmap ve teknik borç planı gerçekçi mi?
Bu sorulara sözle cevap vermek yerine, doküman + metrik + süreç ile kanıt sunmak, görüşmenin kalitesini ve hızını doğrudan artırır.
2) “Technical Data Room” nedir ve neden gereklidir?
Technical Data Room, yatırımcıya teknik tarafta güven veren, düzenli bir kanıt setidir. İçerik olarak şu kategorilerde hazırlanır:
Mimari netlik: C4 diyagramları, kritik akışlar, entegrasyonlar, veri akışı
Süreç olgunluğu: branch stratejisi, kod review, release yönetimi
Kalite: test stratejisi, coverage hedefleri, regresyon yaklaşımı
Observability: log/metric/trace, alarm yaklaşımı, incident geçmişi
Güvenlik & KVKK: erişim politikaları, secrets, bağımlılıklar, audit log, veri saklama
DR/BCP: yedekleme, felaket kurtarma, RPO/RTO
FinOps: run rate, birim maliyet, kapasite planı, optimizasyon fırsatları
Roadmap: ürün hedefleri ile teknik yatırımların eşleştirilmesi
Bu paket sayesinde yatırımcı “neden risk almamalıyım?” sorusuna cevap bulur; siz de görüşmede sürekli savunmada kalmak yerine proaktif ilerlersiniz.
3) Mimari netlik: “Sistemi 5 dakikada anlatabiliyor musunuz?”
Yatırımcı teknik ekibi genellikle ilk olarak “şu anki mimariyi” anlamak ister. Burada amaç; karmaşık detaylara boğmak değil, büyüme risklerini görünür kılmaktır.
Minimum mimari çıktılar:
C4 Level 1–2: sistem sınırları ve ana bileşenler (FE, API, DB, mesajlaşma, üçüncü parti servisler)
Kritik akış diyagramları: para kazandıran veya riskli akışlar (ödeme, onboarding, üyelik, sipariş vb.)
Veri modeli özeti: kritik tablolar, tutarlılık, migration stratejisi
ADR (Architecture Decision Records): “neden bu teknoloji/karar?” kayıtları
Yatırımcı açısından mimari netlik, “takım büyürse yönetilebilir mi?” sorusunun temelidir.
4) Kalite ve test: Büyümenin sigortası
Yatırımcılar test konusunu “mükemmel coverage” olarak değil, regresyon riskini yönetme kabiliyeti olarak değerlendirir.
Beklenen minimumlar:
Kritik akışlar için smoke test (en azından canlı sonrası doğrulama)
API tarafı için integration test
Ürün akışları için E2E regresyon seti (checkout/onboarding gibi)
“Definition of Done” içinde test ve kalite kriterleri
Görüşmede güçlü etki yaratan örnekler:
Son 30–90 günde regresyon oranı ve nasıl düştüğü
Testlerin pipeline’da çalışması ve release’e “gate” olması
Bugfix/incident sonrası aksiyonların testlere yansıması (postmortem çıktısı)
5) CI/CD ve release güvenliği: “Deploy korkusu” yatırımcı riskidir
Yatırımcı, ekibin release yapma disiplinini “operasyonel olgunluk” göstergesi olarak görür. Çünkü release yapamayan ekip; hızlı iterasyon yapamaz, müşteri taleplerine yetişemez ve teknik borç biriktirir.
Olgun bir release yapısının göstergeleri:
Pipeline: build → test → security scan → deploy
Ortam ayrımı: dev / stage / prod
Rollback (dökümante edilmiş, test edilmiş)
Feature flag / staged rollout
Versiyonlama ve release notları
En kritik nokta: “Canlıya çıkmak” değil, güvenle canlıya çıkmak.
6) Observability ve incident yönetimi: “Sorun çıkınca ne oluyor?”
Bir ürün büyüdüğünde sorun kaçınılmazdır; yatırımcı ekibin sorunla nasıl başa çıktığını ölçer.
Sunulması gereken metrikler:
Uptime (30/90 gün)
p95 latency
Error rate
Incident sayısı ve MTTR (ortalama çözüm süresi)
Sunulması gereken süreçler:
Postmortem kültürü (kök neden + aksiyon maddeleri)
Observability, yatırımcıya “bu ürün satılabilir” kadar “bu ürün sürdürülebilir” mesajı verir.
7) Güvenlik ve KVKK: En pahalı risk kalemi
Due diligence’da güvenlik, çoğu zaman görüşmenin tonunu belirler. Zayıf güvenlik; yatırımcı için doğrudan “reputational risk” ve “financial risk” demektir.
Minimum güvenlik kanıtları:
Secrets yönetimi (env/vault, erişim politikaları)
Bağımlılık taraması (SCA) ve kritik açıkların planı
RBAC ve audit log
SAST/DAST veya en azından temel güvenlik taraması
KVKK: veri saklama politikası, silme/anonymization, yetkilendirme, erişim logları
İyi yaklaşım: Açıkları saklamak yerine, “gap listesi + aksiyon planı” ile yönetmek.
8) DR/BCP: “Bir gün her şey durursa ne olacak?”
Yatırımcılar felaket kurtarma planını “olursa bakarız” seviyesinde görmek istemez.
Net cevaplanması gerekenler:
RPO (ne kadar veri kaybı tolere edilir?)
RTO (ne kadar sürede ayağa kalkmalı?)
Backup sıklığı, test edilmiş restore prosedürü
Kritik bağımlılıklar ve tek noktadan hata riskleri
Bu bölüm, özellikle B2B ve kritik sektörlerde görüşmenin kilit noktası olabilir.
9) FinOps: Büyüme ile maliyet aynı hızda artmamalı
Yatırımcı büyümeyi sever; ama “kontrolsüz maliyet” büyümeyi değersizleştirir. Bu nedenle teknik hazırlık paketinde FinOps çıktıları giderek daha önemli hale geldi.
Hazırlanması gereken temel veriler:
Run rate: aylık altyapı maliyeti (cloud, DB, servisler)
Birim maliyet: kullanıcı başı / işlem başı maliyet
Kapasite planı: 2x/5x büyümede hangi bileşenler ölçeklenecek?
Optimizasyon fırsatları: cache/CDN, right-sizing, reserved capacity vb.
Yatırımcıya verilen mesaj: “Biz büyümeyi değil, kârlı büyümeyi planlıyoruz.”
10) Roadmap + teknik borç: Yatırım sonrası hızlanma planı
Yatırımcılar “yatırım sonrası ne olacak?” sorusuna teknik tarafta şu yanıtı bekler:
Roadmap net
Teknik borç saklanmıyor
Öncelikler disiplinli
Sağlam bir model:
Ürün hedefleri (gelir, retention, churn) ile teknik hedefleri (performans, güvenlik, refactor) eşleştirmek
Her çeyrekte 1–2 teknik “must-have” iyileştirme kalemi koymak
Borcu “bütçelendirmek” (sprint kapasitesinin belirli yüzdesi)
14 Günlük Aksiyon Planı (Pratik)
Gün 1–2: Teknik envanter + risk haritası + erişim kontrol listesi
Gün 3–5: Mimari diyagramlar + ADR + kritik akış dokümantasyonu
Gün 6–8: CI/CD dokümantasyonu + release/rollback prosedürü + smoke test seti
Gün 9–10: Güvenlik taraması + KVKK checklist + gap planı
Gün 11–12: Observability metrikleri + incident raporu (MTTR/postmortem örneği)
Gün 13–14: FinOps raporu + birim maliyet + kapasite planı + roadmap paketleme