Kurumsal Yazılım Geliştirme Şirketi Seçerken Sormanız Gereken 12 Soru (2026 Rehberi)

Bir yazılım projesini 8 ay sonra yeniden yaptırmak zorunda bırakan karar, çoğu zaman projenin ilk iki haftasında verilir: yanlış yazılım firmasını seçmek.

Geçen yıl, yarım kalmış ya da yeniden geliştirilmesi istenen 17 projeyi inceledik. Bunların 13’ünde sorunun aslında teknolojiden değil, başlangıçta doğru ekibin seçilmemesinden kaynaklandığını gördük.

Çoğu proje baştan yazılmak zorunda değildi. Doğru ekip, doğru kapsam ve doğru çalışma modeliyle 8–12 haftalık bir toparlama süreci yeterli olabilirdi.

Aradaki fark teknik yeterlilikten çok, alıcının firma seçim sürecinde doğru soruları sormamış olmasıydı.

Bu rehber; CTO, CIO, IT direktörü, satın alma ekibi ya da dijital dönüşümden sorumlu yöneticiler için hazırlanmış 12 kritik değerlendirme sorusundan oluşuyor. Teklif sürecine başlamadan önce ayıracağınız 30 dakika, aylarca sürecek zaman kaybını ve ciddi bütçe aşımlarını önleyebilir.

Neden Bu Karar Bu Kadar Kritik?

Kurumsal yazılım projeleri genellikle bir anda başarısız olmaz. Süreç çoğu zaman sessizce bozulur:

İlk 1–3 ay:

İhtiyaç analizi uzar, kapsam netleşmez.

4–8. aylar:

Ekip değişir, projeyi başlatan deneyimli kişiler başka işlere kayar.

9–12. aylar:

Bütçe %40–60 aşılır, teslim tarihi ertelenir.

13. ay ve sonrası:

Proje ya durdurulur ya da “baştan mı yazsak?” sorusu gündeme gelir.

Bu sorunların büyük bölümü, yazılım firması seçilirken yapılan yanlış varsayımlardan kaynaklanır.

Çünkü doğru sorular en başta sorulmamıştır.

Teklif Sürecinden Önce Kendinize Sormanız Gereken Sorular

1. Bu projenin gerçek amacı ne?

“Yeni bir CRM istiyoruz” iyi bir cevap değildir.

Daha doğru bir cevap şöyle olmalıdır:

> “X ay içinde Y metriğini %Z iyileştirmek için, mevcut sürecimizi yeniden tasarlamak istiyoruz.”

Örneğin:

> “Satış ekibinin teklif hazırlama süresini 6 ay içinde %40 azaltmak için, müşteri talebi, fiyatlandırma ve onay süreçlerini tek bir sistemde toplamak istiyoruz.”

Eğer kendi cevabınızı bu netlikte yazamıyorsanız, ne kadar iyi bir yazılım firması seçerseniz seçin proje yön kaybedebilir.

Çünkü firma yazılımı geliştirebilir; ama iş hedefi net değilse doğru ürünü geliştiremez.

2. Bu proje için gerçek bütçeniz ne?

Onaylı bütçe ile “rahat ettiğiniz” bütçe çoğu zaman aynı değildir.

Teklif sürecinde gerçek bütçe aralığını paylaşmak, doğru ölçekteki firmalarla görüşmenizi sağlar.

Örnek bütçe aralıkları:

MVP / yeni ürün geliştirme:

40.000 – 150.000 USD

Türkiye merkezli deneyimli bir proje ekibi için gerçekçi aralık.

Orta ölçekli kurumsal yazılım projesi:

150.000 – 500.000 USD

Büyük ölçekli kurumsal dönüşüm projesi:

500.000 USD ve üzeri

Bütçesini tamamen gizleyen alıcı, iki riske açık kapı bırakır:

Birincisi, projeye uygun olmayan firmalarla zaman kaybeder.

İkincisi, kapsam sonradan kontrolsüz biçimde büyür.

İyi bir yazılım firması, bütçenize göre sadece fiyat değil, doğru kapsam önerisi de sunabilmelidir.

3. Takviminiz gerçek mi, yoksa sadece beklenti mi?

Her teslim tarihi aynı ağırlıkta değildir.

Bazı tarihler değiştirilemez:

* Yasal uyum zorunluluğu

* Fuar ya da lansman tarihi

* Mevcut sözleşmenin yenilenme dönemi

* Operasyonel geçiş tarihi

* Yönetim kuruluna verilmiş taahhüt

Bazı tarihler ise daha esnektir:

“Q3 sonuna yetişse iyi olur”

“Yazdan önce canlıya almak istiyoruz”

“Mümkünse 3 ayda bitsin”

