Dijital İşletmelerde Teknik Due Diligence: Kaynak Koddan Altyapıya Neler İncelenir?

Bir dijital işletmenin gelir ve müşteri metrikleri güçlü olabilir.

Ancak ürünün arkasındaki teknik altyapı sağlıklı değilse satın alma sonrasında önemli maliyetler ve operasyonel riskler ortaya çıkabilir.

Özellikle Micro-SaaS, mobil uygulama ve web uygulaması satın alımlarında alıcının yalnızca:

• gelir
• churn
• müşteri sayısı
• büyüme

gibi ticari metrikleri değil, işletmenin teknik olarak sürdürülebilir olup olmadığını da değerlendirmesi gerekir.

Bu süreç genel olarak teknik due diligence olarak adlandırılır.

Teknik Due Diligence Nedir?

Teknik due diligence, bir yazılım veya teknoloji tabanlı işletmenin teknik durumunun satın alma öncesinde incelenmesidir.

Amaç yalnızca:

Kod çalışıyor mu?

sorusuna cevap vermek değildir.

Asıl amaç şunları anlamaktır:

• Sistem sürdürülebilir mi?
• Kaynak kod gerçekten satıcıya mı ait?
• Kritik teknik riskler var mı?
• Yeni sahibi ürünü çalıştırmaya devam edebilir mi?
• Büyük bir rewrite gerekiyor mu?
• Üçüncü taraf servis bağımlılıkları ne kadar yüksek?
• Güvenlik veya veri kaybı riski var mı?
• Teknik altyapı yeni sahibine transfer edilebilir mi?

Teknik due diligence bu sorulara sistematik şekilde cevap arar.

Küçük Bir Dijital İşletmede Teknik Due Diligence Gerekli mi?

Evet.

İşletmenin küçük olması teknik riskin de küçük olduğu anlamına gelmez.

Tam tersine Micro-SaaS işletmelerinde:

• tüm sistemi tek kişi geliştirmiş olabilir
• dokümantasyon bulunmayabilir
• deployment manuel olabilir
• backup hiç test edilmemiş olabilir
• kritik servisler kurucunun kişisel hesabına bağlı olabilir

Bu nedenle küçük bir işletmede birkaç teknik problem işletmenin ekonomik değerinin büyük bölümünü etkileyebilir.

1. Kaynak Kodun Sahipliğini Doğrulayın

İlk sorulardan biri şudur:

Satıcı bu kaynak kodun gerçekten sahibi mi?

Kodun GitHub üzerinde bulunması tek başına yeterli değildir.

Kod geçmişte:

• freelancer
• ajans
• eski çalışan
• eski ortak
• dış kaynak developer

tarafından geliştirilmiş olabilir.

İncelenebilecek konular:

• repository geçmişi
• contributor listesi
• freelancer sözleşmeleri
• IP assignment hükümleri
• kullanılan hazır script veya template'ler
• açık kaynak lisansları

Alıcı satın aldığı yazılımın fikri mülkiyet haklarının açık olduğundan emin olmalıdır.

2. Repository Yapısını İnceleyin

Tek bir repository işletmenin tamamı olmayabilir.

Örneğin sistem şu parçalardan oluşabilir:

• frontend
• backend
• mobile app
• admin panel
• background worker
• infrastructure scripts
• shared libraries

Bu nedenle tüm repository'lerin listesi çıkarılmalıdır.

Kontrol edilebilecek sorular:

• Kaç repository var?
• Hangileri production için gerekli?
• Private package bulunuyor mu?
• Deployment scriptleri nerede?
• Eski ancak hala kullanılan repository var mı?

Eksik bir repository transferi closing sonrasında sistemi çalıştırmayı zorlaştırabilir.

3. Teknoloji Stack'ini Anlayın

Alıcı kullanılan teknolojileri anlamalıdır.

Örneğin:

• backend framework
• frontend framework
• database
• mobile technology
• cloud provider
• queue sistemi
• cache
• search infrastructure

incelenebilir.

Buradaki amaç belirli bir teknolojiyi iyi veya kötü olarak etiketlemek değildir.

Asıl sorular şunlardır:

• Teknoloji hala destekleniyor mu?
• Developer bulmak kolay mı?
• Kritik dependency'ler güncel mi?
• İşletme eski veya terk edilmiş bir framework'e mi bağlı?

4. Teknik Borcu Değerlendirin

Technical debt, kısa vadede çalışan ancak gelecekte bakım ve geliştirme maliyeti yaratabilecek teknik kararları ifade eder.

Örnekler:

• eski dependency'ler
• test eksikliği
• tekrar eden kod
• manuel deployment
• karmaşık database yapısı
• dokümantasyon eksikliği
• geçici çözümlerin kalıcı hale gelmesi

Her teknik borç kritik değildir.

Önemli olan teknik borcun:

• sistem güvenilirliğini
• geliştirme hızını
• güvenliği
• bakım maliyetini

ne kadar etkilediğidir.

5. Rewrite Gerekiyor mu?

Alıcıların dikkat etmesi gereken önemli konulardan biri budur.

Developer'ların:

Bu kod kötü, baştan yazmak lazım.

demesi her zaman gerçek bir business requirement değildir.

Rewrite ciddi:

• zaman
• maliyet
• operasyon riski

yaratabilir.

Teknik due diligence sırasında daha doğru soru:

Mevcut sistem işletmenin önümüzdeki birkaç yılındaki ihtiyaçlarını karşılayabiliyor mu?

olmalıdır.

Kod estetik olarak mükemmel olmayabilir.

Ancak stabil, güvenli ve sürdürülebilir ise tamamen yeniden yazılması gerekmeyebilir.

6. Test Altyapısını İnceleyin

Test bulunması yazılımın bakımını kolaylaştırabilir.

İncelenebilecek alanlar:

• unit tests
• integration tests
• end-to-end tests
• manual test süreçleri

Test coverage'ın düşük olması tek başına işlemin iptal edilmesini gerektirmez.

Ancak kritik ödeme, authentication veya billing süreçlerinin hiç test edilmemesi risk seviyesini artırabilir.

7. Deployment Sürecini Anlayın

Yeni bir versiyon production'a nasıl çıkıyor?

Örneğin:

• GitHub Actions
• Azure DevOps
• GitLab CI
• manuel publish
• doğrudan server'a dosya kopyalama

kullanılıyor olabilir.

Kontrol edilmesi gereken sorular:

• Deployment tek kişi tarafından mı biliniyor?
• Rollback yapılabiliyor mu?
• Production secret'ları nerede tutuluyor?
• Deployment sırasında downtime oluşuyor mu?
• CI/CD pipeline dokümante mi?

Kurucu olmadan deployment yapılamıyorsa önemli founder dependency bulunmaktadır.

8. Hosting ve Cloud Yapısını İnceleyin

İşletmenin nerede çalıştığı açık olmalıdır.

Örneğin:

• AWS
• Azure
• Google Cloud
• DigitalOcean
• Vercel
• fiziksel veya sanal sunucu

kullanılabilir.

İncelenecek alanlar:

• sunucu maliyetleri
• resource kullanımı
• scaling
• region
• database hosting
• storage
• CDN
• DNS
• SSL

Alıcı yalnızca mevcut faturayı değil, altyapının büyüme durumunda nasıl davranacağını da anlamalıdır.

9. Cloud Hesaplarının Sahipliğini Kontrol Edin

Teknik olarak çalışan sistem, transfer açısından problemli olabilir.

Örneğin production AWS hesabı kurucunun kişisel e-postasına bağlı olabilir.

Bu durumda closing sırasında:

• account ownership
• billing
• MFA
• admin users
• IAM

yeniden yapılandırılmalıdır.

Aynı durum domain, GitHub ve diğer kritik hesaplar için de geçerlidir.

10. Database Yapısını İnceleyin

Database işletmenin en kritik varlıklarından biri olabilir.

Kontrol edilebilecek alanlar:

• database teknolojisi
• schema yapısı
• index'ler
• büyüklük
• performans
• migration sistemi
• backup
• restore süreci

Özellikle şu soru önemlidir:

Backup gerçekten restore edilebiliyor mu?

