Yazılım firması seçerken: teklif öncesi sorulacak 20 soru

Yazılım firması seçerken fiyattan önce beş şeyi doğrulayın: kodu kim yazıyor; gösterilen işler ve referanslar gerçekten o firmanın mı; iş bitince kod, sunucu ve hesaplar kimde kalıyor; değişiklikler ve hatalar yazılı bir kurala bağlı mı; ilişki biterse sistem nasıl ayakta kalıyor. Teklif almadan önce sorulacak 20 soru, bu beşini iki üç kısa görüşmede ölçmenize yardım eder.

Bu rehber, elinde yazılı bir brief olan ve iki üç yazılım firması arasında karar vermeye hazırlanan kurucular ve KOBİ sahipleri için. Brief'iniz henüz yoksa önce yazılım yaptırmak istiyorum: brief şablonu yazısıyla başlayın. Teklifleri fiyat ve kapsam açısından karşılaştırmayı ise yazılım yaptırma maliyeti ve teklif karşılaştırma rehberinde ayrıca ele aldık. Bu rehber fiyatı bilerek dışarıda bırakıyor; bana göre yanlış firmadan pazarlıkla alınan indirim, sonradan çıkabilecek devir ve düzeltme maliyetinin yanında küçük kalır.

Bir açıklamayla başlayayım: ben de bir yazılım firmasında, UlvionTech'te çalışıyorum. Bu yüzden soruları bize de sorulabilecek biçimde yazdım. 2025'te kurulmuş bir şirket olarak hangi sorularda bugün size ne gösterebildiğimizi "UlvionTech'i aynı sorularla nasıl sınarsınız?" başlığında ayrıca belirttim.

Yazılım firması seçerken neye bakılır?

Yazılım firması seçerken bakılacak asıl ölçüt, firmanın kendisi hakkında söyledikleri değil, işi nasıl yürüttüğünü belgeyle ve canlı işle gösterip gösteremediğidir. Bir firmayı değerlendirseydim beş başlıkta cevap arardım; her biri teklif metninden değil, görüşmeden, belgelerden ve bir referans aramasından doğrulanabilir.

• Ekip: Kodu yazacak kişiler belli mi, görüşmeye geliyorlar mı, işin bir kısmı başka birine mi gidiyor?
• Kanıt: Gösterilen işler canlıda açılıyor mu, firmanın o işteki payı net mi, eski bir müşteriyle konuşabiliyor musunuz?
• Sahiplik: Kod deposu, sunucu, alan adı ve hesaplar ilk günden sizin adınıza mı açılıyor, haklar sözleşmede yazılı mı?
• Süreç: Değişiklikler, ilerleme, kabul testi ve teslim sonrası hatalar yazılı bir kurala bağlı mı?
• Süreklilik: İlişki biterse ya da firma kapanırsa başka bir ekip sistemi devralabilir mi?

Bu listede teknoloji yığını, ofis büyüklüğü ya da ödül yok. Bunların hiçbir anlamı olmadığını söylemiyorum; ama teklif aşamasında doğrulamaları zordur. Beş başlıktaki cevaplar ise birkaç belge ve bir görüşmeyle kontrol edilebilir. Firmanın kaç yıllık olduğu da tek başına çok şey söylemez, çünkü uzun bir geçmiş bugün projenize kimin atanacağını garanti etmez.

Teklif almadan önce yazılım firmasına sorulacak 20 soru nelerdir?

Teklif almadan önce yazılım firmasına sorulacak 20 soru, on temayı ikişer soruyla kapsar: ekip, kanıt, sahiplik, kapsam, iletişim, teslim sonrası, güvenlik ve KVKK, devir, çıkış ve dürüstlük. Her sorunun yanına iyi bir cevabın kabaca neye benzediğini yazdım. Cevabın birebir böyle olması gerekmez, ama somutluk düzeyi bu kadar olmalı.

