Kurumsal Yazılım Geliştirme Şirketi Seçimi: 2026 CTO Checklist (38 Soru)

Yazılım tedarikçisi seçimi çoğu projede ihale yöntemiyle yapılıyor:

3-5 firmadan teklif al, en ucuzu ya da en iyi sunum yapanı seç, sözleşme imzala.

Bu yöntem 3 sebepten kötü:

Teklif fiyatı, gerçek maliyetin yalnızca %30-40’ını gösterir. Geri kalanı sözleşmenin imzalanmasından sonra ortaya çıkar. Kapsam kayması, hata düzeltme sözleşmeleri ve devir eksikleri buna dahildir.

Sunum kalitesi, ekip kalitesi anlamına gelmez. Demoyu yapan satış mühendisi projede çalışmayacak olabilir.

Referans görüşmelerinin %80’i pozitif geri bildirim verir. Çünkü tedarikçi yalnızca mutlu müşterileri listeler.

Aşağıdaki 38 soruluk kontrol listesi, 16 yıllık özel yazılım deneyimimizden, hem yürüttüğümüz hem de kurtarmaya çağrıldığımız sorunlu projelerden derlendi.

Soruların büyük bölümü tedarikçiyi zorlar. Cevaplar ise size teklif dokümanından çok daha fazlasını öğretir.

Bu yazıda her kategori için soruları, neden önemli olduklarını, nasıl test edeceğinizi ve kırmızı bayrakları paylaşıyoruz.

Kategori 1: Teknik Yetkinlik ve Teknoloji Uyumu

Burada amacımız “biliyorlar mı?” sorusunu sormak değil.

Asıl soru şu:

“Bu projeye uygun şekilde biliyorlar mı?”

1. Bu projeye benzer ölçekte 3 canlı kullanım örneği gösterebilir misiniz?

Neden önemli?

“Yapabiliriz” diyen herkes, “yaptık” demiyor.

Nasıl test edilir?

Canlı URL’yi ya da müşterinin kabul ettiği canlı bir aşamayı isteyin.

“NDA var” dedikleri her projeyi referans kabul etmeyin.

Kırmızı bayrak:

3 vakanın 3’ü de “NDA altında” ise ya gerçekten yoktur ya da başarılı değildir.

2. Bu projedeki ana 3 teknik riski şu an söyleyebilir misiniz?

Neden önemli?

Keşif çalışması yapmadan risk söyleyebilen tedarikçi, deneyimden konuşur.

Nasıl test edilir?

Cevabın genel mi yoksa spesifik mi olduğuna bakın.

“Ölçeklenebilirlik önemli” zayıf bir cevaptır.

“Ödeme altyapısında Türkiye’deki yan ödeme senaryoları için PayU + Iyzico yedek akışı gerekebilir” gibi bir cevap daha güçlüdür.

3. Teknoloji tercihinizin nedeni nedir? Alternatifi neydi?

Neden önemli?

Tedarikçiler genelde doğru olanı değil, en iyi bildiklerini önerir.

Nasıl test edilir?

“Neden Node yerine .NET değil?” gibi alternatif bir soruyla sıkıştırın.

Hızla “ekibimiz bunu daha iyi biliyor” diyen tedarikçi, sizin için en doğru teknolojiyi seçiyor olmayabilir.

4. Bulut ve altyapı maliyeti tahminini şimdi yapabilir misiniz?

Neden önemli?

İyi tedarikçi yalnızca kodu değil, toplam sahip olma maliyetini de düşünür.

Nasıl test edilir?

AWS, Google Cloud veya Azure için aylık tahmini ve ölçeklenme noktalarını isteyin.

Bunu yapamayan tedarikçi genelde geliştirme aşamasından ötesini yeterince düşünmemiştir.

5. Sürekli entegrasyon, otomatik test ve izleme nasıl kuruluyor? Sıfırdan örnek anlatın.

Neden önemli?

“Modern teknoloji kullanıyoruz” diyen tedarikçilerin önemli bir bölümünde canlı ortam izleme yapısı yoktur.

Nasıl test edilir?

Araç isimlerini isteyin.