Bu ayrımı en başta yapmazsanız, firma size iyimser bir plan sunabilir. Kağıt üzerinde iyi görünen bu plan, gerçek hayatta çoğu zaman tutmaz.

Doğru soru şudur:

> “Bu tarihin kaçırılması durumunda iş etkisi ne olur?”

Eğer cevap “çok ciddi” ise, proje planı buna göre tasarlanmalıdır.

4. Risk toleransınız ne?

Bazı şirketler hızlıca canlıya çıkıp ürünü zaman içinde geliştirmek ister.

Bazıları ise ilk versiyonda daha kontrollü, daha sağlam ve kurumsal standartlara uygun bir yapı bekler.

Bu iki yaklaşımın ikisi de doğru olabilir. Yanlış olan, hangi yaklaşımı istediğinizi yazılım firmasıyla netleştirmemektir.

Kendinize şu soruyu sorun:

> “Hızlı çıkalım, sonra düzeltiriz mi diyoruz; yoksa ilk versiyonda daha olgun ve kontrollü bir yapı mı istiyoruz?”

Bu cevap teknik değil, stratejiktir.

Çünkü firmanın çalışma kültürü, geliştirme hızı, test yaklaşımı, dokümantasyon seviyesi ve ekip yapısı buna göre değişir.

Siz daha kurumsal ve kontrollü bir süreç beklerken firma hızlı MVP mantığıyla ilerliyorsa, proje daha ilk ayda gerilim üretmeye başlar.

Yazılım Firmasını Değerlendirirken Sormanız Gereken Sorular

5. Bu projede çalışacak ekibin net listesi nedir?

Bu soru önemlidir çünkü satış sürecinde gördüğünüz ekip ile proje başladığında çalışan ekip her zaman aynı olmayabilir.

Bazı firmalar görüşmelere çok deneyimli kişilerle girer. Ancak proje başladıktan sonra işin büyük kısmı daha junior ekiplere devredilir.

Bu yüzden şu soruyu doğrudan sormalısınız:

> “Proje başladığında bizimle çalışacak kişilerin isimlerini, rollerini ve mümkünse LinkedIn profillerini görebilir miyiz?”

Burada amaç kişileri tek tek denetlemek değildir. Amaç, firmanın size gerçekten hangi ekibi ayırdığını anlamaktır.

Eğer firma bu sorudan kaçınıyorsa, bu bir uyarı işaretidir.

İyi firma, ekibini saklamaz. Hangi rolde kimin yer alacağını, hangi kişinin ne kadar zaman ayıracağını ve karar verici teknik sorumlunun kim olduğunu açıkça anlatır.

6. Geçmişte zorlandığınız ya da kaybettiğiniz bir projeyi anlatabilir misiniz?

İyi yazılım firmaları bu sorudan kaçmaz.

Çünkü her ciddi ekip zor proje yaşamıştır. Önemli olan, hiç hata yapmamış olmak değil; hatadan ne öğrendiğini gösterebilmektir.

Şu cevap iyi bir işarettir:

> “X projesinde kapsamı yeterince erken netleştiremedik. Müşteri beklentisi büyüdü, teslim planı sarktı. Bu deneyimden sonra her projede ilk haftayı kapsam netleştirme ve risk analizi için ayırmaya başladık.”

Şu cevap ise risklidir:

> “Bizde böyle şeyler olmaz.”

Hiç sorun yaşamamış firma ya yeterince büyük proje yapmamıştır ya da sorunları açıkça konuşmaya hazır değildir.

Kurumsal yazılım projelerinde önemli olan kusursuzluk iddiası değil, kriz yönetme olgunluğudur.

7. Referans müşteriyi siz mi seçiyorsunuz, biz seçebilir miyiz?

Firmaların sunduğu referanslar çoğu zaman özellikle seçilmiş en iyi örneklerdir. Bu normaldir.

Ancak daha gerçekçi bir değerlendirme yapmak istiyorsanız şu soruyu sorun:

> “Geçen yıl tamamladığınız projelerden rastgele birini seçip, o müşteriyle konuşabilir miyiz?”

Bu her zaman mümkün olmayabilir. Gizlilik sözleşmeleri, sektör hassasiyetleri ya da müşteri politikaları buna engel olabilir.

Ama firmanın bu soruya yaklaşımı size çok şey anlatır.

İyi firma şöyle der:

> “Bazı müşterilerimiz gizlilik nedeniyle konuşamaz ama size benzer ölçekte 2–3 farklı referans alternatifi sunabiliriz.”

Riskli cevap ise şudur:

> “Referans paylaşamıyoruz.”

Hiç referans veremeyen ya da sadece tek bir parlak örneği gösteren firmayı daha dikkatli değerlendirmek gerekir.

8. Ücret modeliniz nasıl çalışıyor?

Yazılım projelerinde tek bir doğru fiyatlandırma modeli yoktur. Doğru model, projenin belirsizlik seviyesine göre değişir.