1. Ekip: Kodu projede kim yazacak, bu kişilerle teklif öncesi tanışabilir miyim? İyi cevap: isimler ve roller veriliyor, teknik görüşmeye işi yapacak geliştirici katılıyor.
2. Ekip: İşin herhangi bir kısmını alt yükleniciye ya da serbest çalışana veriyor musunuz? İyi cevap: net bir evet ya da hayır; evetse hangi parça, kimin yönetiminde ve hakların size nasıl geçeceği sözleşmede yazılı.
3. Kanıt: Benzer bir işi canlıda açıp hangi kısmını sizin yaptığınızı gösterebilir misiniz? İyi cevap: çalışan bir sistem ya da site ve firmanın payının açıkça sınırlanması ("tasarım bizim değildi, arka uç bizimdi" gibi).
4. Kanıt: Önceki bir müşterinizle doğrudan konuşabilir miyim? İyi cevap: izni alınmış bir isim ve iletişim bilgisi; yoksa bunu açıkça söyleyip yerine neyin doğrulanabileceğini önermek.
5. Sahiplik: Kod deposu, sunucu, alan adı ve mağaza hesapları kimin adına açılacak? İyi cevap: ilk günden şirketiniz adına; firma bu hesaplarda yalnızca yetkili kullanıcı.
6. Sahiplik: Projede kullanılacak hazır bileşenleri ve lisanslarını listeler misiniz? İyi cevap: açık kaynak kütüphaneler ve ücretli servisler, lisanslarıyla birlikte devir belgesinde yer alıyor.
7. Kapsam: Teklif vermeden önce bize hangi soruları soracaksınız? İyi cevap: kullanıcılar, bugünkü süreç, entegrasyonlar ve öncelikler hakkında sorular. Hiç soru sormadan fiyat veren bir firma işi anlamamış olabilir.
8. Kapsam: Proje sürerken bir değişiklik istersek süreç nasıl işliyor? İyi cevap: talep e-postayla iletilir, süreye ve bedele etkisi geliştirmeden önce bildirilir, siz onaylarsınız.
9. İletişim: İlerlemeyi ne sıklıkla ve nerede göreceğim? İyi cevap: belirli aralıklarla, test ortamında kendinizin deneyebileceği çalışan bir sürüm; yalnızca yüzde veren durum raporları değil.
10. İletişim: Günlük muhatabım kim olacak, o kişi ayrılırsa ne olur? İyi cevap: isimli bir muhatap, yazılı bir kanal, bir yedek kişi ve kararların yazılı kaydı.
11. Teslim sonrası: Teslimden sonra çıkan hataları ne kadar süre, hangi koşulla ücretsiz düzeltiyorsunuz? İyi cevap: yazılı bir destek dönemi, hatanın tanımı ve bildirimlere dönüş süresi.
12. Teslim sonrası: Kabul testini nasıl yapacağız, bir parça neye göre "bitti" sayılacak? İyi cevap: yazılı kabul ölçütleri, bir test ortamı ve size ayrılmış bir deneme süresi.
13. KVKK: Kişisel verilere ekibinizden kimler, hangi yetkiyle erişecek? İyi cevap: erişimi olan kişilerin listesi, gereken en az yetki ve iş bitince erişimlerin kapatılması.
14. Güvenlik: Şifreler, yedekler ve güncellemeler geliştirme sırasında nasıl yönetiliyor? İyi cevap: şifreler kodun içinde değil ayrı bir gizli bilgi deposunda, yedekten geri dönüş denenmiş, kütüphane güncellemelerinin bir sorumlusu var.
15. Devir: Proje bittiğinde hangi belgeleri teslim alacağım? İyi cevap: kurulum ve çalıştırma talimatı, mimari özet, hesap ve servis listesi, yönetim paneli kılavuzu.
16. Devir: Başka bir ekip bu kodu devralmak isterse işe nasıl başlar? İyi cevap: yaygın bir teknoloji, belgelenmiş kurulum ve istenirse bir devir toplantısı.
17. Çıkış: Sözleşmeyi erken bitirirsek o güne kadar yapılan iş nasıl teslim edilir? İyi cevap: kod zaten sizin deponuzda; ödeme ve teslim aşamalara bağlı olduğu için yarım kalan iş de devredilebilir durumda.
18. Çıkış: Firmanız kapanırsa ya da çalışmayı bırakırsak sistem nasıl ayakta kalır? İyi cevap: hesaplar ve ödemeler sizde olduğu için sistem çalışmayı sürdürür, bakımını başka bir ekip devralabilir; erişimlerin geri alınacağı bir liste ve verilerin dışa aktarım yolu hazır.
19. Dürüstlük: Bu projede gördüğünüz en büyük risk ne? İyi cevap: somut bir risk (bir entegrasyon, veri taşıma, takvim) ve onu nasıl küçülteceklerine dair bir öneri.
20. Dürüstlük: Bu işin hangi kısmını sıfırdan yazmanıza gerek yok? İyi cevap: ödeme, e-posta ya da harita gibi hazır servislerle çözülecek parçaları ayırıp yalnızca işinize özgü kuralları yazmayı önermek.