Örneğin GitHub Actions, GitLab CI, Argo, Jenkins, Datadog, Grafana, New Relic veya Sentry gibi araçlardan bahsedebilmeli.

Genel cevap veriyorsa büyük ihtimalle yapmıyordur.

6. Önceki bir projede yaptığınız en büyük teknik hata neydi?

Neden önemli?

Bu tek başına en güçlü testlerden biridir.

Hatasını anlatabilen ekip, ondan ders almıştır.

Kırmızı bayrak:

“Hata yapmadık” cevabı ya gerçek dışıdır ya da deneyimsizlik göstergesidir.

Kategori 2: Süreç ve Metodoloji

“Agile çalışıyoruz” cümlesi tek başına bilgi vermez.

Spesifik süreci sormanız gerekir.

7. Keşif fazını ne kadar tutarsınız ve çıktısı ne olur?

Beklenen cevap:

2-4 hafta arası keşif süreci ve somut çıktılar.

Örneğin teknik doküman, kullanıcı hikâyeleri, risk kaydı ve kilometre taşı planı.

Kırmızı bayrak:

“Keşifsiz başlayabiliriz” cevabı.

Bu durumda kapsam kayması neredeyse kaçınılmazdır.

8. Sprint’ler nasıl planlanır? Hızı kim takip eder?

Beklenen cevap:

1-2 haftalık sprint’ler, sprint planlama, gözden geçirme ve geriye dönük değerlendirme toplantıları.

Ayrıca scrum master veya teknik lider tarafından iş ilerleme grafiğinin takip edilmesi.

9. Kod incelemesi nasıl yapılır?

Beklenen cevap:

Her kod birleştirme isteği en az 1 kıdemli kişi tarafından incelenir.

Otomatik kod kontrolü, test kapısı ve birleştirme blokları vardır.

Kırmızı bayrak:

“Kodu yazan kişi kendisi birleştirebilir” cevabı.

Bu kalite kontrolü olmadığını gösterir.

10. Kalite güvence dağılımı nasıl? Geliştiricilerin manuel testi yeterli mi, ayrı kalite ekibi var mı?

Beklenen cevap:

Karma model.

Birim testler geliştiricilerde, entegrasyon testi, kullanıcı kabul testi ve geriye dönük testler ayrı kalite ekibinde olmalı.

Otomatik testler de sürece dahil edilmeli.

11. Hata bulunduğunda hizmet seviyesi taahhüdünüz nedir? Canlı ortamda kritik hataya tepki süreniz ne?

Beklenen cevap:

Kritik seviye hata için 2 saatten kısa tepki, 24 saatten kısa çözüm hedefi.

12. Bir kilometre taşı gecikirse iletişim ne zaman ve nasıl gelir?

Beklenen cevap:

Gecikme tahmin edilir edilmez, ideal olarak 1-2 sprint öncesinden bilgi verilir.

Neden, etki ve çözüm planı birlikte paylaşılır.

Kırmızı bayrak:

“Sorun çıkarsa söyleriz” cevabı.

Bu genelde sorunu son anda söyleyecekleri anlamına gelir.

Kategori 3: Ekip Yapısı ve Stabilite

Sunum yapan ekip, projede çalışacak ekip anlamına gelmez.

Bu kategori çoğu CTO’nun atladığı yerdir.

13. Bu projede çalışacak ekibin CV’lerini görebilir miyim?

Beklenen cevap:

İsim, rol, deneyim yılı ve önceki proje listesi paylaşılmalı.

Projede gerçekten çalışacak mühendislerin profili net olmalı.

Kırmızı bayrak:

“Ekip projeye atanınca paylaşırız” cevabı.

Bu büyük ihtimalle henüz kaynak planlaması yapılmadığını gösterir.

14. Kıdemli, orta seviye ve junior ekip oranı nedir?

Beklenen cevap:

Kıdemli ekip oranı %25-40, orta seviye %40-50, junior %15-25 bandında olabilir.

Tamamen junior ekip ucuz görünür ama yeniden iş yapma ve devir maliyetleriyle pahalıya gelir.

15. Yıllık ekip değişim oranınız nedir?

Beklenen cevap:

%15-25 arası makul kabul edilebilir.

Türkiye’de sektör ortalaması yaklaşık %20-30 bandındadır.

%40 üzeri, ekip stabilitesinin zayıf olduğunu gösterir.

Bu da projenizin sürekli bilgi devriyle zarar görmesi anlamına gelebilir.

16. Bu projede çalışacak kişiler aynı anda kaç başka projeye ayrılmış durumda?

Beklenen cevap:

1.0 tam zamanlı eşdeğer, yani yalnızca sizin projenizde çalışmaları idealdir.

0.5-0.75 tam zamanlı eşdeğer kabul edilebilir.

0.25 altı ise projeye gerçek kapasite ayrılmadığını gösterir.

17. Hangi roller Türkiye’de, hangileri farklı lokasyonda çalışıyor?

Neden önemli?

Bazı tedarikçiler Türkiye’de küçük bir ekip gösterir, gerçek geliştirmeyi farklı ülkelerdeki ekiplerle yürütür.

Saat farkı ve iletişim sorunları sözleşmeden sonra ortaya çıkar.

Bu nedenle rollerin lokasyonu net olmalıdır.

Kategori 4: Şeffaflık ve Raporlama

Yazılım projelerinde “iyi gidiyor” cümlesi en pahalı yanıltıcı ifadelerden biridir.

Görünürlük olmadan kontrol olmaz.

18. Kod deposu erişimini ilk günden alabilir miyim?

Beklenen cevap:

Evet.

En azından okuma erişimi verilmelidir.

GitHub, GitLab veya Bitbucket erişimi ilk günden açılmalıdır.

Kırmızı bayrak:

“Proje sonunda devrederiz” cevabı.

Bu durumda kod sizin değil, fiilen onların kontrolündedir.

19. Sprint sonu demolarda gerçek kodu canlı görebilir miyim, yoksa sadece sunum mu yapılacak?

Beklenen cevap:

Her sprint sonunda çalışan ortamda demo yapılmalıdır.

Bu ortam geliştirme veya test ortamı olabilir.

Yalnızca slayt üzerinden ilerlenmemelidir.

20. Saatlik ya da iş puanı bazında gerçek harcanan eforu görebilecek miyiz?

Beklenen cevap:

Jira, Linear, ClickUp veya benzeri bir araçtan görünürlük sağlanmalıdır.

Kırmızı bayrak:

“Bu detaya gerek yok, biz sabit fiyat çalışıyoruz” cevabı.

Değişiklik olduğunda kapsam tartışmasını kaybetme ihtimaliniz artar.

21. Geliştirme hızı, hata oranı ve yayına alma sıklığı gibi metrikleri raporluyor musunuz?

Beklenen cevap:

Aylık rapor ve bu metriklerin trend olarak paylaşılması.

22. Keşif sonrası kapsam değişikliğinde nasıl iletişim kuruyorsunuz?

Beklenen cevap:

Değişiklik talebi yazılı alınır.

Efor, maliyet ve takvim etkisi analiz edilir.

Onay sonrası devam edilir.

23. Yazılım kalitesi metrikleri raporlanıyor mu?

Beklenen cevap:

Test kapsamı, teknik borç ve kod kalite raporları paylaşılmalıdır.

Test kapsamı için %70 üzeri hedeflenebilir.

SonarQube veya benzeri bir kod kalite aracı kullanılabilir.

Kategori 5: Sözleşme, Fiyatlandırma ve Fikri Mülkiyet

Çoğu pahalı sorun burada gizlenir.

24. Fiyatlandırma modeli nedir? Sabit fiyat, zaman ve malzeme, sonuç odaklı model? Hangisi ve neden?

Beklenen cevap:

Keşif sonrası karar verilmesi en sağlıklısıdır.

Keşif fazı genellikle zaman ve malzeme ya da sabit ücretli keşif olarak kurgulanabilir.

Ana geliştirme fazı ise zaman ve malzeme veya hibrit model olabilir.

Kırmızı bayrak:

Tüm projeyi keşif yapmadan sabit fiyatla teklif eden tedarikçi.

