Custom yazılım partneri seçerken 5 kırmızı bayrak

Önümüzdeki çeyrekte custom yazılım partneri seçecekseniz bu yazı, ilk üç görüşmeden sonra hangi soruları sormanız gerektiğini netleştirir. Custom yazılım partnerliği orta ölçekli bir B2B şirket için yıllık en pahalı üç sözleşmeden biri olur. Engagement süresi tipik olarak 6-12 ay, harcanan tutar 500.000 TL ile birkaç milyon TL arasında değişiyor; üstelik karar geri dönüşü kolay olmuyor — partner değiştirmek demek ya yarım kalmış kod tabanını başka bir ekibe devretmek ya da scope’u sıfırlamak demek. İlk seçimde fark edilebilecek beş kırmızı bayrak, sonraki 12 ayda çok büyük yük olarak geri dönüyor.

Son üç yılda hem bizimle çalışmaya gelen müşterilerin önceki partner deneyimleri hem de RFP süreçlerinde yarıştığımız ekiplerin hâli üzerinden gözlemledik: bayraklar tekrar ediyor. Bu yazı, müşteri olarak bir partner değerlendirirken görüşme tahtasında veya teklif metninde fark edebileceğiniz beş kırmızı bayrağı, sonrasında dengeleyici beş yeşil bayrağı paylaşıyor. Amaç, herhangi bir partneri “ihale dışı bırakacak” katı bir kontrol listesi vermek değil; ilk üç görüşmeden sonra hangi soruları sormanız gerektiğini netleştirmek. Listeyi bizimle çalışırken müşterilerimize de açıkça paylaşıyoruz — kendi pratiğimizi denetletmek için.

Kırmızı bayrak 1: “Her şeyi yaparız” — uzmanlık alanı belirsiz

İlk telefon görüşmesinde “biz B2B SaaS, e-ticaret, mobil uygulama, blockchain, AI, IoT ve ERP entegrasyonları yapıyoruz” cümlesi geçtiyse durup düşünün. Beş kişilik bir ekip için bu profil mümkün değil; 50 kişilik bir ekip için “yapıyoruz” demek “bir kere yaptık, bir daha yapabiliriz” anlamına geliyor olabilir.

Custom yazılım, dikey uzmanlığın katlanarak değer ürettiği alandır. Bir ekip son 18 ayda üç farklı B2B SaaS’te tenant isolation üzerinde çalışmışsa, sizinki için seçenekleri 30 dakikada konuşur. Aynı ekip ilk kez bir multi-tenant probleme bakıyorsa, üç hafta dokümantasyon okumakla geçecek; üstelik faturayı siz ödeyeceksiniz.

Bir partnerin uzmanlık alanını kontrol etmenin pratik üç yolu:

• Son 6 vakanın anonimleştirilmiş özetini sorun. Sektör dağılımı tek bir kümeye toplanıyor mu yoksa her vakada farklı bir teknoloji yığını mı çıkıyor? Tek küme = derinlik var. Dağınık = “her şeyi yaparız” deklarasyonu sözdeydi.
• Teknik referanslarına teknik bir soru sorun. Örneğin “Postgres’te 2.000 tenant’lı bir RLS kurulumunda connection pooling stratejiniz ne olur?” Cevap belirgin bir paterne dayanmıyorsa, daha önce bu probleme bakmamış demektir.
• Tekrarlanan kelimeleri sayın. Kendi alanını anlatırken kullandığı 5-6 spesifik kavram (örn. “dual-write”, “shadow read”, “outbox pattern”) varsa konfor zonu var demek.

Scope çekme riski, “her şeyi yaparız” diyen ekiplerde sistemli olarak yüksek. Sözleşmeyi imzalarsınız, üç ay sonra tasarım gözden geçirme aşamasında “biz bu kısmı yapmıyoruz, dışarıdan bir freelancer alalım mı?” cümlesi geliyor — fatura sizin tarafınızda büyüyor.

Kırmızı bayrak 2: Tek-müşteri portfolio ya da hep aynı sektör

Tersine, ikinci kırmızı bayrak da var: portföyünün %80’i tek bir müşteriden ya da tek bir sektörden geliyorsa. İlk bakışta “uzmanlaşma” gibi görünür, gerçekte bağımlılık ve dış-perspektif yokluğu yaratıyor.

Tek-müşteri partner şirketleri tipik olarak iki riskten birine giriyor: ya o büyük müşteri çıktığında likidite krizine düşüyor ve sizin projeyi bekleme listesine alıyor, ya da o müşterinin teknolojik tercihleri (sevdikleri framework, sevdikleri cloud sağlayıcı, kendi mimari kalıpları) sizin projenize de aynen kopyalanıyor. İkisi de sizin için kötü.

Tek-sektör partneri ise farklı bir risk: dış-perspektif yok. B2B SaaS dünyasında çalışan bir ekip, e-ticaret dünyasının “checkout abandonment” problemlerine bakarken körleşiyor. Sektörler arası örüntülerden gelen yaratıcı çözümleri kaçırıyor. Kendi sektörünüzde derinleşmiş ama 1-2 dış sektörle de çalışmış bir ekip, çoğu zaman daha sağlam çözüm öneriyor.