Bu soruları tek görüşmede sormaya çalışmayın. Benim önerim, ilk görüşmede ekip, kanıt ve kapsam sorularını, ikinci görüşmede iletişim, teslim sonrası, sahiplik, güvenlik, devir ve çıkış sorularını sormak. Cevapların görüşmeden sonra e-postayla yazılı olarak teyit edilmesini de isterdim, çünkü sözlü verilip yazıya geçmeyen bir cevap sözleşme günü yeniden konuşulmak zorunda kalır.

Yazılım firmasının iyi ve zayıf cevabı nasıl ayırt edilir?

Bir yazılım firmasının iyi cevabı isim, belge ve yazılı kural içerir; zayıf cevabı ise "uzman kadromuz var" ya da "teslimde devrederiz" gibi doğrulanamayan genel ifadelerdir. Tablodaki satırları her firma için ayrı ayrı işaretlerseniz, hangi firmanın hangi temada belirsiz kaldığı tek bakışta ortaya çıkar.

Kodu kim yazıyor: firmanın kendi ekibi mi, alt yüklenici mi?

Bir yazılım firmasında kodu her zaman satış görüşmesine gelen ekip yazmaz; işin bir kısmı alt yükleniciye ya da serbest çalışana gidebilir. Bu yüzden teklif öncesi kodu kimin yazacağını isim ve rolle sorun, alt yükleniciyi de sözleşmeye yazdırın. Alt yüklenici kullanmak tek başına kötü bir şey değil: bir mobil uygulama gibi uzmanlık gerektiren bir parçayı o işi iyi bilen birine vermek mantıklı olabilir. Sorun, bunun size söylenmemesi ve kimin hangi kuralla çalıştığını bilmemenizdir. Ben bu soruda cevabın kendisi kadar, ne kadar rahat verildiğine de bakardım.

Türk Borçlar Kanunu md. 471, eser sözleşmesinde yükleniciye eseri bizzat yapma ya da kendi yönetimi altında yaptırma borcu yükler; yüklenicinin kişisel özellikleri önem taşımıyorsa iş başkasına da yaptırılabilir (TBK md. 471 (yeni sekmede açılır)). Bir yazılım sözleşmesinin bu hükümlere tabi olup olmadığı içeriğine göre değişebilir. Bu yüzden işin başkasına verilip verilemeyeceğini ve hangi koşulla verileceğini sözleşmeye açıkça yazdırmak en temiz yoldur.

Alt yüklenici kullanımı, kodun fikri haklarının size geçip geçmeyeceğini de etkiler. Fikir ve Sanat Eserleri Kanunu bilgisayar programlarını eser sayar; mali hakları kullanma yetkisi kural olarak eser sahibine aittir, çalışanların işlerini görürken ürettiği eserlerde ise haklar aralarındaki sözleşmeden ya da işin niteliğinden aksi anlaşılmadıkça işverence kullanılır (FSEK md. 2 ve 18 (yeni sekmede açılır)). Kodun bir kısmını firmanın çalışanı olmayan bir geliştirici yazıyorsa, firmanın size devredebileceği hak, o kişiden yazılı olarak aldığı hak kadardır.

FSEK md. 52, mali haklara dair sözleşmelerin yazılı olmasını ve konusu olan hakların ayrı ayrı gösterilmesini şart koşar. Bu yüzden alt yüklenici kullandığını söyleyen bir firmaya, alt yükleniciden aldığı hak devrini nasıl belgelediğini de sorardım. TBK md. 471 ile FSEK md. 2, 18 ve 52'ye dair bu özet Ekim 2026 itibarıyla yürürlükteki kanun metinlerine dayanır ve hukuki görüş değildir; sözleşmeyi imzalamadan önce bir avukata okutun.

Yazılım firması referansı nasıl kontrol edilir?

Bir yazılım firmasının referansını kontrol etmenin en sağlam yolu, firmanın hazırladığı listeyi okumakla yetinmeyip canlı işi kendiniz açmak ve o işin sahibiyle, firmanın yanında olmadan konuşmaktır. Logo listeleri ve ekran görüntüleri kendi başlarına bir şey kanıtlamaz; yayındaki bir site ya da uygulama ise en azından işin var olduğunu gösterir.

