Şanlıurfa Yazılım Firması Nasıl Seçilir? 7 Kriterli Pratik Rehber

Şanlıurfa'da yazılım firması seçmek, görünüşte sade ama pratiğe geçince çok katmanlı bir karar. Sade görünüyor çünkü pazarda 20-30 firma var; çok katmanlı çünkü bu firmaların yarısı freelance grup, üçte biri yalnızca web tasarım yapıyor, kalan üçte birinin de sertifika ve referans yapısı birbirinden çok farklı. Karaköprü ofisimizdeki ekibimizin son 14 yılda gözlemlediği şu: yanlış firma seçiminin maliyeti, "biraz fazla ödeme" değil — projenin 6-12 ay geri kalması ve sıfırdan yeniden yazılması.

Bu yazıda kurumsal alıcının bakması gereken 7 kriteri sırayla ele alacağız. Her kriter için neyi sormanız gerektiğini, hangi cevabı arıyor olmanız gerektiğini ve bizim kendi projelerimizden ne öğrendiğimizi anlatacağız.

1. Aynı çekirdek ekibin sürekliliği

Kurumsal yazılım projesinde en pahalı kayıp para değil, kurumsal hafızadır. Bir firma size bugün gösterdiği üç başarılı referansı, son üç yılda aynı çekirdek ekip ile mi yaptı, yoksa proje ortasında ekip yeniden mi kuruldu — bu sorunun cevabı, sizin önümüzdeki 18 ayda ne yaşayacağınızın en güvenilir göstergesidir.

Firma değerlendirme görüşmesinde şu üç soruyu mutlaka sorun:

• "Bu sunumda gördüğüm mimar, benim projemin sonuna kadar projede kalacak mı?"
• "Geçen yıl ekipten ayrılan mühendis sayısı nedir?"
• "Mevcut ekip ortalama firmada kaç yıldır çalışıyor?"

Eğer cevap belirsizse ya da firma "biz portföyümüzdeki en uygun kişiyi atarız" gibi genel bir cümle kullanıyorsa, dikkatli olun. Outsource-ağırlıklı modellerde ekip kayboldukça bilgi de kayboluyor; siz her sprint başlangıcında projeyi yeniden anlatmak zorunda kalıyorsunuz.

Biz kendi mühendislik ekibimizi bu sebeple kalıcı çekirdek + dış uzman modeliyle yapılandırdık. 17 kişilik çekirdek ekibimizin yarısı 5+ yıldır eCloud Tech'te; bu süreklilik sayesinde 2019'da başlattığımız BiCRM'in kararlarını bugün hâlâ savunabiliyor ve gerekçelendirebiliyoruz.

2. Kod tabanı sahipliği ve repo erişimi

Sözleşmenizdeki en önemli üç sayfa, fiyat sayfası değil, fikri mülkiyet ve kod sahipliği sayfasıdır. Çoğu kurumsal alıcı bu kısma yeterince zaman ayırmaz; iki yıl sonra firma değiştirmek istediğinde kodun yarısının kendisine ait olmadığını fark eder.

Sözleşmeye dahil etmeniz gereken üç maddeyi paylaşalım:

1. Tam mülkiyet devri — geliştirilen kodun tüm fikri hakları teslim sonrası size geçer. "Lisans verir" değil, "mülkiyetini devreder" ifadesi kullanılmalıdır.
2. Git repository'sine ortak erişim — proje başladığı andan itibaren sizin teknik temsilcinizin repository'yi (GitHub, GitLab veya self-hosted) okuma izni olmalıdır. Sadece tamamlanmış sürümlerin teslim edilmesi yetmez; süreç şeffaf olmalıdır.
3. Üçüncü parti bağımlılıkların açık listesi — kullanılan tüm kütüphaneler, lisansları ve maliyet bilgisi (GPL, MIT, ticari) yazılı olmalıdır. AGPL gibi bulaşıcı lisansların sızması sonradan ciddi sorun yaratır.

Eğer firma "kod bizim AR-GE ürünümüzdür, kaynağı paylaşmıyoruz, hizmet alıyorsunuz" diyorsa — bu vendor lock-in klasiğidir. Bu modelin ticari mantığı vardır (firma için), ancak kurumsal alıcı için stratejik bir risk oluşturur. Kararı bilinçli vermeniz gerekir.