Ya fiyatı yüksek güvenlik payıyla şişirmiştir ya da değişikliklerde ekstra fatura çıkaracaktır.

25. Sözleşmede fikri mülkiyet maddesi açık mı? Kod kime ait?

Beklenen cevap:

Tüm kod ve dokümantasyon, ödeme tamamlandıktan sonra size ait olmalıdır.

Kırmızı bayrak:

“Lisans modeli”, “kullanım hakkı” veya benzeri muğlak ifadeler.

26. Tedarikçinin kendi kütüphanesi veya çatısı kullanılıyorsa, buradan çıkmak mümkün mü?

Neden önemli?

Tedarikçi bağımlılığı en büyük gizli maliyetlerden biridir.

Şirket içi geliştirilmiş kapalı çatı yapıları size devredilemiyorsa, tedarikçiden ayrılmak imkânsız hale gelebilir.

Beklenen cevap:

Tüm yardımcı kütüphaneler ya MIT/Apache gibi açık lisanslı olmalı ya da sahipliği size geçmelidir.

27. Keşif ve tasarım fazından sonra projeden çekilebilir miyim? Faz kapısı var mı?

Beklenen cevap:

Her ana faz sonunda, örneğin keşif, MVP ve ölçekleme fazlarında devam ya da çıkış seçeneği olmalıdır.

Ceza olmadan çıkış hakkı net tanımlanmalıdır.

28. Sözleşmede ceza veya hizmet seviyesi ihlali maddeleri var mı?

Beklenen cevap:

Kilometre taşı gecikmeleri için indirim veya ceza maddeleri olmalıdır.

Kalite kapılarında işi reddetme hakkı tanımlanmalıdır.

29. Yedek dokümantasyon hangi sıklıkla güncelleniyor?

Beklenen cevap:

Mimari, yayına alma ve operasyon dokümantasyonu sürekli güncellenmelidir.

Confluence, Notion veya benzeri bir ortamda tutulabilir.

Her büyük değişiklikte güncelleme yapılmalıdır.

30. Proje bittikten sonra devir paketi ne içeriyor?

Beklenen cevap:

Tüm kodlar, depo erişimi, yayına alma yönergesi, mimari diyagram, 30 günlük destek ve bilgi transferi seansları.

İdeal olarak 2-4 bilgi transferi oturumu yapılmalıdır.

31. Ödeme takvimi nedir? Avans yüzdesi kaçtır?

Beklenen cevap:

Avans %20-30 aralığında olabilir.

Kalan ödeme kilometre taşlarına bağlanmalıdır.

Kırmızı bayrak:

%50 üzeri avans talebi.

Kategori 6: Referans, Alan Bilgisi ve Sürdürülebilirlik

32. Bu sektörde kaç canlı kullanım örneğiniz var?

Örneğin e-ticaret, fintech, sağlık, lojistik veya ERP gibi alanlarda en az 2-3 canlı kullanım örneği beklenir.

Ayrıca alana özel regülasyon bilgisi de önemlidir.

KVKK, BDDK ve KKK gibi gerekliliklerden haberdar olmaları gerekir.

33. Referans olarak verebileceğiniz en zorlu müşteri veya proje hangisiydi?

Neden önemli?

Tedarikçiler genellikle en mutlu müşterileri listeler.

“En zor müşteri” sorusu daha gerçek bir hikâyeye götürür.

34. Müşteri kaybettiniz mi? Neden?

Beklenen cevap:

Dürüst bir cevap.

Hiç müşteri kaybetmediğini söyleyen tedarikçi ya yeni bir firmadır ya da gerçekçi konuşmuyordur.

35. Kendi seçtiğim müşterilerinizle referans görüşmesi yapabilir miyim?

Neden önemli?

Tedarikçinin seçtiği referanslar genellikle özenle seçilmiştir.

Sizin seçeceğiniz müşterilerle yapılacak görüşmeler daha objektif olur.

Nasıl test edilir?

Müşteri listesini isteyin ve listeden 2-3 müşteriyi siz seçin.

36. Önceki müşterileriniz mevcut sistemleri nasıl yönetiyor? Sizin desteğinizle mi devam ediyorlar, kendileri mi yönetiyorlar?

