Bir yazılım firmasını seçmek, bir ürünü satın almaktan çok bir ortaklığa girmeye benzer: teslimattan sonra da yıllarca birlikte çalışırsınız. Bu rehberde önce işinize uygun çalışma modelini (hazır paket, freelancer, ajans, yazılım firması) belirliyor, ardından adayları 10 ağırlıklı kriterle puanlıyoruz. Her kriterde görüşmede sormanız gereken soruları ve sizi durdurması gereken kırmızı bayrağı bulacaksınız. Kriterlerin altındaki Zayıf / Yeterli / Güçlü düğmeleriyle aday firmanızı puanlayın; ağırlıklı skorunuz firma karnesinde ve yazının sonundaki sonuç kartında anında hesaplanır.
- Önce çalışma modelini seçin: her proje özel yazılım gerektirmez.
- Referansı logo listesiyle değil, konuşabileceğiniz müşteriyle doğrulayın.
- Tek satırlık teklif değil, kalem kalem kapsam ve kabul kriteri isteyin.
- Kaynak kodun, alan adının ve sunucu erişimlerinin sahibi siz olun.
- Yayın sonrası destek ve SLA, teslimat kadar önemlidir; sözleşmeye yazdırın.
Önce Doğru Model: Kimle Çalışmalısınız?
Firma karşılaştırmasına geçmeden önce ihtiyacın hangi çalışma modeline uygun olduğunu netleştirin. Basit bir tanıtım sitesi için kapsamlı bir yazılım ekibi fazla gelebilir; stok, cari ve sahayı bağlayan bir iş uygulamasında ise hazır paket kısa sürede tıkanır. Proje tipinizi seçin, tablo size en uygun modeli vurgulasın.
| Ölçüt | ÖnerilenHazır Paket / SaaS | Freelancer | ÖnerilenDijital Ajans | Yazılım Firması |
|---|---|---|---|---|
| Başlangıç maliyeti düşüklüğü | ||||
| İşe özel özelleştirme | ||||
| Ölçeklenebilirlik | ||||
| Güvenlik ve KVKK süreçleri | ||||
| Uzun vadeli destek güvencesi | ||||
| Kaynak kod / veri sahipliği | ||||
| İlk yayına çıkış hızı |
Referanslar ve Benzer Proje Deneyimi
Ağırlık: Kritik · ×3Bir firmanın web sitesindeki logo duvarı, o firmanın sizin projenize benzer bir işi başarıyla teslim ettiğini kanıtlamaz. Bakmanız gereken şey; sektör, ölçek ve teknik karmaşıklık bakımından sizinkine yakın en az iki projedir. Bir e-ticaret entegrasyonu ile bir saha servis uygulaması bambaşka yetkinlikler ister.
Referans projeyi canlı olarak inceleyin, mümkünse o müşteriyle doğrudan konuşun. Proje zamanında bitti mi, bütçe aşıldı mı, yayından sonra firma ulaşılabilir kaldı mı? Bu üç sorunun cevabı, sunum dosyasındaki tüm başlıklardan daha değerlidir. Vaka çalışması yayınlayan firmalarda (örneğin projelerimiz sayfasındaki gibi) problem, yaklaşım ve ölçülebilir sonucu birlikte arayın.
- Bizim sektörümüzde veya benzer ölçekte hangi projeyi yaptınız, canlı adresini paylaşabilir misiniz?
- Referans müşterinizden biriyle 15 dakikalık bir görüşme ayarlayabilir miyiz?
- Bu projede plan dışı ne yaşandı ve nasıl çözdünüz?
Referanslar yalnızca logo olarak var; canlı proje veya konuşulabilecek bir müşteri gösterilemiyor.
Ekip Yapısı ve Teknik Yetkinlik
Ağırlık: Kritik · ×3Satış görüşmesine gelen kişiyle projeyi yazacak ekip çoğu zaman aynı değildir. Projenizde kimlerin, hangi rollerde ve yüzde kaç zamanla çalışacağını isimleriyle öğrenin: proje yöneticisi, iş analisti, UI/UX tasarımcı, backend ve frontend geliştirici, test (QA) ve DevOps. Tek kişinin her rolü üstlendiği yapılar küçük işlerde çalışır, büyüdükçe darboğaz olur.
Teknoloji seçiminin gerekçesini sorun. "Hep bunu kullanıyoruz" bir gerekçe değildir; doğru cevap ihtiyacınızla ilişkilidir: trafik beklentisi, entegrasyonlar, ekibinizin ileride kodu devralma ihtimali. Kod inceleme (code review), sürüm kontrolü ve otomatik test pratiklerinin olup olmadığı, ekibin olgunluğunu en hızlı gösteren işarettir. Firmanın ekibini ve uzmanlık alanlarını açıkça paylaşması iyi bir başlangıçtır.
- Projede çalışacak kişiler kim, rolleri ve bu projeye ayrılan zamanları nedir?
- Kod inceleme ve otomatik test süreciniz nasıl işliyor?
- Ekipten biri ayrılırsa bilgi devri nasıl sağlanıyor?
Ekip isimleri ve rolleri paylaşılmıyor; işin önemli kısmının bilinmeyen alt yüklenicilere verileceği anlaşılıyor.
Keşif ve Analiz Süreci
Ağırlık: Kritik · ×3İyi bir yazılım firması fiyat vermeden önce soru sorar. İlk görüşmede iş hedeflerinizi, kullanıcı tiplerinizi, mevcut sistemlerinizi ve başarıyı nasıl ölçeceğinizi anlamaya çalışmayan bir teklif, büyük olasılıkla varsayımlar üzerine kuruludur ve o varsayımların faturası proje ortasında "ek iş" olarak size döner.
Orta ve büyük projelerde ayrı bir keşif (discovery) aşaması önerilmesi olumlu bir işarettir. Bu aşamanın çıktısı somut olmalıdır: kullanıcı senaryoları, ekran akışları veya wireframe'ler, entegrasyon listesi, önceliklendirilmiş iş listesi (backlog) ve riskler. Bu belgeler başka bir firmayla devam etseniz bile sizin elinizde kalan değerli bir varlıktır. Kapsamı netleştirmekte zorlanıyorsanız teknik danışmanlık ile başlamak toplam maliyeti düşürür.
- Teklif vermeden önce hangi bilgilere ihtiyacınız var?
- Keşif aşamasının çıktıları neler olacak ve bu belgelerin sahibi kim?
- Kapsam dışı bir talep geldiğinde değişiklik nasıl yönetiliyor?
İlk görüşmenin sonunda, tek bir soru sorulmadan kesin fiyat ve teslim tarihi veriliyor.
Teklif Şeffaflığı: Kapsam, Kalemler, Kabul Kriterleri
Ağırlık: Kritik · ×3"Kurumsal web yazılımı: X TL" şeklindeki tek satırlık bir teklif karşılaştırılamaz, denetlenemez ve anlaşmazlık anında hiçbir şeyi korumaz. Sağlıklı bir teklif; modülleri veya iş paketlerini, her birinin tahmini eforunu, dahil olan ve dahil olmayan işleri, ödeme takvimini ve her teslimatın kabul kriterini içerir.
Teklifleri yalnızca toplam rakamla kıyaslamayın. En düşük teklif genellikle ya kapsamın bir kısmını dışarıda bırakmıştır (test, içerik girişi, yayın, eğitim) ya da riski ileriye ertelemiştir. Sabit fiyat ile zaman-malzeme (time & material) modelinin artı ve eksilerini firmayla açıkça konuşun: kapsam netse sabit fiyat, belirsizlik yüksekse sprint bazlı bütçe daha adildir. İhtiyacınızı adım adım tarif edip karşılaştırılabilir bir teklif almak için teklif formunu kullanabilirsiniz.
- Teklifte hangi işler açıkça dahil değil?
- Her iş paketinin kabul kriteri nedir, onayı kim veriyor?
- Ödeme takvimi teslimat aşamalarına bağlı mı?
Kapsam dışı işler yazılmamış; ödemenin büyük bölümü iş başlamadan peşin isteniyor.
Proje Yönetimi ve İletişim Ritmi
Ağırlık: Önemli · ×2Projelerin çoğu teknik nedenle değil, iletişim kopukluğuyla raydan çıkar. Firmanın nasıl bir ritimle çalıştığını baştan öğrenin: 1–2 haftalık sprintler, her sprint sonunda çalışan yazılımın demosu, haftalık kısa durum raporu ve tek bir sorumlu iletişim kişisi. Böylece aylar sonra "beklediğimiz bu değildi" sürpriziyle karşılaşmazsınız.
İş takibi için kullanılan aracın (Jira, Linear, GitHub Projects vb.) size de açık olması, ilerlemeyi raporlara değil gerçeğe bakarak izlemenizi sağlar. Ayrıca kararların nerede yazılı tutulduğunu sorun: telefonda verilen kararlar unutulur, yazılı kararlar projeyi korur.
- Demo ve raporlama sıklığınız nedir, iş takip aracına erişimimiz olacak mı?
- Projede tek muhatabımız kim olacak?
- Bir gecikme fark edildiğinde bize ne zaman ve nasıl bildiriliyor?
Teslim tarihine kadar ara demo planlanmıyor; ilerleme yalnızca "her şey yolunda" mesajlarıyla raporlanıyor.
Kaynak Kod, Fikri Mülkiyet ve Sözleşme
Ağırlık: Kritik · ×3Parasını ödediğiniz yazılımın kaynak koduna erişemiyorsanız, aslında yazılımı değil firmaya bağımlılığı satın almışsınızdır. Sözleşmede kaynak kodun, tasarım dosyalarının ve dokümantasyonun mülkiyetinin (veya en azından süresiz ve münhasır kullanım hakkının) size geçtiği açıkça yazmalıdır. Kodun, sizin hesabınızda bulunan bir Git deposunda tutulması en temiz çözümdür.
Alan adı, SSL, sunucu, e-posta, uygulama mağazası ve üçüncü taraf servis hesapları şirketiniz adına açılmalıdır. Açık kaynak lisanslı bileşenlerin listesi, gizlilik yükümlülüğü, garanti süresi ve sözleşmenin sona ermesi hâlinde devir yükümlülükleri de sözleşmede yer almalıdır. Aşağıdaki örnek madde bir başlangıç noktasıdır; nihai metni mutlaka hukuk danışmanınızla birlikte hazırlayın.
MADDE 9 — FİKRİ MÜLKİYET VE DEVİR
9.1 Proje kapsamında üretilen kaynak kod, tasarım dosyaları
ve dokümantasyon, ilgili hak ediş ödendiği anda
İŞVEREN'e ait olur.
9.2 Kaynak kod, İŞVEREN adına açılan sürüm kontrol
deposunda tutulur; YÜKLENİCİ her sprint sonunda
güncel kodu bu depoya aktarır.
9.3 Sözleşmenin herhangi bir nedenle sona ermesinde
YÜKLENİCİ; tüm erişim bilgilerini, ortam
yapılandırmalarını ve kurulum dokümanını
10 iş günü içinde teslim eder.- Kaynak kodun mülkiyeti kime ait olacak ve kod hangi depoda tutulacak?
- Alan adı, sunucu ve servis hesapları kimin adına açılacak?
- Çalışmayı sonlandırırsak devir süreci nasıl işler?
Kaynak kod teslim edilmiyor veya yalnızca "lisans" olarak kullandırılıyor; hesaplar firmanın adına açılıyor.
Güvenlik ve KVKK Uyumu
Ağırlık: Kritik · ×3Kişisel veri işleyen her uygulama 6698 sayılı KVKK kapsamındadır ve bir güvenlik açığının hukuki sorumluluğu veri sorumlusu olarak sizde kalır. Bu yüzden firmanın güvenliği sonradan eklenen bir özellik değil, geliştirme sürecinin parçası olarak ele alması gerekir: şifrelerin güvenli saklanması, yetkilendirme kontrolleri, girdi doğrulama, HTTPS, güvenlik başlıkları ve bağımlılık güncellemeleri.
Firmaya OWASP Top 10 risklerine karşı nasıl önlem aldığını, loglarda kişisel veri tutup tutmadığını, yedeklerin nasıl şifrelendiğini ve yayın öncesi güvenlik testi yapılıp yapılmadığını sorun. Kritik uygulamalarda bağımsız bir sızma testi planlamak, kodu yazan ekibin göremediği açıkları yakalar.
- OWASP Top 10 risklerine karşı geliştirme sürecinizde hangi kontroller var?
- Kişisel veriler nerede, nasıl şifrelenerek saklanıyor; yedekler nerede duruyor?
- Yayın öncesi güvenlik testi veya kod taraması yapıyor musunuz?
Yönetici şifreleri e-postayla paylaşılıyor; güvenlik sorularına "bizde sorun olmaz" dışında somut cevap verilmiyor.
Kalite Güvencesi: Test, Performans ve SEO
Ağırlık: Önemli · ×2Çalışıyor görünen yazılım ile üretimde güvenle çalışan yazılım arasındaki farkı test süreci belirler. Firmanın birim ve uçtan uca testleri, test ortamını (staging) ve hata takibini nasıl yönettiğini öğrenin. Kabul testini sizin ekibinizle birlikte, gerçekçi verilerle yapmayı teklif etmesi olumlu bir işarettir.
Web projelerinde kalite; hız, erişilebilirlik ve arama motoru uyumluluğunu da kapsar. Core Web Vitals değerleri, mobil uyumluluk, doğru başlık hiyerarşisi, yapılandırılmış veri ve yönlendirme planı yayın öncesinde kontrol edilmelidir. Eski siteden yeni siteye geçişte yönlendirme planı yapılmazsa yıllar içinde biriken organik trafik birkaç haftada kaybolabilir. Detaylı kontrol listesi için Teknik SEO Audit rehberimize göz atın.
- Otomatik testleriniz neyi kapsıyor, yayın öncesi kontrol listeniz var mı?
- Yayın öncesi hedeflediğiniz Lighthouse / Core Web Vitals değerleri nedir?
- Eski siteden geçişte URL yönlendirme planını kim hazırlıyor?
Test ortamı yok; değişiklikler doğrudan canlı sistem üzerinde yapılıyor.
Barındırma, Ölçeklenme ve Altyapı
Ağırlık: Önemli · ×2Yazılım ne kadar iyi olursa olsun yanlış altyapıda yavaşlar, kesintiye uğrar veya güvenlik riski taşır. Firmanın uygulamanızı nerede barındırmayı önerdiğini, neden önerdiğini ve beklenen trafik arttığında ne yapılacağını sorun. Küçük bir kurumsal site için yönetilen web hosting yeterliyken, yoğun trafikli bir uygulama bulut sunucu üzerinde yatay ölçeklenebilir bir mimari ister.
Yedekleme sıklığı, yedekten geri dönüş testleri, izleme (monitoring) ve alarm mekanizmaları, SSL yenileme ve işletim sistemi güncellemelerinin kimin sorumluluğunda olduğu yazılı olmalıdır. "Sunucuyu siz alın, gerisini biz hallederiz" cümlesi, sorun çıktığında kimsenin sorumluluk almadığı gri bir alan yaratır.
- Uygulama için hangi altyapıyı öneriyorsunuz ve trafik artarsa plan nedir?
- Yedekler ne sıklıkla alınıyor, en son ne zaman geri dönüş testi yapıldı?
- Kesinti olduğunda bunu bizden önce fark etmenizi sağlayan izleme var mı?
Yedekleme ve izleme planı yok; sunucu erişim bilgileri tek bir çalışanın kişisel notlarında duruyor.
Yayın Sonrası Destek, SLA ve Bakım
Ağırlık: Kritik · ×3Yazılımın ömrünün büyük kısmı yayından sonra geçer: tarayıcı ve işletim sistemi güncellemeleri, güvenlik yamaları, yeni iş ihtiyaçları. Teslimattan sonra firmanın nasıl destek vereceği; garanti süresi, aylık bakım paketi kapsamı ve hizmet seviyesi taahhüdü (SLA) ile sözleşmede tanımlanmalıdır.
SLA'da en az şunlar yazmalıdır: öncelik seviyelerinin tanımı (kritik, yüksek, normal), her seviye için ilk yanıt ve çözüm hedef süreleri, destek kanalları ve çalışma saatleri, mesai dışı kritik hata prosedürü. "Ne zaman ararsanız ulaşırsınız" sözü güzeldir; ama yazılı bir süre taahhüdü olmadan ölçülemez.
- Garanti süresi ne kadar, bu sürede hangi hatalar ücretsiz düzeltiliyor?
- Kritik bir hatada ilk yanıt ve çözüm hedef süreleriniz nedir?
- Bakım paketine neler dahil, küçük geliştirme talepleri nasıl ücretlendiriliyor?
Destek koşulları sözleşmede yok; yayından sonra her talep ayrı ve belirsiz bir fiyatla karşılanıyor.
İmzadan Önce 7 Kırmızı Bayrak
Puanlama ne kadar yüksek çıkarsa çıksın, aşağıdakilerden biriyle karşılaşıyorsanız durun ve açıklama isteyin. Bunlar tek başına projeyi riske atabilecek işaretlerdir.
Sağlıklı Bir Projenin Zaman Çizelgesi
Doğru firmayla çalışırken proje genellikle aşağıdaki aşamalardan geçer. Süreler orta ölçekli bir kurumsal web uygulaması için yol göstericidir; kapsamınıza göre kısalır veya uzar. Önemli olan her aşamanın somut bir çıktıyla kapanmasıdır.
- 1.Keşif1–3 haftaKapsam dokümanı, backlog, riskler
- 2.Tasarım2–4 haftaWireframe, UI tasarımları, prototip
- 3.GeliştirmeSprintlerHer sprintte çalışan demo
- 4.Test & Kabul1–3 haftaTest raporu, kabul onayı
- 5.Yayın1 haftaCanlı ortam, yönlendirmeler, izleme
- 6.BakımSürekliSLA, güncellemeler, iyileştirmeler
Aday firmanızı puanlayın, karnesini görün
Kriterlerin altındaki Zayıf / Yeterli / Güçlü düğmeleriyle değerlendirin. Kritik ağırlıklı kriterler (referans, ekip, keşif, teklif, sözleşme, güvenlik, destek) skoru daha çok etkiler.
Sık Sorulan Sorular
W3 Bilişim'in kurucusu. ODTÜ Bilgisayar Mühendisliği; teknoloji girişimlerinde teknik liderlik ve kurumsal yazılım projelerinde satış öncesi keşiften teslimata kadar uçtan uca deneyim.
Profili gör