Backup dosyasının bulunması yeterli değildir.

Hiç test edilmemiş backup sistemi gerçek bir güvence sağlamayabilir.

11. Backup ve Disaster Recovery

İşletme önemli bir sistem kaybından sonra ne kadar hızlı geri dönebilir?

Kontrol edilebilecek konular:

• backup sıklığı
• backup lokasyonu
• retention süresi
• database backup
• file backup
• source-code backup
• disaster recovery prosedürü

Örneğin database her gece yedekleniyor ancak aynı sunucuda tutuluyorsa sunucu kaybında backup da kaybolabilir.

12. Monitoring Var mı?

Production sistemlerinin çalışıp çalışmadığı nasıl takip ediliyor?

Örneğin:

• uptime monitoring
• error tracking
• log monitoring
• performance monitoring
• alerting

bulunabilir.

Monitoring yoksa kritik bir hata müşteriler bildirmeden fark edilmeyebilir.

Bu özellikle küçük ve kurucunun sürekli sistemi takip ettiği işletmelerde sık görülen bir risk olabilir.

13. Security İncelemesi

Teknik due diligence sırasında temel güvenlik kontrolleri de yapılmalıdır.

Örneğin:

• MFA kullanılıyor mu?
• Secret key'ler source code içerisinde mi?
• Production database internete açık mı?
• Kullanıcı şifreleri güvenli şekilde tutuluyor mu?
• Kritik dependency'lerde güvenlik açığı var mı?
• Admin panel yeterince korunuyor mu?
• Access control doğru çalışıyor mu?

Amaç her küçük işletmeye enterprise seviyesinde güvenlik standardı uygulamak değildir.

Riskin işletmenin büyüklüğüne göre makul olup olmadığını değerlendirmektir.

14. Secret ve Credential Yönetimi

Aşağıdaki bilgilerin nasıl saklandığı incelenmelidir:

• database password
• API key
• payment secret
• cloud credentials
• SMTP password
• OAuth secrets

Bu değerlerin doğrudan:

• source code
• public repository
• configuration file

içerisinde bulunması risk oluşturabilir.

Closing sonrasında kritik secret'ların rotate edilmesi de planlanmalıdır.

15. Authentication ve Authorization

Kullanıcı hesapları bulunan işletmelerde:

• login sistemi
• password reset
• MFA
• role management
• admin authorization

incelenebilir.

Özellikle admin işlemlerinin yalnızca frontend kontrolüne dayanması ciddi risk yaratabilir.

Backend tarafında authorization mekanizmasının bulunması önemlidir.

16. Üçüncü Taraf API Bağımlılıkları

Birçok Micro-SaaS başka platformlara bağlı çalışır.

Örneğin:

• OpenAI
• Google
• Stripe
• Twilio
• SendGrid
• AWS
• Shopify

gibi servisler kritik olabilir.

Her servis için şu sorular sorulabilir:

• Servis olmadan ürün çalışıyor mu?
• Alternatif sağlayıcı var mı?
• API fiyatı artarsa ne olur?
• Kullanım limiti var mı?
• Hesap transfer edilebilir mi?
• API değişirse ürün ne kadar etkilenir?

Tek bir API'ye tam bağımlılık önemli platform riskidir.

17. Third-Party SaaS Bağımlılıkları

Teknik altyapı yalnızca API'lerden oluşmaz.

İşletme:

• monitoring
• analytics
• email
• support
• automation
• database
• CDN

için birçok SaaS aracı kullanıyor olabilir.

Bu servislerin:

• aylık maliyeti
• sahibi
• login yöntemi
• transfer edilebilirliği

belirlenmelidir.

18. Payment Infrastructure

Gelir üreten bir işletmede ödeme altyapısı kritik teknik varlıktır.

Kontrol edilebilecek alanlar:

• Stripe veya Paddle entegrasyonu
• webhook'lar
• subscription lifecycle
• failed payment handling
• refunds
• invoice sistemi
• currency işlemleri

Satın alma sonrasında payment account değişecekse migration riskleri ayrıca değerlendirilmelidir.

19. Analytics ve Event Tracking