En yaygın üç model şunlardır:

Zaman ve efor bazlı çalışma modeli

Bu modelde ücret, projeye ayrılan ekip ve süre üzerinden hesaplanır.

Kapsamın henüz tam net olmadığı, ürünün zaman içinde şekilleneceği projeler için uygundur.

Avantajı esnekliktir.

Dezavantajı ise güçlü bir proje yönetimi yoksa bütçenin kontrolsüz büyüyebilmesidir.

Sabit fiyatlı proje modeli

Bu modelde kapsam, teslimatlar ve fiyat en başta netleştirilir.

Kapsamı çok net olan projeler için uygundur.

Avantajı bütçe öngörülebilirliğidir.

Dezavantajı ise proje sırasında değişiklik çıktığında sürecin yavaşlaması ya da maliyetin artmasıdır.

Aylık hizmet modeli

Bu model, uzun vadeli geliştirme ve bakım ilişkileri için uygundur.

Özellikle ürün sürekli gelişecekse, yeni modüller eklenecekse ya da iç ekip gibi çalışan dış bir teknoloji partnerine ihtiyaç varsa tercih edilebilir.

Önemli olan firmanın size tek bir modeli dayatması değil, projenizin doğasına göre doğru modeli önermesidir.

Şeffaf ücretlendirme yapan firma güven verir.

Belirsizliği özellikle koruyan firma ise ileride sürpriz maliyetler çıkarabilir.

Sözleşme ve Proje Yürütme Sürecinde Sormanız Gereken Sorular

9. Fikri mülkiyet ve kod sahipliği nasıl tanımlanıyor?

Bu konu sözleşmede açıkça yazmalıdır.

Özellikle stratejik bir ürün, iç operasyon platformu ya da müşteriye özel geliştirilen bir sistem yaptırıyorsanız, kodun ve fikri mülkiyet haklarının kime ait olduğu net olmalıdır.

Genellikle üç model görülür:

Tüm hakların müşteriye ait olduğu model

Özel yazılım projelerinde en sağlıklı model budur.

Kod, dokümantasyon ve proje çıktıları müşteriye ait olur. Firma yalnızca geliştirme hizmetini sağlar.

Firmanın bazı kullanım haklarını sakladığı model

Bazı firmalar geliştirdikleri altyapının ya da bileşenlerin kullanım hakkını saklamak isteyebilir.

Bu her zaman yanlış değildir. Ancak sınırları çok net çizilmelidir.

Ortak sahiplik modeli

Bu model en karmaşık olanıdır.

İlerleyen yıllarda ürünün satılması, başka bir firma tarafından geliştirilmesi, yatırım alınması ya da farklı pazarlara açılması gibi durumlarda sorun çıkarabilir.

Eğer stratejik bir yazılım geliştiriyorsanız, sözleşmede şu cümlelerin net karşılığı olmalıdır:

* Kod kime ait?

* Üçüncü taraf bileşenler var mı?

* Firma geliştirdiği yapıyı başka müşterilerde kullanabilir mi?

* Proje bittiğinde tüm erişimler ve dokümantasyon teslim edilecek mi?

Bu konu proje sonunda değil, en başta konuşulmalıdır.

10. Proje ortasında ekipten biri ayrılırsa ne olur?

Bu ihtimal her projede vardır.

Bir geliştirici işten ayrılabilir. Proje yöneticisi değişebilir. Teknik lider başka bir projeye kayabilir.

Önemli olan bunun olup olmayacağı değil, firmanın buna nasıl hazırlandığıdır.

İyi cevap şuna benzer:

> “Her projede düzenli dokümantasyon tutuyoruz. Kod standartlarımız belli. Haftalık toplantı notları, karar kayıtları ve teknik açıklamalar proje boyunca güncelleniyor. Ekip değişikliği olursa yeni kişi kısa sürede sürece dahil olabilir.”

Kötü cevap ise şudur:

> “Bizde ekip değişikliği olmaz.”

Bu gerçekçi değildir.

Kurumsal yazılım projelerinde kişi bağımlılığı büyük risktir. İyi firma, projeyi tek bir kişinin hafızasına bırakmaz.

Süreç, dokümantasyon ve kod yapısı ekip değişimini kaldırabilecek şekilde kurulmalıdır.

11. Canlıya geçiş sonrası destek nasıl çalışıyor?

Bir proje canlıya alındığında bitmiş sayılmaz.

Asıl gerçek kullanım, canlıya geçişten sonra başlar. Kullanıcılar sistemi kullanır, beklenmeyen senaryolar ortaya çıkar, küçük hatalar görünür hale gelir.

Bu yüzden canlıya geçiş sonrası destek modeli sözleşmede net olmalıdır.

Genellikle üç model vardır:

Garanti dönemi

Belirli bir süre boyunca hata düzeltmeleri ücretsiz yapılır.

Bu süre genellikle 30–90 gün arasında değişir.

Burada önemli olan, hangi tür hataların garanti kapsamında olduğunun açıkça yazılmasıdır.

Aylık bakım ve destek modeli

Sistem canlıda çalışmaya devam ederken, firma belirli bir aylık ücret karşılığında destek, bakım, izleme ve küçük geliştirmeler sağlar.

Kurumsal sistemler için çoğu zaman en sağlıklı model budur.

Desteksiz teslim modeli

Proje teslim edilir ve sonrasında destek ayrı değerlendirilir.

Bu model küçük işler için kabul edilebilir olabilir. Ancak kritik operasyonel sistemlerde ciddi risk yaratır.

Sözleşmede en azından şu başlıklar yer almalıdır:

* Canlıya geçiş sonrası kaç gün destek verilecek?

* Hangi hatalar ücretsiz düzeltilecek?

* Müdahale süreleri ne olacak?

* Kritik hata tanımı nedir?

* Yeni geliştirme talepleri nasıl fiyatlandırılacak?

Canlıya geçiş sonrası destek konuşulmuyorsa, proje eksik planlanmış demektir.

12. Projeyi başka bir ekibe devretmek gerekirse süreç nasıl işler?

Bu soru kulağa olumsuz gelebilir ama aslında profesyonel bir sorudur.

İyi yazılım firması, müşteriyi kendisine bağımlı hale getirmeye çalışmaz. Tam tersine, gerektiğinde projenin başka bir ekip tarafından devralınabileceği kadar düzenli çalışır.

Şu soruları mutlaka sorun:

* Kod deposuna erişim kimde olacak?

* Sunucu ve altyapı erişimleri müşteride olacak mı?

* Teknik dokümantasyon teslim edilecek mi?

* Kurulum ve yayınlama süreçleri yazılı olacak mı?

* Üçüncü taraf servis hesapları kime ait olacak?

* Başka bir firma projeyi devralmak isterse ne kadar sürede adapte olabilir?

İyi firma bu konuyu ilk günden konuşabilir.

Kötü firma ise bu soruyu tehdit gibi algılar.

Oysa bu bir güven meselesidir. Projeyi devredebilir şekilde geliştiren firma, zaten genellikle daha düzenli ve sürdürülebilir çalışıyordur.

Karar Matrisi: 12 Cevabı Nasıl Değerlendirebilirsiniz?

Her soru için firmaya 0–3 arasında puan verebilirsiniz.

0 puan: Net cevap vermedi veya sorudan kaçındı.

1 puan: Cevap verdi ama belirsiz kaldı.

2 puan: Net ve makul bir cevap verdi.

3 puan: Net cevap verdi, riskleri anladığını gösterdi ve olgun bir yaklaşım sundu.

Toplam skor şu şekilde yorumlanabilir:

30 puan ve üzeri

Güçlü uyum var. Bir sonraki aşamaya geçilebilir.

20–29 puan

Kısmi uyum var. Ek görüşme ve detaylı değerlendirme gerekir.

10–19 puan

Zayıf uyum var. Alternatif firmalarla görüşmek daha sağlıklı olabilir.

10 puanın altı

Bu firma proje için uygun görünmüyor.

Bu matris tek başına karar verdirmez. Ancak görüşme sürecini kişisel izlenimlerden çıkarıp daha objektif hale getirir.

Internative Olarak Biz Bu 12 Soruyu Müşterilerimizle Birlikte Yanıtlıyoruz

Yeni bir proje görüşmesine başladığımızda, ilk 30 dakikalık ücretsiz değerlendirme görüşmesinin amacı tam olarak budur:

Projenin hedefini, kapsamını, risklerini, bütçesini, takvimini ve doğru ekip modelini birlikte netleştirmek.

Bu görüşmenin sonunda üç şeyden biri ortaya çıkar:

Eğer sizin için doğru teknoloji partneri bizsek, somut bir yol haritası ve öneriyle ilerleriz.

Eğer proje henüz hazır değilse, önce hangi noktaların netleşmesi gerektiğini paylaşırız.

Eğer sizin için doğru firma biz değilsek, hangi tür ekip ya da çalışma modelinin daha uygun olabileceğini açıkça söyleriz.

Çünkü iyi bir yazılım projesi yalnızca iyi kodla başlamaz.

Doğru sorularla başlar.

30 dakikalık ücretsiz proje değerlendirme görüşmesi planlayın.

Bu soruların yazdırılabilir PDF versiyonunu istiyorsanız, e-posta adresinizi bırakarak rehberi indirebilirsiniz.

Software Graveyard: Yarım Kalan Yazılım Projelerini Kurtarma Hizmetimiz