Kontrol formülü: portföyün %50’sinden fazlası tek müşteriden mi geliyor? %70’inden fazlası tek sektörden mi? İkisinden birinde “evet” çıkıyorsa konuşmayı detaylandırın. Çoğu zaman çıkış stratejisi (tek müşteri konsantrasyonunu azaltma planı) sorulduğunda pek çok partner sessiz kalıyor. Bu sessizlik kendi başına bir sinyal.

Kırmızı bayrak 3: Pricing ya çok şeffaf değil ya çok hızlı verilen

Üçüncü kırmızı bayrak, fiyatlandırma sürecinin kendisi. İki uç var, ikisi de zararlı.

Çok şeffaf değil. İlk üç görüşme bitiyor, kapsam üzerinde mutabakat var, ama “fiyat bir-iki hafta sonra netleşir” cümlesi tekrar ediyor. İçeride kapsam mapping yapılmıyor; muhtemelen ekip hiyerarşisi onayını bekliyorlar ya da rakibinizin teklifini görmek için zaman kazanıyorlar. Sonuç: yarı-pazarlık sürecinde bilginin asimetrisi onların elinde kalıyor.

Çok hızlı verilen. Daha kötüsü: ilk 30 dakikalık görüşmenin sonunda “engagement 600.000 TL, 16 hafta” denmesi. Bu, kapsam mapping yapılmadan teklif verildiği anlamına geliyor — yani ya partner sizden ek scope çıkacağını biliyor ve “değişiklik talebi” ile büyütmeyi planlıyor, ya da bütçeyi görmeden body-shop fiyat veriyor.

Sağlıklı bir fiyatlandırma süreci tipik olarak iki hafta alıyor:

• 1. hafta: Discovery (1-2 görüşme), kapsam taslağı, soruların yazıya dökülmesi.
• 2. hafta: Yapı önerisi (mimari brief, milestone breakdown), tahminler, fiyat aralığı.

Aralık fiyat (örn. “11-14 hafta, 450-580k TL”) tek-nokta fiyattan daha sağlıklıdır, çünkü partner içeride risk faktörlerini ayrıştırmış demektir. Tek-nokta fiyat veriliyorsa, sözleşme değişiklik talebi (change request) maddesi nasıl yazıyor diye bakın. Çok serbest bir CR maddesi varsa, asıl fiyatlandırma sözleşmenin sonunda yapılacak demektir.

B2B partnership checklist’imizdeki 12 maddelik kontrol listesinin dördü tamamen fiyatlandırma sürecine ayrılmış; ihale öncesi indirebilirsiniz.

Kırmızı bayrak 4: Code ownership ve IP madde belirsizliği

Dördüncü ve en pahalı kırmızı bayrak, kod sahipliği ve fikri mülkiyet (IP) maddesinin belirsizliği. Bunun en sık karşılaştığımız hâli, sözleşmede “iş tamamlandığında müşteri kullanım hakkı kazanır” cümlesinin geçmesi. Kullanım hakkı sahiplik değil. Partner değiştirmek, kodu fork etmek ya da ürünü başka bir piyasada satmak ihtiyacı oluştuğunda, sahipsizlik aniden çok pahalı.

Sözleşmede her zaman aramanız gereken üç ifade:

• “Work-for-hire” ya da “iş eseri” maddesi. Üretilen tüm kod, dokümantasyon, mimari diyagram, test paketi ve infra konfigürasyonu teslim alındığı anda müşteriye geçer. Bu açıkça yazılmalı; “kullanım hakkı” yetmiyor.
• Üçüncü taraf bağımlılıkları. Partnerin kendi açık kaynak ya da iç kütüphaneleri kullanılıyorsa hangi lisans altında? GPL gibi viral bir lisans gözden kaçarsa sizi sonra bağlar. MIT/Apache 2.0 ve benzeri permissif lisanslar tercih edilmeli; özel lisanslı kütüphaneler için müşteriye sürekli kullanım garantisi sözleşmede yazmalı.
• Hesap ve credential erişimi. Cloud hesabı, repo, CI/CD ortamı, secrets manager kimin adına? Engagement boyunca partnere yetki verilebilir, ama sahiplik baştan müşteride olmalı. Pek çok kötü vaka, partnerin AWS hesabını “müşterimiz adına” kurması ile başlıyor; ayrılırken hesap geçişi ay alıyor.

IP madde belirsiz görünüyorsa, görüşmede şu soruyu sorun: “Bu engagement’tan ayrılırsak, kodu başka bir ekibin devralması ne sürer?” Cevap “iki hafta dokümantasyon devri ve hesap transferi” dışında bir şeyse, kilit (lock-in) düşünülmüş demektir.

Kırmızı bayrak 5: Hand-off planı yok — ya teslim et çekil ya kilit-içinde tut