Alıcı işletmenin geçmiş performansını anlayabilmek için doğru analytics verisine ihtiyaç duyar.

Kontrol edilebilecek araçlar:

• Google Analytics
• Mixpanel
• PostHog
• internal analytics

Ancak yalnızca analytics hesabının bulunması yeterli değildir.

Event'lerin doğru ölçülüp ölçülmediği de değerlendirilmelidir.

Yanlış event tracking, due diligence sırasında yanlış ürün metrikleri üretebilir.

20. Data Privacy ve Veri Saklama

İşletme kişisel veri işliyorsa teknik yapı açısından şu alanlar incelenebilir:

• hangi verilerin tutulduğu
• nerede tutulduğu
• ne kadar süre saklandığı
• kimlerin erişebildiği
• silme süreçleri
• backup içerisindeki kişisel veriler

Bu alan teknik ve hukuki due diligence'ın kesişimindedir.

21. Scaling Problemleri Var mı?

Bugün 1.000 müşteride çalışan sistem 10.000 müşteride de çalışacak mı?

Her satın alma büyüme hedeflemeyebilir.

Ancak sistemin mevcut kapasitesine ne kadar yakın olduğu bilinmelidir.

Kontrol edilebilir:

• CPU ve memory kullanımı
• database performansı
• queue backlog
• API limitleri
• storage büyümesi
• maliyet artışı

Scaling sorunu gelecekte önemli yatırım gerektirebilir.

22. Kritik Single Point of Failure'ları Bulun

Single point of failure, tek bir parçanın bozulmasıyla tüm sistemin durmasına neden olan bağımlılıktır.

Örneğin:

• tek server
• tek developer
• tek database
• tek API
• tek admin account

olabilir.

Her single point of failure mutlaka ortadan kaldırılmak zorunda değildir.

Ancak alıcının bunları bilmesi ve riskini fiyatlaması gerekir.

23. Teknik Dokümantasyon

İdeal olarak şu alanlarda dokümantasyon bulunabilir:

• sistem mimarisi
• deployment
• database
• API entegrasyonları
• environment variables
• troubleshooting
• backup
• monitoring

Micro-SaaS işletmelerinde dokümantasyon genellikle sınırlıdır.

Bu tek başına büyük problem olmayabilir.

Ancak sistem yalnızca kurucunun hafızasında yaşıyorsa transfer riski yüksektir.

24. Developer Dependency

Kodun bakımını kim yapıyor?

Örneğin:

• kurucu
• freelancer
• ajans
• full-time developer

olabilir.

Eğer yalnızca bir freelancer sistemi biliyorsa şu sorular sorulmalıdır:

• Satış sonrası devam edecek mi?
• Saatlik ücreti ne kadar?
• Kaynak kod hakları açık mı?
• Alternatif developer sisteme ne kadar hızlı adapte olabilir?

Bu risk operasyon maliyetini doğrudan etkileyebilir.

Teknik Due Diligence'da Red Flag'ler

Aşağıdaki durumlar daha detaylı inceleme gerektirebilir:

• kaynak kod sahipliğinin belirsiz olması
• kritik repository'nin eksik olması
• hiç backup bulunmaması
• backup restore sürecinin test edilmemiş olması
• production secret'ların repository'de bulunması
• kritik sistemin tek kişiye bağlı olması
• terk edilmiş teknoloji kullanılması
• ağır teknik borç
• dokümantasyon bulunmaması
• payment sisteminin transfer edilememesi
• kritik üçüncü taraf hesabın satıcıya kişisel olarak bağlı olması
• ciddi güvenlik açığı
• sistemin sürekli production problemi yaşaması

Bir red flag otomatik olarak işlemin iptal edilmesi gerektiği anlamına gelmez.

Önemli olan:

• riskin büyüklüğü
• çözüm maliyeti
• çözüm süresi
• işletmenin değerine etkisi

dir.

Teknik Risk Değerlemeyi Nasıl Etkiler?

Teknik sorunlar doğrudan purchase price üzerinde etkili olabilir.

Örneğin işletmenin:

• SDE: 100.000 dolar
• teorik değeri: 350.000 dolar

olsun.

