Yazılım Şirketi Seçerken Dikkat Edilecek 10 Kriter (2026)

Yazılım şirketi seçerken fiyat ve portföyden önce beş sorunun cevabına bakın: Firma işinizi anlamak için nasıl bir keşif yapıyor, referanslarını doğrulayabiliyor musunuz, kaynak kodun ve fikri hakların sahibi kim olacak, güvenlik ve devir teslim nasıl yönetiliyor ve sözleşme modeli projenin belirsizlik düzeyine uyuyor mu? Aşağıdaki 10 kriter ve yazının sonundaki puanlama tablosu, kısa listenizi gerekçesi yazılı bir karara dönüştürmeniz için hazırlandı.

Firmalarla görüşmeden önce

Tedarikçileri karşılaştırmadan önce kendi tarafınızda üç konuyu netleştirmeniz, görüşmelerden alacağınız verimi belirgin biçimde artırır.

• Çözülecek iş problemi ve başarının nasıl ölçüleceği. “Yeni bir portal” yerine “bayi siparişlerinin telefonla alınmasına son vermek” gibi ölçülebilir bir hedef.
• Projenin iç sahibi. Kararları verecek, sorulara hızlı cevap verecek ve kabul testlerini onaylayacak bir kişi.
• Sabit kısıtlar. Bağlanılması gereken sistemler (ERP, CRM, muhasebe), KVKK kapsamındaki veriler ve iş açısından değiştirilemeyecek bir canlıya çıkış tarihi varsa o tarih.

1. Keşif kalitesi

İlk görüşmede soruları kimin sorduğuna bakın. İyi bir yazılım ekibi fiyat vermeden önce kullanıcılarınızı, mevcut iş akışınızı, verinizin nerede durduğunu ve hangi sistemlerle entegrasyon gerektiğini sorar. Görüşmenin sonunda anladıklarını ve açık kalan soruları yazılı olarak özetler. Riskli bir varsayım varsa, örneğin bir tedarikçi API’sinin ihtiyaç duyulan veriyi verip vermediği belli değilse, projenin tamamını teklif etmek yerine önce o varsayımı test eden küçük bir kavram kanıtı (PoC) önerir. İhtiyaç sorulmadan gelen kesin fiyatlı bir teklif hızlı görünebilir, ancak çoğu zaman belirsizliğin size devredildiği anlamına gelir.

2. Doğrulayabileceğiniz referanslar

Logo listesi referans değildir. Projenize benzeyen bir iş için mevcut bir müşteriyle görüşme talep edin ve şunları sorun: Proje planlanan kapsamda bitti mi, canlıdaki sistem hâlâ kullanılıyor mu, sorun çıktığında ekip nasıl davrandı, proje boyunca ekip değişti mi? Yayımlanmış vaka çalışmalarında müşterinin adının, problemin tanımının ve teslim edilen sistemin açıkça yazıp yazmadığını kontrol edin. Clutch veya Gartner Peer Insights gibi bağımsız platformlardaki yorumlar faydalı bir ek sinyaldir, ancak bir referans görüşmesinin yerini tutmaz.

3. Kaynak kod ve fikri hakların sahipliği

Sözleşme, ödeme yapıldıkça kaynak kodun, tasarımların, dokümantasyonun ve projede üretilen verinin size ait olacağını açıkça belirtmelidir. Türkiye’de Fikir ve Sanat Eserleri Kanunu’nun 52. maddesi, mali haklara dair sözleşmelerin yazılı olmasını ve konusu olan hakların ayrı ayrı gösterilmesini şart koşar (5846 sayılı Kanun, mevzuat.gov.tr). Bu nedenle “tüm haklar devredilir” gibi genel bir cümle yerine hakların tek tek sayıldığı bir madde isteyin ve hukuk danışmanınıza kontrol ettirin.

Pratik tarafta iki şey isteyin. Birincisi, kod deposunun ilk günden sizin kurumsal hesabınızda açılması. İkincisi, kullanılan açık kaynak ve üçüncü taraf bileşenlerin lisanslarıyla birlikte listelenmesi. Böylece proje yarıda kalsa bile elinizde çalışan bir kod tabanı olur.

4. Bilgi güvenliği ve ISO 27001

ISO/IEC 27001 sertifikası, firmanın bilgi güvenliğini denetlenen bir yönetim sistemiyle yürüttüğünü gösterir. Sertifikanın kendisini ve kapsam beyanını isteyin; kapsam, yazılım geliştirme yapan ve müşteri verisiyle çalışan ekipleri içermelidir. Bunun yanında şu soruları sorun:

• Ortamlarımıza erişim nasıl verilir, proje bitince nasıl geri alınır?
• Test ortamında gerçek kişisel veri kullanılıyor mu, kullanılıyorsa nasıl anonimleştiriliyor?
• Kod incelemesi ve bağımlılık güvenlik taraması nasıl yapılıyor?
• Bir güvenlik olayında bize ne zaman ve nasıl haber verilir?

Kişisel veri işlenecekse KVKK ve gerekiyorsa GDPR kapsamındaki rolleri ve sorumlulukları sözleşmeye bağlayın. Kendi kurumunuzun hazırlığını değerlendirmek isterseniz KVKK ve ISO 27001 uyum hizmetimizin kapsamına bakabilirsiniz.