İlk elemede canlı işte üç şeye bakın: sayfalar hızlı açılıyor mu, telefonda düzgün görünüyor mu ve firma o işteki payını açıkça söylüyor mu. "Hepsini biz yaptık" cevabı ayrıntı sorulduğunda dağılıyorsa, ben bunu not ederdim. Bir işin tamamını üstlenmiş olmak şart değil; önemli olan, firmanın payını dürüstçe anlatabilmesidir.

Referans görüşmesinde hazır bir metin dinlememek için açık uçlu ve olaylara dayalı sorular sorun. "Memnun kaldınız mı?" sorusu genellikle kısa bir "evet" ile geçiştirilir. Şu sorular ise çok daha fazlasını gösterir:

• Plan değiştiğinde ne oldu? Kapsam ya da tarih kaydığında firma bunu ne zaman söyledi ve nasıl çözüldü?
• Kodu kim yazdı? Projede kimlerle konuştunuz, kişiler proje boyunca aynı kaldı mı?
• Hesaplar kimde? Bugün kod deposuna, sunucuya ve alan adına kendi hesabınızla girebiliyor musunuz?
• Teslimden sonra ne oldu? İlk haftalarda çıkan hatalar ne kadar sürede düzeldi, bunun için ek bedel istendi mi?
• Tekrar çalışır mıydınız? Çalışırsanız neyi farklı yapardınız?

Referans veren kişinin firmanın bir tanıdığı olma ihtimalini de hesaba katın. Mümkünse firmanın önermediği, sizin bulduğunuz bir eski müşteriye de ulaşın; firmanın projeler sayfasında adı geçen işlerin sahipleri bunun için iyi bir başlangıçtır. Yeni kurulmuş bir firmanın aranabilecek referansı az olabilir. O durumda ben referans yerine firmanın canlıda açıp payını gösterdiği benzer bir işe ve büyük projeden önce yapılacak küçük, ücretli bir ilk işe daha fazla ağırlık verirdim.

İş bitince ya da firma kapanırsa kod, hesaplar ve veriler kimde kalır?

İş bittiğinde ya da firma ortadan kalktığında kodun, hesapların ve verilerin sizde kalması, bunların ilk günden şirketiniz adına açılmasına ve devrin sözleşmede yazılı olmasına bağlıdır. Sonraya bırakılan devirler çoğu zaman pazarlığa döner ve bu pazarlık genellikle ilişkinin bittiği, yani pazarlık gücünüzün en düşük olduğu anda yapılır.

Kaynak kodunun mali haklarının sözleşmede nasıl devredileceğini teklif karşılaştırma rehberinde ayrıca anlattık. Yazılım firmasıyla ilişki biterse ne olacağını ölçmek için "yarın çalışmayı bırakırsak ne olur?" diye sorun. Ben bu soruyu sorsam iki tür cevap duymayı beklerdim: "hiçbir şey olmaz, her şey zaten sizin hesaplarınızda" ya da neyin devredilmesi gerektiğine dair net bir liste. Belirsiz bir cevap bugün değil, ilişki bittiğinde pahalıya patlar.

Çıkışın hazır olup olmadığını teslim belgelerinden anlarsınız. Bir devir paketinde en az şunları görmek isterdim:

• Hesap listesi: Kod deposu, sunucu, alan adı, e-posta servisi, mağaza hesapları ve ücretli servislerin hangi hesapta olduğu ve yetkili kişileri.
• Kurulum talimatı: Kodun sıfırdan başka bir bilgisayarda nasıl çalıştırılacağı ve gereken ortam ayarlarının listesi (değerleri değil).
• Mimari özet: Sistemin parçaları, hangi servislere bağlandıkları ve verinin nerede tutulduğu, bir iki sayfada.
• Veri çıkışı: Verilerin hangi biçimde ve nasıl dışa aktarılacağı.
• Erişim kapatma listesi: İlişki bittiğinde firmanın erişimlerinin hangi sırayla kapatılacağı.

Devir paketindeki bu belgeler bir firmanın dürüstlüğünü değil, işinin devredilebilir olup olmadığını gösterir. Devredilebilir bir iş sizi firmaya bağımlı kılmaz; firma da sizi tutmak için iyi iş çıkarmak zorunda kalır. Bana göre sağlıklı bir müşteri ilişkisi de buna dayanır.

