İstanbul'da Yazılım Geliştirme Şirketi Nasıl Seçilir? Kontrol Listesi

İstanbul'da bir yazılım geliştirme şirketi seçerken asıl soru "en iyisi hangisi?" değil, "bu projeyi doğrulanabilir biçimde kim teslim eder ve kodu kime bırakır?" sorusudur. Kısa listeye girecek firmayı dört şeye bakarak ayırabilirsiniz: canlıda açıp inceleyebileceğiniz işler ve konuşabileceğiniz referanslar, kaynak koda ve repoya ilk günden erişiminiz, yazılı bir süreç ve sözleşme, yayından sonrası için tanımlı destek. Aşağıdaki kontrol listesi ve puanlama tablosu, üç-dört adayı aynı ölçütle karşılaştırmanız için hazırlandı.

Yazılım geliştirme şirketi seçerken önce neye bakmalısınız?

Firma sitelerindeki logo duvarları ve genel başarı cümleleri karşılaştırma yapmanıza yardım etmez. Seçimi sadeleştirmek için adayları şu sırayla eleyin:

1. Kapsam uyumu: Firma sizin işinize benzer bir şeyi (web platformu, mobil uygulama, MVP, entegrasyon) daha önce canlıya almış mı?
2. Doğrulanabilirlik: Gösterilen işler canlıda açılıyor mu, o işlerin müşterileriyle konuşabiliyor musunuz?
3. Teknik şeffaflık: Kod nerede duruyor, kim inceliyor, canlıya nasıl çıkıyor?
4. Ticari çerçeve: Sözleşme modeli, fikri mülkiyet, KVKK ve destek şartları yazılı mı?
5. İletişim: Karşınızda kim olacak, ne sıklıkla ve hangi dilde konuşacaksınız?

Bu sıra önemlidir: kapsam uyumu olmayan bir firmayla sözleşme ayrıntısı tartışmak iki tarafın da zamanını harcar.

Portföy ve referanslar nasıl doğrulanır?

Portföy bir ekran görüntüsü galerisi değil, kanıt olmalı. Bir başarı hikayesini incelerken şunları sorun: ürün bugün canlıda mı, firma projede tam olarak hangi işi yaptı (tasarım mı, backend mi, tamamı mı), hangi problem çözüldü ve sonuç nasıl ölçüldü? "Uçtan uca geliştirdik" denilen bir ürünü indirip kullanın; yavaşlık, çökme ya da aylardır güncellenmemiş içerik gibi belirtileri kendiniz görün.

Referans görüşmesi en az yapılan ama en çok bilgi veren adımdır. Firmadan, sizinkine benzer bir projedeki müşterisiyle kısa bir görüşme ayarlamasını isteyin ve şunları sorun:

• Proje planlanan süre ve kapsamda bitti mi? Bitmediyse firma bunu ne zaman ve nasıl söyledi?
• Kapsam değiştiğinde süreç nasıl yönetildi, beklenmedik bir fatura çıktı mı?
• Yayından sonra bir hata çıktığında ne kadar sürede dönüş aldınız?
• Bugün aynı firmayla yeniden çalışır mıydınız?

Gizlilik sözleşmeleri nedeniyle bazı işler gösterilemeyebilir, bu normaldir. Ama hiçbir işini gösteremeyen ve hiçbir referansla görüştüremeyen bir firmada teknik değerlendirmeyi çok daha sıkı yapmanız gerekir.

Teknik yetkinlik nasıl ölçülür?

Teknik geçmişiniz olmasa bile olgunluğu anlamanın yolu var: süreci anlatmalarını isteyin ve cevapların somut olup olmadığına bakın. Olgun bir ekip aşağıdaki konuları araç adı ve örnekle anlatır, genel ifadelere sığınmaz.

• Repo erişimi ve kod sahipliği: Kod ilk günden sizin hesabınızda (GitHub, GitLab veya Bitbucket) mı duruyor, yoksa proje sonunda sıkıştırılmış bir klasör olarak mı teslim edilecek? Doğru cevap, commit geçmişini baştan itibaren görebildiğiniz bir repodur.
• Code review: Her değişiklik birleştirilmeden önce başka bir geliştirici tarafından inceleniyor mu? Pull request geçmişi bunun kanıtıdır.
• CI/CD: Testler, tip kontrolü ve yayına alma otomatik mi, yoksa biri sunucuya elle dosya mı yüklüyor?
• Testler: Hangi akışlar otomatik testle korunuyor? Her satırın testi olmayabilir, ama ödeme, giriş ve yetkilendirme gibi kritik akışların testi olmalı.
• Ortamlar: Değişiklikleri canlıya çıkmadan önce görebileceğiniz bir test (staging) ortamı var mı?
• Mimari kararlar: Teknoloji seçimlerinin gerekçesini yazılı olarak açıklayabiliyorlar mı? Bu kararların uzun vadeli etkisini ölçeklenebilir ve sürdürülebilir yazılım mimarisi yazımızda ele aldık.