Due diligence sırasında alıcının:

• 30.000 dolar teknik borç temizliği
• 20.000 dolar infrastructure migration
• 10.000 dolar security iyileştirmesi

gerektiğini düşündüğünü varsayalım.

Toplam tahmini ek yatırım:

60.000 dolar

olur.

Alıcı bu maliyeti:

• satın alma fiyatında discount
• holdback
• closing öncesi satıcı tarafından düzeltme

şeklinde işlem yapısına yansıtmak isteyebilir.

Bu nedenle teknik due diligence yalnızca developer'ların yaptığı bir kod incelemesi değildir.

Doğrudan ekonomik due diligence'ın bir parçasıdır.

Teknik Due Diligence Kontrol Listesi

Kaynak Kod

• Tüm repository'ler mevcut mu?
• Kaynak kod sahipliği açık mı?
• Contributor'lar belli mi?
• Third-party lisanslar kontrol edildi mi?

Architecture

• Tech stack güncel mi?
• Kritik sistemler nasıl bağlı?
• Single point of failure var mı?

Technical Debt

• Kritik teknik borç var mı?
• Rewrite gerçekten gerekiyor mu?
• Bakım maliyeti makul mü?

Infrastructure

• Hosting nerede?
• Cloud hesapları transfer edilebilir mi?
• DNS ve SSL yönetimi açık mı?

Database

• Database yapısı anlaşılır mı?
• Backup var mı?
• Restore test edildi mi?
• Performance problemi var mı?

Security

• MFA kullanılıyor mu?
• Secret management doğru mu?
• Admin erişimleri korunuyor mu?
• Kritik güvenlik açıkları var mı?

Deployment

• Deployment dokümante mi?
• CI/CD var mı?
• Rollback yapılabiliyor mu?

Monitoring

• Uptime izleniyor mu?
• Error tracking var mı?
• Kritik alarmlar mevcut mu?

Third-Party Dependencies

• Kritik API'ler neler?
• Alternatifleri var mı?
• Hesaplar transfer edilebilir mi?

Payment

• Subscription sistemi çalışıyor mu?
• Webhook'lar güvenilir mi?
• Payment provider migration riski var mı?

Transferability

• Yeni developer sistemi devralabilir mi?
• Teknik bilgi yalnızca kurucuda mı?
• Kritik hesapların sahipliği değiştirilebilir mi?

Alıcı Teknik Due Diligence Sonunda Neyi Bilmelidir?

İnceleme tamamlandığında alıcı şu sorulara mümkün olduğunca net cevap verebilmelidir:

1. Ürün bugün teknik olarak stabil mi?
2. En büyük üç teknik risk nedir?
3. Closing sonrası hangi teknik işler yapılmalı?
4. Bunların tahmini maliyeti nedir?
5. İşletme mevcut kurucu olmadan çalışabilir mi?
6. Tüm kritik teknik varlıklar transfer edilebilir mi?
7. Önümüzdeki 12 ay büyük teknik yatırım gerekiyor mu?

Bu soruların cevapları satın alma kararının ekonomik kısmına doğrudan dahil edilmelidir.

Sonuç

Teknik due diligence'ın amacı mükemmel kod bulmak değildir.

Küçük dijital işletmelerin büyük bölümünde:

• teknik borç
• manuel süreçler
• eksik dokümantasyon
• belirli third-party bağımlılıkları

bulunabilir.

Asıl soru bu problemlerin var olup olmadığı değil, ne kadar ciddi olduklarıdır.

İyi bir teknik due diligence:

• kritik riskleri belirler
• transfer problemlerini ortaya çıkarır
• satın alma sonrası yatırım ihtiyacını tahmin eder
• işletmenin yeni sahibine sürdürülebilir şekilde geçip geçemeyeceğini değerlendirir

Bu nedenle bir yazılım işletmesini satın alırken yalnızca:

Ürün bugün çalışıyor mu?

sorusunu sormak yeterli değildir.

Daha önemli soru şudur:

Bu ürünün teknik altyapısı yeni sahibinin kontrolünde güvenli, sürdürülebilir ve ekonomik şekilde çalışmaya devam edebilir mi?