Teslimden sonra çıkan hataları kim, hangi koşulla düzeltir?

Teslimden sonra çıkan hataları kimin ve hangi koşulla düzelteceğini, sözleşmede yazılı bir destek dönemi, açık kabul ölçütleri ve hata ile yeni istek arasındaki farkın tanımı belirler. Gerçek kullanıcılar sistemi kullanmaya başladığında hata çıkması olağandır; önemli olan bunun kuralıdır.

Bir hata, kapsamda yazılı bir işin yazıldığı gibi çalışmamasıdır. Kapsamda olmayan bir davranışın istenmesi ise yeni bir istektir. Bu ayrım yazılı değilse her bildirim bir tartışmaya dönüşebilir. Firmadan bu farkı kendi cümleleriyle anlatmasını ve bir örnek vermesini isteyin; bana göre cevabın netliği, ilk aylarda yaşanacak ilişkinin de habercisidir.

Kabul testinin hukuki bir ağırlığı da var. Türk Borçlar Kanunu'na göre eser sözleşmesinde iş sahibi, teslimden sonra imkân bulur bulmaz eseri gözden geçirmek ve ayıpları uygun bir süre içinde yükleniciye bildirmek zorundadır (TBK md. 474 (yeni sekmede açılır)). Gözden geçirmeyi ve bildirimi ihmal eden iş sahibi eseri kabul etmiş sayılır; kabulden sonra yüklenici sorumluluktan kurtulur (TBK md. 477 (yeni sekmede açılır)). Usulüne uygun bir gözden geçirmede fark edilemeyecek ayıplar ile yüklenicinin kasten gizlediği ayıplar bunun dışındadır; böyle bir ayıp sonradan ortaya çıkarsa iş sahibi bunu gecikmeksizin bildirmelidir; bildirmezse eseri kabul etmiş sayılır (TBK md. 477).

TBK md. 474 ve 477'deki gözden geçirme ve bildirim kuralları (Ekim 2026 itibarıyla yürürlükteki metin; hukuki görüş değildir), yazılım teslimlerinde kabul testini atlamanın neden riskli olduğunu gösterir. Sözleşmenizin bu hükümlere tabi olup olmadığını ve destek döneminin bunlarla nasıl birleştiğini bir avukata sorun. Benim pratik önerim, her teslimden sonra kabul ölçütlerini tek tek denemek ve bulduğunuz her sorunu yazılı bildirmektir.

Değişiklik talepleri de aynı mantıkla yönetilir. İyi bir firma, bir değişikliğin süreye ve bedele etkisini geliştirmeye başlamadan önce yazılı olarak bildirir ve onayınızı bekler. "Küçük değişiklikler dahildir" gibi ölçüsü olmayan ifadeler iki tarafı da zor durumda bırakır. Burada sormanız gereken, bu kuralın kim tarafından ve hangi belgeyle işletildiğidir.

Yazılım firması KVKK açısından veri işleyen midir, neyi sormalısınız?

Yazılım firması sizin adınıza ve sizin verdiğiniz yetkiyle kişisel verileri işliyorsa, KVKK'daki tanıma göre veri işleyendir; verinin işleme amaçlarını ve vasıtalarını belirleyen şirketiniz ise veri sorumlusu olarak kalır (KVKK md. 3 (yeni sekmede açılır)). Bu ayrımın pratik sonucu KVKK md. 12'de yazılıdır.

Ekim 2026 itibarıyla yürürlükteki metne göre KVKK md. 12, veri sorumlusunu kişisel verilerin hukuka aykırı işlenmesini ve bunlara hukuka aykırı erişilmesini önlemek ve verilerin muhafazasını sağlamak için gerekli teknik ve idari tedbirleri almakla yükümlü tutar. Veriler sizin adınıza başkası tarafından işleniyorsa, bu tedbirler konusunda o kişiyle birlikte müştereken sorumlu olursunuz.

KVKK md. 12'ye göre veri işleyenler, öğrendikleri kişisel verileri kanuna aykırı olarak başkasına açıklayamaz ve işleme amacı dışında kullanamaz; bu yükümlülük görevden ayrıldıktan sonra da sürer (Ekim 2026 itibarıyla yürürlükteki metin; hukuki görüş değildir). Ben bir firmadan "güvenliğe önem veririz" cümlesini yeterli bulmazdım; şu sorulara somut cevap beklerdim:

• Erişim: Canlı veritabanına kimler erişebiliyor, erişimler kişi bazında mı, iş bitince nasıl kapatılıyor?
• Ortamlar: Geliştirme ve test sırasında gerçek kişisel veriler mi kullanılıyor, yoksa anonim ya da örnek veri mi?
• Konum: Veriler hangi sunucuda, hangi ülkede tutulacak ve bu seçimi kim yapıyor?
• Kayıt ve olay: Sisteme kimin ne zaman eriştiği kaydediliyor mu, bir veri sızıntısı şüphesinde size ne kadar sürede haber veriliyor? KVKK md. 12, veri sorumlusunun böyle bir durumu en kısa sürede ilgilisine ve Kurula bildirmesini ister.
• Sözleşme: Veri işlemeyle ilgili yükümlülükler ana sözleşmede ya da ek bir metinde yazılı mı?

Yurt dışındaki sunucular ve veri aktarım kuralları ayrı ve teknik bir konu. Sağlık verisi gibi özel nitelikli kişisel veri işleyecekseniz, firmayla konuşmadan önce bir KVKK danışmanına da danışmanızı öneririm.

Hangi uyarı işaretleri görülürse o firmadan uzak durmalısınız?

Bir yazılım firmasından uzak durmanızı gerektiren yedi uyarı işareti genellikle daha teklif aşamasında görünür: yazılı kapsamın olmaması, açıklaması yapılamayan düşük bir fiyat, hiç soru sorulmaması, imza baskısı, isimsiz bir ekip, hesapların firma adına açılması ve her isteğe "evet" denmesi.

• Yazılı kapsam yok: Fiyat bir sohbet notuna ya da tek satırlık bir toplama dayanıyor; neyin dahil olmadığı hiç yazılmamış.
• Açıklamasız düşük fiyat: Teklif diğerlerinin çok altında ve firma farkın nereden geldiğini (daha dar kapsam, hazır şablon, farklı varsayım) anlatamıyor.
• Soru yok: Firma brief'inizi okuyup tek bir soru sormadan fiyat ve tarih veriyor.
• İmza baskısı: "Bu fiyat yalnızca bu hafta geçerli" gibi sürelerle karar hızlandırılmaya çalışılıyor.
• İsimsiz ekip: Projede kimin çalışacağı söylenmiyor, teknik soruları hep satıştan sorumlu kişi cevaplıyor.
• Hesaplar firmada: Alan adının, sunucunun ya da kod deposunun firma adına açılması "pratik olduğu için" öneriliyor.
• Her şeye evet: Hiçbir istek için "bu ilk sürümde gereksiz" ya da "bunu hazır bir servisle çözelim" denmiyor.

Yedi uyarı işaretinden yalnızca biri bir firmayı elemeye yetmeyebilir; düşük fiyatın makul bir açıklaması olabilir. İki ya da üç işaret bir aradaysa ben görüşmeyi orada keserdim. Bir firma sizi bir isteğinizden vazgeçirmeye çalışıyor ve gerekçesini anlatabiliyorsa, bu genellikle iyi bir işarettir; işin sonucuna baktığını gösterir.

Yazılım firması seçerken hangi hatalar sık yapılır?

Yazılım firması seçerken yapılan hataların önemli bir kısmı, kararı hızlandırma isteğinden doğan genel kalıplardır:

• Sunumla karar vermek: Projeyi kimin yapacağını görmeden, satış sunumunun kalitesine bakarak seçmek.
• Tek firmayla görüşmek: Karşılaştırma yapılmadığı için iyi ve zayıf cevap arasındaki farkı görememek.
• Referansı yalnızca dinlemek: Firmanın verdiği referansı aramak ama canlı işi açmamak ve olaylarla ilgili soru sormamak.
• Sahipliği sona bırakmak: Hesapların ve hakların kimde olduğunu yayından sonra sormak.
• Kabul testini atlamak: Teslimi gözden geçirmeden kabul edip hataları aylar sonra fark etmek.
• Sözlü cevaplara güvenmek: Görüşmede verilen taahhütleri yazıya geçirmemek.

Serbest çalışan mı, yazılım firması mı, şirket içi ekip mi?

Serbest çalışan, yazılım firması ve şirket içi ekip arasındaki seçim; işin büyüklüğüne, ne kadar süreceğine ve sistemi yayından sonra kimin sahipleneceğine göre yapılır. Ben bu kararı şu ölçülerle verirdim:

• Serbest çalışanı seçin: İş küçük ve sınırlıysa (bir formu bir tabloya bağlamak, mevcut bir sitede birkaç düzeltme), tek bir kişinin yetkinliği yetiyorsa ve o kişi ayrıldığında işi devralacak birini bulabilecekseniz.
• Yazılım firmasını seçin: İş tasarım, arka uç, mobil ya da entegrasyon gibi birkaç uzmanlık gerektiriyorsa, bir kişinin ayrılması projeyi durdurmamalıysa ve yazılı bir kapsam, teslim planı ve destek dönemi istiyorsanız.
• Şirket içi ekip kurun: Yazılım işinizin merkezindeyse, geliştirme sürekli olacaksa ve ekibi yönetecek teknik bir kişiniz varsa. Abonelikli bir ürün kuruyorsanız (SaaS nasıl yapılır rehberinde anlattığımız gibi) uzun vadede genellikle iç ekip gerekir; bir firma ilk sürümü kurup ekibinize devredebilir.
• Hazır programla başlayın: Süreciniz sektörünüzdeki pek çok şirketinkiyle aynıysa ve hazır bir program onu ayarlarıyla karşılıyorsa. O durumda özel yazılım çoğu zaman gereksiz bir maliyettir.

Hazır program ile özel yazılım arasında kaldıysanız, özel yazılımın avantajlarını bilerek tartın. Özel yazılımda kurallar işinize göre yazılır, sözleşmede öyle yazılırsa veri ve kod sizin adınıza durur, kullanıcı ya da şube sayısı arttıkça kullanıcı başı lisans bedeli ödemezsiniz (sunucu ve bakım maliyeti ise kullanımla artabilir) ve kendi sistemlerinize istediğiniz entegrasyonu kurabilirsiniz. Bunun bedeli daha uzun bir ilk sürüm, daha yüksek bir başlangıç maliyeti ve sistemi sahiplenecek birinin gerekmesidir.

Yapay zekâ destekli geliştirme araçları ilk sürümün maliyetini düşürebiliyor; bu araçların nerede yettiğini ve nerede ekip gerektiğini yapay zekâ ile uygulama nasıl yapılır yazısında ele aldık. Karşılaştırmanın tamamı özel yazılım mı hazır yazılım mı rehberinde.

Yazılım firmalarıyla görüşmeler nasıl yürütülür ve karşılaştırılır?

Yazılım firmalarıyla görüşmeleri yürütmenin en sağlam yolu, iki ya da üç firmayla aynı brief üzerinden, aynı sırayla ve aynı sorularla görüşmek, cevapları tek bir tabloda işaretlemek ve kararı en az belirsizlik bırakan firmaya göre vermektir. Ben olsam adımları şöyle sıralardım:

1. Aynı brief'i gönderin. Firmaların hepsine aynı belgeyi gönderin ve ilk görüşmeden önce sorularını yazılı iletmelerini isteyin; hangi firmanın ne sorduğu ilk ipucudur.
2. İlk görüşmede ekip, kanıt ve kapsamı konuşun. Ekip, kanıt ve kapsam temalarındaki altı soruyu sorun; kodu yazacak kişinin görüşmeye katılmasını isteyin.
3. Canlı işi açın ve referansı arayın. İki görüşme arasında gösterilen işleri kendiniz deneyin, referansla firmanın yanında olmadan konuşun.
4. İkinci görüşmede iletişim, teslim sonrası, sahiplik, güvenlik, devir ve çıkışı konuşun. Sahiplik, iletişim, teslim sonrası, KVKK ve güvenlik, devir ve çıkış temalarındaki on iki soruyu sorun; cevapların e-postayla yazılı teyidini isteyin.
5. Dürüstlük sorularıyla bitirin. Projedeki en büyük riski ve sıfırdan yazılması gerekmeyen kısmı soran iki soruya verilen cevaplar, firmanın işinizi ne kadar anladığını gösterir.
6. Tabloyu doldurun. Her firma için karşılaştırma tablosundaki sekiz satırı iyi, orta ya da zayıf diye işaretleyin; cevap alamadığınız satırı zayıf sayın.
7. Kararı yazılı kapsamla tamamlayın. Seçtiğiniz firmadan sözleşmeden önce yazılı kapsam, teslim planı ve sahiplik maddelerini isteyin; fiyat karşılaştırmasını bundan sonra yapın.