Süreç şeffaflığı neden bu kadar önemli?

Yazılım projeleri çoğunlukla teknik nedenlerle değil, sorunların geç fark edilmesi yüzünden raydan çıkar. Şeffaf bir süreç, sorunu haftalar sonra değil günler içinde görmenizi sağlar. Bakmanız gerekenler:

• Kısa iterasyonlar: İş bir-iki haftalık sprintlere bölünüyor mu, her sprint sonunda çalışan bir şey gösteriliyor mu?
• Demo: İlerlemeyi yüzdelerle ve slaytlarla değil, test ortamında tıklayabildiğiniz ekranlarla mı görüyorsunuz?
• Raporlama: Yapılan iş, harcanan efor ve açık riskler düzenli ve yazılı olarak paylaşılıyor mu?
• Görev takibi: İşlerin durumunu Jira, Linear veya Trello gibi bir araçta kendiniz görebiliyor musunuz?

"Bitince haber veririz" yaklaşımı, özellikle sabit fiyatlı işlerde, son haftada büyük sürprizlere yol açar.

Sabit fiyat mı, zaman ve malzeme (T&M) mi?

İki model de doğru yerde kullanıldığında işe yarar. Sorun, kapsamı belirsiz bir işe sabit fiyat verilmesi ya da ucu açık bir T&M anlaşmasının kontrolsüz bırakılmasıdır.

Pratik bir yol: keşif ve kapsam çalışmasını ayrı ve sabit bedelli bir aşama olarak yapmak, geliştirmeyi ise netleşen kapsama göre sabit fiyatla ya da tavanlı T&M ile sürdürmek. Böylece iki modelin riskini de azaltırsınız.

Kaynak kod ve fikri mülkiyet kimde olmalı?

Bedelini ödediğiniz yazılımın kaynak kodu, tasarım dosyaları ve dokümantasyonu size ait olmalı ve bu sözleşmede açıkça yazmalı. Kontrol edilecek maddeler:

• Fikri mülkiyet haklarının ne zaman devredildiği (her ödemede mi, proje sonunda mı).
• Firmanın kendi hazır kütüphanelerini veya lisanslı bileşenlerini kullanıp kullanmadığı ve bunların lisans şartları.
• Sunucu, veritabanı, alan adı ve uygulama mağazası hesaplarının sizin adınıza açılmış olması.
• Kullanılan açık kaynak bileşenlerin lisanslarının ticari kullanıma uygun olması.
• Ayrılık durumunda devir: kod, erişim bilgileri, dokümantasyon ve teslim notu.

Uygulama mağazası hesabının ya da alan adının firma adına kayıtlı olması, ilişki bittiğinde en çok sorun çıkaran konulardan biridir. Bunu ilk toplantıda sorun.

KVKK ve veri güvenliği nasıl değerlendirilir?

Kişisel veri işleyen bir yazılımda geliştirici firma çoğu zaman veri işleyen konumundadır ve 6698 sayılı Kişisel Verilerin Korunması Kanunu'ndan doğan yükümlülükler sözleşmeye yansımalıdır. Resmi rehberlere Kişisel Verileri Koruma Kurumu sitesinden ulaşabilirsiniz. Firmaya şunları sorun:

• Canlı kullanıcı verisine kim, hangi yetkiyle erişecek? Geliştirme ve test ortamlarında gerçek veri kullanılacak mı?
• Şifreler, API anahtarları ve diğer gizli bilgiler repoda değil, güvenli bir yerde mi tutuluyor?
• Veriler hangi sağlayıcıda ve hangi ülkede barındırılacak? Yurt dışına aktarım söz konusu mu?
• Yetkilendirme, loglama ve yedekleme nasıl kurgulanıyor, bir güvenlik ihlalinde süreç ne?
• Gizlilik ve veri işleme maddeleri sözleşmede yer alıyor mu?

Yayından sonra destek ve SLA'da neye dikkat edilmeli?