3. KVKK uyumu — mimari mi yoksa son katman mı?

Şanlıurfa'da görüştüğünüz hemen her firma "KVKK uyumlu hizmet veriyoruz" cümlesini söyleyecektir. Cümle doğru ama yetersiz. Asıl ayrım, KVKK uyumunu projenin tasarım aşamasında karar olarak benimseyen firmalarla, son katmana eklenti olarak ekleyenler arasındadır.

Firmanın hangi yaklaşımı uyguladığını anlamak için üç soru yeterlidir:

Veri lokasyonu nerede? Kullanıcı verileri Türkiye sınırları içinde mi işleniyor? Eğer "AWS Ireland kullanıyoruz" cevabı geldiyse, KVKK m.9 yurt dışı veri aktarımı şartlarını sağlıyor musunuz? Türkiye'de işlemek için ek mimari maliyet ne olur?

Anonimleştirme süreci nasıl tanımlı? Test ortamlarında gerçek kullanıcı verisi mi kullanıyorsunuz, yoksa otomatik anonimleştirilmiş veri seti mi? Geliştirici makinelerinde production veri çekiliyor mu?

Denetim logu hangi olayları kapsıyor? Hangi rol hangi veriye eriştiğinde log alınıyor? Bu loglar ne kadar süreyle saklanıyor? KVKK Kurumu denetimi gelirse log dökümünü ne kadar sürede üretebilirsiniz?

Üç sorunun da tatmin edici cevabı yoksa — firma KVKK'yı bir formalite olarak görüyor demektir. Bu önemli çünkü kanun değişiklikleri ya da denetim talebi geldiğinde, eklenti olarak yapılmış uyum çabucak yıkılır.

Kurumsal yazılım hizmetlerimizde KVKK uyumunu gün bir mimari olarak ele alırız: veri akış diyagramı çıkarmadan kod yazmıyoruz, üretim verisi geliştirici ortamına asla inmiyor, denetim logu standart bir modül olarak her projede mevcut.

4. Bakım sözleşmesi (SLA) — somut maddeler

"7/24 destek sunuyoruz" cümlesi, sözleşme metninde ne anlama geliyor? Çoğu zaman, hiçbir şey. Gerçek bir bakım SLA'sı, aşağıdaki maddelerin her birine sayı vermelidir:

Bu tablonun her satırına "duruma göre değişir" cevabı veren firma, ya henüz bu kararları vermemiştir ya da net bir bakım organizasyonu yoktur. İkisi de risk göstergesidir.

5. Üç referans ve bir başarısız proje sorusu

Başarılı referans göstermek kolay; her firma kataloğunda en parlak üç müşteriyi tutar. Bir firmanın gerçek olgunluğu, kötü gittiği projeleri nasıl anlattığında anlaşılır. Görüşmenizin sonunda şu soruyu sorun:

"Son üç yılda istediğiniz sonucu alamadığınız bir projeniz oldu mu? Ne yanlış gitti, sonradan neyi değiştirdiniz?"

Cevap kategorilerinin pratik analizi:

• "Hayır, tüm projelerimiz başarılı." — Kırmızı bayrak. Yazılım mühendisliğinde her firmanın başarısız projeleri vardır; iddianın aksi mümkün değildir. Bu cevap ya firmanın az sayıda proje yapmış olduğunu ya da öz-eleştiriye kapalı olduğunu gösterir.
• "Şu müşteri ile sorun yaşadık, ama suç onların." — Sarı bayrak. Tek taraflı suçlama yetersiz iç gözlem demektir. Sonradan ne öğrendiğini söyleyemiyorsa, aynı hata tekrar olabilir.
• "X projesinde mimari kararı geç verdik, Y modülünü iki kez yeniden yazmak zorunda kaldık. Sonradan sprint 1'den önce mimari kararları tamamlama kuralı koyduk." — Yeşil bayrak. Spesifik vaka + spesifik öğrenme + spesifik proses değişikliği. Bu firma kurumsal hafızasını iyi yönetiyor.

Eski projelerine geri dönmek, hatalarını ortaya koymak ve süreç düzeltmesini anlatabilmek; bir mühendislik firmasının olgunluğunun en güçlü göstergelerinden biridir.