Neden önemli?

İyi tedarikçi müşteriyi bağımlı bırakmaz.

Kötü tedarikçi sürekli destek gelirinden yaşar.

Beklenen cevap:

Karışık bir yapı olabilir.

Bazı müşteriler sistemi kendi yönetiyorsa devir başarılıdır.

Bazıları yönetilen hizmet modeliyle devam ediyorsa bu da tercih olabilir.

37. Bizim ekibimizden 2-3 mühendisi projeye gömülü şekilde dahil edebilir miyiz?

Neden önemli?

Gömülü ekip modeli bilgi transferini en hızlı yapan modellerden biridir.

Buna karşı çıkan tedarikçi genellikle fikri mülkiyet veya şeffaflık konusunda çekince yaşıyordur.

38. Tedarikçi şirketinin finansal stabilitesi nasıl? Son 3 yılda büyüdü mü, küçüldü mü?

Neden önemli?

Tedarikçi şirket proje ortasında küçülürse, ekibinizi kaybedebilirsiniz.

Beklenen cevap:

Şirketin yıllık %10-30 arası büyümesi, kârlılığının pozitif olması ve son 12 ayda toplu işten çıkarma yapmamış olması olumlu göstergelerdir.

Hızlı Karar Matrisi

Her tedarikçi için 38 soruyu cevaplatın.

Cevapları 4 seviyeli bir skorla puanlayın.

3 puan: Mükemmel

Spesifik, sayılarla desteklenen ve somut örnek içeren cevap.

2 puan: İyi

Genel ama mantıklı cevap. Yapabileceklerine dair makul sinyal var.

1 puan: Zayıf

Genel, klişe ve kanıtsız cevap.

0 puan: Kırmızı bayrak

Cevap kaçıyor, çelişiyor veya güven vermiyor.

Toplam skora göre değerlendirme

95 ve üzeri: Olağanüstü tedarikçi. Nadir bulunur.

75-94 arası: Güvenilir iş ortağı. Sözleşme aşamasına geçilebilir.

55-74 arası: Kabul edilebilir. Bazı kategorilerde yakın takip gerekir.

35-54 arası: Riskli. Yeniden değerlendirilmelidir.

35 altı: Bu tedarikçiyle çalışmayın.

Eğer Kategori 5, yani sözleşme ve fikri mülkiyet kategorisinin ortalaması 1.5’in altındaysa, toplam skor ne olursa olsun bu tedarikçiyle çalışmayın.

Sözleşme kötüyse, geri kalan her şey önemsiz hale gelir.

Süreçte Hata Yapmamak İçin 3 Ekstra Kural

Kural 1: Keşif fazını ayrı sözleşmeyle yapın

Keşif sonrası tüm projeye karar verin.

Tedarikçiyle keşif sonrası ayrılmak, ana sözleşme sonrası ayrılmaktan çok daha ucuzdur.

Kural 2: Kod deposu ve dokümantasyon size ait olmadan tek bir ödeme yapmayın

İlk günden okuma erişimi alın.

Kodun ve dokümantasyonun görünür olması gerekir.

Kural 3: Gömülü ekip isteğini reddedenle çalışmayın

İyi tedarikçi bilgi transferini sever.

Kötü tedarikçi kara kutu satar.

Sonraki Adım

Bu kontrol listesini kullanın ve tedarikçinize gönderin.

Cevap vermeyi reddederlerse zaten cevabınızı vermiş olurlar.

Tedarikçi seçimi sadece bir parçası.

Karar verdikten sonra projenin yatırım getirisini hesaplamak için “Özel Yazılım Yatırımı için ROI Hesaplama Çerçevesi” yazımıza bakabilirsiniz.

Önce özel yazılım mı SaaS mı kararını verecekseniz “Özel Yazılım mı Hazır SaaS mı? 9 Soruluk Karar Çerçevesi” yazımızı inceleyebilirsiniz.

Eğer halihazırda sorunlu bir projeyi kurtarmak istiyorsanız ya da tedarikçi değiştirmeyi düşünüyorsanız, Software Graveyard kurtarma sürecimiz için bizimle iletişime geçebilirsiniz.