Yazılım canlıya çıktığı gün bitmez. İlk haftalarda gerçek kullanıcılar, test ortamında görülmeyen hataları bulur. Teklifte şu soruların cevabı olmalı:

• Yayın sonrası dahil olan destek süresi ne kadar ve neyi kapsıyor (hata düzeltme mi, küçük değişiklikler mi)?
• Kritik bir hatada müdahale süresi (SLA) nedir, mesai dışında kime ulaşılır?
• Bakım anlaşması neleri içeriyor: kütüphane güncellemeleri, güvenlik yamaları, sunucu takibi?
• Mobil uygulamalarda yeni iOS ve Android sürümlerine uyum kimin sorumluluğunda? Bu tarafın neden zor olduğunu mobil uygulama geliştirme sayfamızda anlattık.

Ekip sürekliliği ve iletişim nasıl sınanır?

Satış görüşmesini yapan kişiyle projede çalışacak ekip aynı olmayabilir. Projede kimlerin çalışacağını isim ve rolle sorun, mümkünse teknik lideri ilk toplantılardan birinde görün. Ekipten biri ayrıldığında bilginin kaybolmaması için dokümantasyon, kod incelemesi ve yazılı kararlar gerekir; tek bir geliştiricinin kafasında duran proje risklidir.

İletişim tarafında haftalık toplantı ritmini, ortak kanalı (Slack, Teams veya e-posta), sorularınıza ne kadar sürede dönüş alacağınızı ve dokümanların hangi dilde yazılacağını baştan netleştirin.

Hangi uyarı işaretleri sizi durdurmalı?

• Diğer tekliflerin belirgin biçimde altında fiyat: Fark genellikle test, code review, dokümantasyon veya destekten kısılarak kapatılır ve bedeli sonra ödenir.
• Yazılı kapsam yok: "Konuştuğumuz gibi yaparız" diyen bir teklif, anlaşmazlıkta elinizde hiçbir şey bırakmaz.
• Repo erişimi verilmiyor: Kodu proje sonuna kadar göremiyorsanız, ne yazıldığını da bilmiyorsunuz demektir.
• "Her şey iki haftada hazır" vaadi: Gereksinimler dinlenmeden verilen kesin süre bir tahmin değil, satış cümlesidir.
• Her soruya "evet": İyi bir ekip bazı fikirlere itiraz eder, kapsamı küçültmeyi önerir, gerektiğinde "buna şimdi ihtiyacınız yok" der.
• Altyapı firma adına: Sunucu, alan adı veya mağaza hesabı sizin adınıza açılmıyor.
• Tek kişiye bağımlılık: Bütün bilgi tek bir geliştiricide ve yazılı hiçbir şey yok.

Yazılım geliştirme şirketi adaylarını karşılaştırmak için puanlama tablosu

Her adayı her ölçütte 1 ile 5 arasında puanlayın, puanı ağırlıkla çarpıp toplayın. Ağırlıkları kendi projenize göre değiştirebilirsiniz; aşağıdakiler çoğu web ve mobil proje için makul bir başlangıçtır.

Tek bir satırda 1 alan adayı, toplam puanı yüksek olsa bile yeniden değerlendirin. Özellikle kod sahipliği ve yazılı kapsam, sonradan telafisi zor konulardır.

İlk toplantıda hangi soruları sormalısınız?

1. Bizimkine benzer, canlıda olan bir işinizi gösterebilir misiniz, o müşterinizle görüşebilir miyiz?
2. Projede kimler çalışacak, teknik lider kim olacak?
3. Kod hangi repoda tutulacak, erişimimiz ne zaman başlayacak?
4. Bir değişiklik canlıya nasıl çıkıyor, bu adımların hangileri otomatik?
5. İlerlemeyi ne sıklıkla ve hangi biçimde göreceğiz?
6. Kapsam değişirse süre ve bütçeye etkisi nasıl hesaplanıyor?
7. Yayından sonra hangi destek dahil, sonrasında bakım nasıl işliyor?
8. Bu projede en büyük riski nerede görüyorsunuz?

Son soru özellikle faydalıdır: riski somut olarak adlandırabilen bir ekip, projeniz üzerine gerçekten düşünmüştür.

İstanbul merkezli bir ekiple çalışmanın pratik avantajları neler?

Konum tek başına bir kalite ölçütü değildir, ama bazı işleri kolaylaştırır:

• Aynı saat dilimi: Sorular aynı iş günü içinde cevaplanır, ortak toplantı saati bulmak kolaydır.
• Yüz yüze çalıştay: Keşif ve kapsam aşamasında aynı masada yapılan bir-iki oturum, haftalarca süren yazışmanın yerini tutabilir.
• Türkçe sözleşme ve faturalama: Sözleşme Türk hukukuna göre ve Türkçe hazırlanır, fatura yerel mevzuata uygun kesilir, yurt dışı ödeme ve döviz işlemleri gerekmez.
• KVKK aşinalığı: Yerel ekipler KVKK yükümlülüklerini, e-fatura ve yerel ödeme altyapıları gibi entegrasyonları günlük işlerinde görür.

Öte yandan başka bir şehirdeki ya da yurt dışındaki bir ekip de doğru süreçle iyi sonuç verebilir. Belirleyici olan konum değil, bu yazıdaki ölçütlerdir.

Detartech bu ölçütlere nasıl cevap veriyor?

Ümraniye'deki ofisimizden web, mobil ve MVP projeleri geliştiriyoruz. Yukarıdaki listeye kendi cevaplarımız şöyle:

• İşi iki haftalık sprintlerle yürütüyoruz ve her sprint sonunda çalışan sürümü gösteriyoruz.
• Her değişiklik birleştirilmeden önce başka bir geliştirici tarafından inceleniyor; testler ve yayına alma otomatik CI/CD hattından geçiyor.
• Repo tüm geçmişiyle sizin hesabınızda duruyor; sunucu, veritabanı ve alan adı sizin adınıza açılan hesaplarda kuruluyor. Teslim paketinin ayrıntısı web geliştirme sayfamızda.
• Yayından sonraki 30 günlük destek teslimata dahil.
• MVP geliştirme projelerinde teknik borcu yazılı bir devir notuyla teslim ediyoruz.

Canlıdaki işlerimizi başarı hikayeleri sayfasında inceleyebilirsiniz; yapay zeka destekli hukuki doküman yönetimi Lextum AI veya endüstriyel çamaşırhane yönetimi Welldone, çalışma biçimimizden örneklerdir.

Projenizi bu kontrol listesi üzerinden konuşmak isterseniz ilk görüşme ücretsizdir ve 24 saat içinde dönüş yapıyoruz. Kısa bir özetle hızlı teklif formunu doldurmanız yeterli.

Sıkça Sorulan Sorular

İstanbul'daki en iyi yazılım geliştirme şirketi hangisi?

Herkes için geçerli tek bir "en iyi" firma yoktur; doğru firma projenizin türüne, bütçenize ve iç ekibinize göre değişir. Sıralama listeleri yerine üç-dört adayı bu yazıdaki puanlama tablosuyla değerlendirin, referanslarıyla görüşün ve repo erişimi, yazılı kapsam ve destek şartlarını yan yana koyun.

Yazılım firmasıyla yapılan sözleşmede hangi maddeler mutlaka olmalı?

Yazılı kapsam ve kabul kriterleri, ödeme planı, kaynak kodun ve fikri mülkiyetin size devri, altyapı hesaplarının sahipliği, gizlilik ve KVKK maddeleri, yayın sonrası destek süresi ve müdahale süreleri. Ayrılık durumunda devrin nasıl yapılacağını da yazılı hale getirin.

Teknik bilgim yoksa bir yazılım şirketinin yetkinliğini nasıl anlarım?

Repo erişimi isteyin, pull request ve code review geçmişini göstermelerini rica edin, bir değişikliğin canlıya nasıl çıktığını adım adım anlatmalarını isteyin. Cevaplar somut araç ve örneklerle geliyorsa bu iyi bir işarettir. Gerekirse teklifi ve kodu bağımsız bir teknik danışmana inceletebilirsiniz.

Sabit fiyatlı proje mi daha güvenli, T&M mi?

Kapsam netse ve değişmesi beklenmiyorsa sabit fiyat bütçe öngörülebilirliği sağlar. Ürün kullanıcıdan öğrenerek şekillenecekse T&M daha esnektir, ama sprint raporları ve bütçe tavanıyla kontrol edilmelidir. Keşif aşamasını ayrı tutmak iki modelin riskini de azaltır.

Yazılım şirketini değiştirmek istersem ne olur?

Kod sizin repoda, altyapı sizin hesaplarınızda ve dokümantasyon güncelse geçiş yönetilebilir bir iştir. Bunlar firmadaysa geçiş önce erişimleri geri almakla başlar ve uzar. Bu yüzden devir maddesini sözleşmede en baştan konuşun.