Referans görüşmesinde ek olarak şu üç noktaya dikkat edin. Birincisi: müşterinin proje sonrası bakım süreçlerinden memnun olup olmadığı. Proje teslim zamanında parlak görünür; iki yıl sonraki memnuniyet farklı bir konudur. İkincisi: planlama-tahmin uyumu — firma "8 hafta" dediğinde gerçekten 8 haftada bitirdi mi, yoksa 14'e mi sarktı? Üçüncüsü: müşterinin firmaya yeniden iş verip vermediği. Tekrar iş veren müşteri en güçlü kalite sinyalidir; aynı firma ile beş yıl içinde üç farklı proje yapan kurumlar, o firmaya gerçekten güveniyor demektir. Bu son nokta tek bir görüşmede ortaya çıkmaz; firma bu bilgiyi gönüllü paylaşmıyorsa siz spesifik olarak sorun.

6. Teknik uyum — kullandığı stack sizinki ile konuşabilir mi?

Firmanın kullandığı teknoloji yığını (programlama dilleri, framework'ler, veritabanı, bulut sağlayıcı), sizin mevcut altyapınız ile uyumlu mu? Bu sadece bir tercih meselesi değil, ileride entegrasyon maliyetini belirleyen bir karardır.

İki senaryoya bakalım:

Senaryo A. Mevcut altyapınız .NET / SQL Server / Azure üzerinde. Görüştüğünüz firma yalnızca PHP / MySQL / shared hosting deneyimine sahip. Yeni projeyi hangi stack'te yapacak? Eğer kendi rahat olduğu stack'i (PHP) önerirse, sonradan kurumsal entegrasyonda iki sistem arası API katmanı yazmak zorunda kalırsınız. Eğer "biz .NET de yaparız" derse, ekibin .NET deneyimini referans projelerle test etmeniz gerekir.

Senaryo B. Mevcut altyapınız mütevazi (örn. WordPress + birkaç Google Workspace aboneliği). Firma size enterprise-grade Kubernetes mimarisi öneriyor. Bu mimarinin bakım maliyeti, sizin mevcut iç teknik kapasitenizi aşıyor olabilir. Görkemli mimari, yanlış müşteri için yanlış karardır.

Doğru firma, ekibinin yetkin olduğu stack'i göstermek yerine sizin uzun vadeli bakım kapasitenize uygun stack'i önerir. Bu öneri için size birkaç sorudan oluşan kısa bir teknik değerlendirme yapması, kötü firma ile iyi firma arasındaki ilk somut farktır.

Bir başka pratik test: firmaya "Bu projede beş yıl sonra kullanılan kütüphanelerin desteği kalmazsa ne yaparsınız?" sorusunu sorun. Verilecek cevap firmanın mühendislik olgunluğunu net gösterir. "Güncel kütüphane çıkınca taşırız" cevabı yetersizdir; iyi cevap, framework seçiminde uzun vadeli destek planını (LTS sürümleri, topluluk büyüklüğü, sponsor şirket) baştan değerlendirdiğini gösterir. React, .NET, Node.js LTS gibi olgun ekosistemler tercih ediliyorsa firma sürdürülebilirliği önemsiyor demektir; aksine yeni çıkmış bir framework'ü "trend" diye seçen firma, sizi 2-3 yıl sonra migration borcu altında bırakır.

Bu noktada bizim kendi yaklaşımımız hakkında — biz iki sorunun cevabını isteriz: "Mevcut yazılım altyapınızda hangi sistemler var?" ve "Bu sistemlerin iç bakımını kim yapıyor?" Cevaplar bize stack önerisini değil, mimari yaklaşım önerimizi şekillendirir. Mevcut altyapıda Microsoft ekosistemi yoğunsa .NET; veri yoğun analitik varsa Python; hızlı API katmanları için Node.js öneririz. Stack seçimi ideolojik değil, somut entegrasyon maliyeti hesabı sonucudur.

7. Mühendis-saat şeffaflığı ve fiyatlama mantığı

Yazılım projelerinin en sıkıntılı bölümü fiyatlandırmadır çünkü ürünü değil süreyi satıyorsunuz. Sabit fiyat ile saatlik faturalama arasındaki seçim, projenin niteliğine bağlıdır:

Sabit fiyat uygundur:

• Scope net belirlenmiş, gereksinimleri donmuş projeler
• PoC (Proof of Concept) ya da MVP (Minimum Viable Product)
• Küçük entegrasyon işleri (örn. mevcut bir API'ya bir modül eklemek)
• Projenin süresi 8 haftadan kısa

Saatlik / sprint bazlı uygundur:

• Gereksinimler evrime açık (çoğu kurumsal proje)
• Süresi 3+ ay
• Müşterinin teknik kararlara dahil olmak istediği projeler
• Üretim sonrası bakım dönemi

Sabit fiyat dayatan ama scope'u açık tutan firma riskinizi büyütür: değişiklik talebi geldiğinde firma direnç gösterir; başlangıç fiyatına dahil sandığınız özellikler "ek geliştirme" olarak faturalanır. Saatlik modelde ise firma kontrolsüz çalışıyorsa süre uzar, fatura şişer.

Sağlıklı bir fiyat görüşmesinde firma sizinle şu kalemleri paylaşmalı:

1. Mühendis-saat tahmini ve dağılımı (örn. 200 saat backend, 80 saat frontend, 40 saat DevOps).
2. Sprint yapısı — kaç haftalık sprint, demo + retro toplantıları nasıl.
3. Değişiklik talep süreci (CR — Change Request) — yeni özellik talebi geldiğinde nasıl fiyatlanır.
4. Bakım sonrası fiyatlandırma — proje teslim olduktan sonra aylık bakım hangi modelde devam eder.

Bu dört kalemde sizinle açık konuşmayan firma sürpriz faturayla karşı karşıya bırakabilir.

Karar matrisi

Yedi kriterin tümünü tek tabloda toparlamak için:

Yedi kriterin tamamına yeşil cevap veren firma nadirdir; en az beş kriterde yeşil + iki kriterde sarı bayrak olan firmayı tercih etmeniz, geçmiş projelerimize bakarak önerebileceğimiz pratik bir kuraldır.

Şanlıurfa ekosistemi notu

Şanlıurfa'nın yazılım ekosistemi, 2019-2026 arası ciddi olgunlaştı. Şanlıurfa Teknokent kayıtlı firma sayısı arttı, üniversite-sanayi işbirliği güçlendi, AR-GE indirimi alan firma profili çeşitlendi. Bununla birlikte ekosistemin asıl yapısal zayıflığı — uzun vadeli kurumsal projelere taahhüt — hâlâ orta firmalar için bir gelişim alanı. Burada büyük firmaların avantajı sertifika değil, ekip sürekliliği ve mali sağlamlıktır.

Bizim kurumsal CRM platformumuz BiCRM'i yedi yıldır aynı çekirdek ekiple geliştirmemiz, bu yapısal zorluğa karşı somut bir cevaptır. Müşterilerimiz iki yıl sonra dönüp aynı mühendisle konuşabiliyor — bu, kurumsal yazılım dünyasında nadir ama belirleyici bir özellik.

Karar günü

Yazılım firması seçimi, "en iyi firmayı bulmak" değil kendi kuruma en uygun firmayı bulmak sürecidir. Şanlıurfa'da yedi kriterin tamamını birinci dereceden karşılayan bir avuç firma vardır; ikinci dereceden karşılayan onlarca firma vardır. Sizin için kritik olan, yedi kriteri kendi proje özelliklerinize göre ağırlıklandırmak: küçük bir PoC için fiyatlama şeffaflığı ile teknik uyum ön plana çıkar; büyük bir kurumsal projede ise ekip sürekliliği ile SLA önceliklidir.

Kendi projeniz için bu yedi kriteri değerlendirmeye başladıysanız, görüşmeden önce yukarıdaki "soracağınız soruları" küçük bir not kâğıdına yazmanızı öneririz. Firma görüşmesinde cevapları tek tek not alın; üç firma görüşmesinden sonra cevapları karşılaştırınca tablo netleşir. Eğer süreç sırasında ikinci bir görüş istiyorsanız, ekibimizle iletişime geçin — ücretsiz ön değerlendirme görüşmesinde yedi kriterin sizin senaryonuza göre nasıl uygulandığını anlatırız.