Fiyatı bilerek en sona koyuyorum. Firmaları önce bu sorularla eler, kalan iki teklifi ondan sonra yan yana koyarsanız, aynı kapsamı fiyatlayan teklifleri karşılaştırmış olursunuz.

Yazılım firması görüşmesine neler götürülmeli?

• Brief'in son hali ve firmalara gönderildiği tarih
• 20 sorunun yazılı listesi, her firma için ayrı bir sayfa
• Karşılaştırma tablosunun boş bir kopyası
• Projede karar verecek ve test edecek kişilerin adları
• Bağlanacak sistemlerin listesi (muhasebe, ERP, ödeme) ve varsa belgeleri
• Kişisel veri içeren alanların listesi
• Firmadan istenecek örnekler: bir kapsam dokümanı, bir devir belgesi ve sözleşme taslağı
• Firmanın ticaret sicili kaydı ve sözleşmeyi imzalayacak kişinin imza yetkisi (imza sirküleri)
• Destek dönemi bittikten sonraki bakımın nasıl fiyatlandığına dair yazılı bilgi

UlvionTech'i aynı sorularla nasıl sınarsınız?

UlvionTech'i de bu 20 soruyla sınayabilirsiniz; biz de bunu yapmanızı isteriz. UlvionTech 2025'te İstanbul'da kuruldu; bu yüzden size yıllara yayılan bir müşteri listesi ya da sonuç ölçümleri içeren vaka çalışmaları gösteremiyoruz. Bugün doğrulayabilecekleriniz şunlar: projeler sayfamızda yayındaki işlerimiz ve her birinde ne geliştirdiğimiz ile teknik görüşmede kodu yazacak mühendislerle doğrudan konuşmanız. Hesapların ilk günden sizin adınıza açılacağını, yazılı kapsamı ve süresi belirli destek dönemini ise imzadan önce sözleşme taslağımızda yazılı olarak görebilirsiniz.

Bugün doğrulayamayacağınız şeyler de var. Referans görüşmesi için müşterilerimizden her seferinde izin almamız gerekir; bu yüzden bunu önceden bir söz olarak vermiyoruz. Bu boşluğu kapatmak istiyorsanız büyük projeden önce küçük, ücretli bir ilk işle başlamanızı öneririm. Kim olduğumuzu hakkımızda sayfasında, hangi işleri yaptığımızı hizmetlerimiz ve özel web uygulaması geliştirme sayfalarında anlattık.

Hangi durumlarda UlvionTech ile çalışmamalısınız?

UlvionTech ile çalışmamanız gereken durumlar; işin bir yazılım firmasının sürecini gerektirmeyecek kadar küçük olduğu, şirket içinde işi yapabilecek bir ekibin bulunduğu, yazılı bir kapsam için zaman ayrılamadığı ya da hazır bir programın işi gördüğü durumlardır.

• Şirket içinde bir yazılım ekibiniz varsa: Ekibiniz işi yapabilecek kapasitedeyse, dışarıdan bir firmanın getireceği koordinasyon yükü kazancı aşabilir. Belirli bir uzmanlık eksikse yalnızca o parçayı dışarıdan almak daha mantıklıdır.
• İş küçükse: Bir formu bir tabloya bağlamak ya da mevcut bir sitede birkaç sayfayı güncellemek için keşif, kapsam dokümanı ve iki haftalık döngüler gereğinden ağırdır; bu işleri iyi bir serbest çalışan daha hızlı yapar.
• Yazılı kapsam için zaman ya da bütçe yoksa: Biz kodlamaya yazılı bir kapsamdan sonra başlıyoruz. "Hemen başlayalım, yolda netleşir" diyorsanız ve kapsam çalışmasına zaman ayıramıyorsanız, birlikte çalışmak iki tarafı da zorlar.
• Hazır bir program işinizi görüyorsa: Süreciniz sıra dışı değilse ve hazır bir program onu karşılıyorsa, özel yazılıma yatırım yapmanın gerekçesi zayıftır.

Bu bölümü bilerek ekledim, çünkü yanlış eşleşmeyle başlayan bir projenin iki taraf için de pahalı olduğunu düşünüyorum. Bu durumların hiçbiri size uymuyorsa ve elinizde bir brief varsa, 20 sorunun hepsini bize de sorabileceğiniz bir ilk görüşme için projenizi iletişim sayfasından birkaç cümleyle anlatın.