Beşinci kırmızı bayrak, engagement sonrasının düşünülmemiş olması. İki uçta da çıkıyor.

Teslim et çekil deseni. Code drop, GitHub erişimi devri, “iyi şanslar”. 12 hafta sonra ilk büyük üretim hatası geldiğinde ekibinizin kodu tanımıyor; partner ise yeni bir engagement’a geçtiği için 3 hafta beklemeniz gerekiyor. Operasyonel risk sizin tarafınıza bırakıldı.

Kilit-içinde tut deseni. Tersine: partner “biz olmadan bu sistem yürümez” konumunu yıllık retainer olarak çevirmeye çalışıyor. Dokümantasyon eksik, deployment script’leri tek bir kişinin laptop’unda, secrets rotation süreci yazılı değil. Ayrılmak istediğinizde “biz olmadan 3 ay kilit alır” cevabı geliyor. Bu, kötü mühendislik kültürünün ya da kasıtlı bir lock-in stratejisinin sonucu — ikisi de kabul edilemez.

Sağlıklı hand-off planının dört bileşeni:

• Bridge süresi: Engagement bitiminden sonra 4-8 haftalık geçiş dönemi. Partner haftada belirli saat bug fix ve soru cevaplama için kalıyor; süreyi sözleşmede sabit tutuyor.
• Operasyonel runbook: Deployment, rollback, on-call rotation, secrets rotation, monitoring threshold ayarlama gibi her tekrarlayan işin yazılı dokümantasyonu.
• İçeride bilgi transferi seansları: Engagement’ın son 4 haftasında haftada 2 saat bilgi transferi (mimari, kararlar, debug yöntemleri). Kayıt altında.
• Kontrol noktası: Bridge süresi bittiğinde, partner gitse bile sistemin çalıştığından emin olmak için bir test seansı. Genellikle partner olmadan production deployment yapmayı deneyerek doğrulanıyor.

Bu dört bileşen ihale aşamasında “evet, böyle yaparız” diye söyleniyorsa kontrol edin: önceki engagement’larından bir referansa “siz ayrıldıktan sonra ne oldu” sorusunu yöneltin. Cevap “üç ay sonra hâlâ ayda 5 saat danışmanlık alıyoruz” ile “ayrıldıktan altı ay sonra hiç ihtiyaç duymadık” arasında çok şey anlatıyor.

Yeşil bayraklar — beş tane

Beş kırmızı bayrağı dengelemek için beş yeşil bayrak da listeleyelim. Bunlar kesin garanti vermiyor ama birkaç tanesi bir araya geldiğinde partner adayı ciddiye alınmaya değer demek.

• NDA hızı. Talep edildikten sonra 24-48 saat içinde imzalı NDA dönüyor. Partnerin operasyonel disiplinini gösteren ilk işaret.
• Sektör çeşitliliği. Portföy ana bir derinlik (ör. B2B SaaS) etrafında ama 1-2 farklı sektörle de çalışmış. Dış-perspektif var.
• Açık fiyatlandırma metodu. Aralık fiyat veriyor, milestone breakdown gösteriyor, change request maddesi standart endüstri pratiği. Pricing konuşması bilgi asimetrisi yaratmıyor.
• IP transfer şartı. Sözleşme örneğinde “work-for-hire” maddesi açıkça yazılı. Hesap sahipliği baştan müşteride. Üçüncü taraf bağımlılıkları için lisans listesi sunuluyor.
• Bridge süresi planı. Engagement teklifinin içinde ya da yan dokümanında “post-engagement bridge: 6 hafta, haftada 8 saat” gibi açık bir plan var. Sonrasını düşünmüş.

Bu beş yeşil bayrağın hepsinin aynı partnerde çıkması nadir; üç-dördü çıkıyorsa engagement’a girmek savunulabilir bir karar. Hiçbiri çıkmıyorsa, listemizdeki strateji ve içgörü hizmetinde yaptığımız partner due diligence çalışmalarına benzer bir denetim yapmadan ilerlemeyin.

Sonuç: kırmızı bayrak gördüğünüzde ne yapmalı

Tek bir kırmızı bayrak engagement’ı bozmaz. İki bayrak görüşme sayısını arttırmanız için yeterli sinyal. Üç ya da daha fazla bayrak: partner değiştirin. Custom yazılımda 6-12 aylık angajmana girip 4. ayda partneri değiştirmek, hem zaman hem para hem moral açısından çok pahalı; ön kontrolün maliyeti her zaman daha düşük.

Pratik öneri: ihale aşamasında en az üç partneri yan yana koyun, beş kırmızı + beş yeşil bayrak listesini her biri için doldurun, sonra teknik referanslarını arayın. Çoğu zaman 30 dakikalık bir referans araması, üç haftalık bir teklif sürecinden daha çok bilgi veriyor. Bu kontrolü kendi başınıza yapamayacağınızı düşünüyorsanız ya da iki finalist arasında bağımsız bir görüş istiyorsanız, bize ulaşın — tipik olarak 2-3 saatlik bir partnership review oturumunda finaliste karar veriyoruz.