5. Dokümantasyon ve devir teslim

Proje bittiğinde sistemi kendi ekibiniz veya başka bir firma işletebilmelidir. Teklifte devir teslimin neleri kapsadığını görün: mimari doküman, kurulum ve dağıtım hattı, işletim kılavuzları (runbook), yönetici hesaplarının ve gizli anahtarların devri, bilgi aktarım oturumları. Devir teslimi test etmenin basit bir yolu var: Kabul aşamasında kendi ekibinizden birinin yalnızca dokümana bakarak sistemi bir test ortamına sıfırdan kurmasını isteyin. Kurulum takılıyorsa eksik olan doküman değil, devir teslimin kendisidir.

6. Ekip sürekliliği

Satış görüşmesine gelenler ile projede çalışacak kişiler aynı olmayabilir. Teklifte teknik lider ve proje yöneticisi isimleriyle yer almalıdır. Bir ekip üyesi ayrılırsa yerine kimin geleceğini, bunun ne kadar önceden bildirileceğini ve bilgi aktarımının nasıl yapılacağını sorun. Bilginin kişilerin hafızasında değil, kod deposunda, iş takip aracında ve dokümanlarda tutulması sürekliliğin en somut güvencesidir.

7. Sözleşme modeli

Doğru model, işin ne kadar netleştiğine bağlıdır.

Kurumsal projelerin çoğunda keşfi ve PoC’yi ayrı bir iş olarak sözleşmeye bağlamak, yapımı ise fazlara bölmek riskleri iki taraf için de görünür kılar.

8. İletişim düzeni

Haftalık durum toplantısı, çalışan yazılımın düzenli aralıklarla gösterildiği demolar, tek bir iletişim sorumlusu ve kararların yazılı kaydı temel beklentilerdir. İş takip aracına ve test ortamına erişiminiz olmalı; ilerlemeyi bir sunumdan değil, çalışan yazılımdan görmelisiniz. Farklı ülkelerde çalışan bir ekiple anlaşacaksanız proje dilini ve çakışan çalışma saatlerini baştan konuşun.

9. Yerel mi, uzaktan mı?

Yazılım geliştirmenin büyük kısmı uzaktan yürütülebilir. Yerinde bulunmanın değer kattığı anlar ise genellikle bellidir: keşif atölyeleri, üretim hattında veya sahada süreç gözlemi, kullanıcı kabul testleri ve canlıya geçiş günü. Firmaya bu anların nasıl planlandığını sorun ve genel bir söz yerine yazılı bir plan isteyin. Örneğin ALGOFACT’in mühendislik ofisleri Adana ve Ankara TEKMER’dedir; diğer şehirlerdeki ekipler aynı teslim modeliyle hizmet alır ve yerinde çalışma ihtiyacı keşif görüşmesinde projeye göre planlanır. Ayrıntılar için hizmet verdiğimiz şehirler sayfasına bakabilirsiniz.

10. Uyarı işaretleri

Aşağıdakilerden biri tek başına eleme sebebi olmayabilir, ancak birkaçı bir araya geliyorsa dikkatli olun.

• İhtiyaç sorulmadan, ilk görüşmede kesin fiyat ve tarih verilmesi.
• Kaynak koda erişimin proje sonuna veya son ödemeye bırakılması.
• Referans görüşmesi talebinin geçiştirilmesi.
• Teklifte ekipte kimlerin çalışacağının belirtilmemesi.
• Test, dokümantasyon ve devir teslimin tekliften çıkarılması ya da “opsiyonel” bırakılması.
• Her soruya “evet, yaparız” denmesi ve hiçbir riskin dile getirilmemesi.

Puanlama tablosu

Kısa listedeki her firmayı aynı tabloyla değerlendirin. Ağırlıkları kendi önceliklerinize göre değiştirin; örneğin kişisel veri işleyen bir projede güvenlik, mevcut sistemlere bağlanan bir projede keşif kalitesi daha ağır basar.

Ağırlıkları “Yüksek” için 3, “Orta” için 2, “Düşük” için 1 gibi bir çarpanla sayıya çevirebilirsiniz. Toplam puan kararın kendisi değil, ekip içindeki tartışmayı düzenleyen bir araçtır. İki firma birbirine yakın puan alıyorsa farkı genellikle referans görüşmeleri ortaya çıkarır.

Seçim sürecini nasıl yürütmeli

• Kısa listeyi üç veya dört firmayla sınırlayın; daha uzun bir liste karşılaştırmayı yüzeysel hale getirir.
• Her firmaya aynı problem tanımını ve aynı soru listesini gönderin.
• Teklifleri fiyat satırından önce kapsam, varsayımlar ve riskler açısından okuyun.
• Son iki firmayla referans görüşmesi yapın.
• Belirsizlik yüksekse sözleşmeyi keşif ve PoC ile başlatın, yapım fazına bunun sonuçlarına göre karar verin.

Sonraki adım

ALGOFACT, çözüm mühendisliği projelerine 30 dakikalık bir keşif görüşmesiyle başlar; ardından kurucu ekip önerilen kapsamı sunar. Bu yazıdaki kriterleri bizi değerlendirirken de kullanabilirsiniz: Sorularınızı getirin ve keşif görüşmesi planlayın.