Outsource yazılım mı, ekip kiralama mı, proje bazlı mı? Sekiz ölçütle karar

Outsource yazılım: üç terim, iki ayrı soru

Outsource yazılım, yazılım işini kendi kadronuzun dışındaki birine yaptırmak demektir; bir şemsiye terimdir. Şemsiyenin altında farklı biçimler var ve karışıklığın çoğu, bunların aynı soruya cevap verdiğini sanmaktan çıkar. Aslında iki ayrı soru var: Ne satın alıyorsunuz, kapasite mi sonuç mu? Ve işi kim yönetiyor?

• Ekip kiralama: zaman ve kapasite satın alınır; ekibi siz yönetirsiniz, önceliği siz belirlersiniz.
• Proje bazlı: yazılı kapsamı olan bir sonuç satın alınır; yürütme tedarikçidedir.
• Serbest çalışan: tek bir kişiden, çoğu zaman kısa ve iyi tanımlı bir iş için alınan hizmet. Karşılaştırma için anılıyor.
• Kendi ekibini kurmak: yazılımcı bulma, işe alma ve yönetme sizdedir. Karşılaştırma için anılıyor.

Ekip kiralama ile proje bazlı yazılım geliştirme, outsource'un iki farklı biçimidir. Bir de sık karışan nokta var: ödeme modeli (sabit fiyat, zaman-malzeme, hibrit) ile çalışma modeli aynı şey değildir. Ödeme tarafı için yazılım teklifi nasıl okunur yazımızdaki tabloya bakın; bu yazı çalışma ve yönetim modelini karşılaştırıyor.

Yazılımı kime ve hangi modelle yaptıracağınız sorusu, "hazır ürün mü özel yazılım mı?" sorusundan sonra gelir; o soru için hazır yazılım mı özel yazılım mı çalışma sayfasına bakabilirsiniz. Özel yazılım yaptıracaksanız bu yazı size sekiz ölçüt, bir karar çalışma sayfası ve tedarikçiye sorulacak on iki soru veriyor. Özel yazılım geliştirme sayfamızda işin nasıl yürüdüğünü ayrıca anlattık.

Sekiz ölçütle karşılaştırma tablosu

Hücreler nitel ve "genelde" kalıbındadır; bir ürünün ya da tedarikçinin tüm koşullarını bilmeden rakam verilemez, biz de rakam vermiyoruz. Tabloyu kopyalayıp kendi notlarınızla genişletebilirsiniz.

Tabloyu okurken iki şeye dikkat edin. Birincisi, satırlar birbirinden bağımsız değil: yönetimi üstlenmediğiniz bir modelde (ölçüt 1) sonuç riskini de çoğunlukla başkası taşır (ölçüt 2), ama bunun karşılığında kapsamın yazılı olması gerekir (ölçüt 3). İkincisi, hiçbir model her satırda kazanmaz: kendi ekibiniz sahipliği ve bilgiyi içeride tutar ama başlamak yavaştır; ekip kiralama esnektir ama yönetim sizdedir; proje bazlı çalışma yönetim yükünü azaltır ama net bir kapsam ister.

Tablo bir hüküm değil, bir başlangıç noktasıdır: her satırda "genelde"nin sizin durumunuzda tutup tutmadığını aşağıdaki sorularla sınayın.

Ölçüt ölçüt: neye bakılır, ne sorulur

1. Kim yönetir ve kime hesap verir?

Yazılım işinin sık bozulduğu yerlerden biri, işi tarif eden ile yapan arasındaki mesafedir. Modeller bu mesafeyi farklı yerlere koyar: kendi ekibinde ve kiralanan ekipte yönetim sizdedir, proje bazlı çalışmada yürütme tedarikçidedir. İyi görünen cevap: günlük işi kimin yönettiği ve kararı kimin verdiği adıyla belli. Uyarı veren cevap: "ekip kendi kendini yönetir" deniyor ama önceliği kimin belirlediği yok, ya da sizinle işi yapan arasında bir aktarıcı katman var. Sorulacak soru: bu işte karar veren kişi kim ve onunla doğrudan konuşabilir miyim?

2. Kapsam, takvim ve maliyet riski kimde?

Her işte bir yerde bir belirsizlik kalır; soru onu kimin taşıdığıdır. İyi görünen: risk paylaşımı yazılı; hangi gecikmeyi kim üstleniyor belli. Uyarı veren: "esneklik" adı altında kimsenin üstlenmediği bir risk. Kapasite kiralıyorsanız sonuç riski büyük ölçüde sizdedir; sabit kapsamlı bir işte ise kapsam dışına çıkıldığında risk size geri döner. Sorulacak soru: takvim ya da maliyet planı aşılırsa ne olur ve bu yazılı mı?

3. Kapsam değişirse ne olur?

Yazılım işinde kapsam çoğu zaman değişir; modeller yalnızca değişikliğin nasıl karşılandığında ayrışır. Kapasite kiralamada öncelik değiştirmek kolaydır, yazılı kapsamlı çalışmada ise değişiklik bir karardır. Genel iyi uygulama şudur: kapsam değişikliği, yazılı bir güncelleme olmadan yapılmaz. İyi görünen: değişiklik talebi yazılı, işe, takvime ve maliyete etkisi yazılı, siz onaylamadan uygulanmıyor. Uyarı veren: "bunu da yaparız" diye sözlü kabul. Sorulacak soru: değişiklik isteğimi nasıl iletirim, etkisini yazılı olarak ne zaman alırım?

4. Bilgi sürekliliği ve kişi bağımlılığı

Bir sistemi en iyi yazan bilir; o kişi ayrıldığında sistem ne kadarının yazıya geçtiğine kadar sizindir. Bu ölçüt serbest çalışanda en görünür, ama her modelde vardır. İyi görünen: sistemi birden fazla kişi biliyor; karar nedenleri ve kurulum belgeleri yazılı. Uyarı veren: her şey tek bir kişinin kafasında. Sorulacak soru: kilit kişi ayrılırsa ne olur, yerine kim gelir, bilgi nasıl aktarılır? Tedarikçi değişirse neyi alacağınızı yarım kalmış yazılım projesi devralma yazımızdaki "eski ekipten istenecekler" bölümü gösteriyor.

5. Kod, hesap ve fikri hakların sahipliği

Çalışan bir yazılımınız olması, onun sizin olduğu anlamına gelmez; kod, hesaplar ve haklar ayrı ayrı sorulur. İyi görünen: kod deposu, sunucu, alan adı ve üçüncü taraf hesapları sizin adınıza; hakların devri yazılı ve tek tek sayılı. Eser sahibinin mali haklarının devri yazılı olmalıdır (5846 sayılı Kanun, madde 52). Uyarı veren: "kaynak kod sizindir" tek cümlesi ve tedarikçi adına açılmış hesaplar. Sorulacak soru: kod ve haklar kime, ne zaman, hangi belgeyle geçer? Bu madde genel bilgidir, hukuki danışmanlık değildir.

6. İlerlemenin görünürlüğü

Gecikmeyi erken görmenin tek yolu, çalışan işi görmektir. "Durum raporu" ile "çalışan yazılım" aynı şey değildir. İyi görünen: canlı bir panel, ortak kod deposu ya da her ara teslimde gerçekten çalışan bir sürüm. Uyarı veren: yalnızca toplantı ve rapor. Sorulacak soru: ilerlemeyi hangi araçla, ne sıklıkta ve tedarikçiden bağımsız olarak nasıl görürüm?

7. Başlama ve bitirme esnekliği

Belirsiz bir ürün fikrinde başlamak kadar durmak da önemlidir. İyi görünen: başlama koşulu, çıkış koşulu ve işi yarıda kestiğinizde o güne kadarki işin neye dönüştüğü yazılı. Uyarı veren: çıkış koşulunun hiç yazılmaması ya da çıkışı fiilen imkânsız kılan bir kurgu. Sorulacak soru: işi yarıda kesersem o güne kadar yapılanı ve kodu bana teslim eder misiniz?

8. Sizin tarafta gereken yetkinlik ve zaman

Outsource etmek yönetim yükünü sıfırlamaz, yalnızca yerini değiştirir. İyi görünen: modelin sizden ne beklediği önceden yazılı: kim, ne sıklıkla, hangi kararı verecek. Uyarı veren: sizden teknik yönetim bekleniyorken bunun söylenmemesi ya da "siz hiçbir şey yapmayacaksınız" vaadi. Sorulacak soru: bu modelde benim tarafımda kim, haftada ne kadar zaman ayırmalı, hangi kararlar bende?

Sekiz ölçütün hepsi her işte aynı ağırlıkta değildir. Bir iç araçta görünürlük ve esneklik öne çıkabilir, müşteriye açılan bir üründe sahiplik ve sürekliliğin ağırlığı artar. Bu yüzden aşağıdaki karar çalışma sayfası önce ölçütleri ağırlıklandırıyor.

Hangi durumda hangi model? Proje bazlı, ekip kiralama ve diğerleri

(a) Kapsamı yazılabilen, sonucu belli bir ürün ya da sistem: proje bazlı yazılım geliştirme uygundur. Ne istediğinizi bir belgeye dökebiliyor ve neyin "tamam" sayılacağını söyleyebiliyorsanız sonucu satın almak, yönetim yükünü tedarikçiye bırakır.

(b) Sürekli geliştirilen, öncelikleri haftalık değişen ürün ve sizde ürün ile teknik yönetim var: ekip kiralama uygundur. Kapasiteyi siz yönlendirirsiniz, değişim kolaydır; karşılığında yönetim ve sonuç riski sizdedir.

(c) Tek kişilik, kısa, iyi tanımlı iş: serbest çalışan çoğu zaman yeterlidir. Küçük bir iş için yazılımcı bulma sürecini uzatmaya gerek yok; ama ölçüt 4 ve 5'i, yani kişiye bağımlılığı ve hak devrini yine yazılı çözün.

(d) Yazılım ürününüzün özü ve uzun yıllar sürecek: kendi ekibinizi kurmak anlamlıdır. Joel on Software sitesinde 2001'de yayımlanan bir yazının kuralı şöyle: bir iş çekirdek bir iş işleviyse onu kendiniz yapın.

(e) Hibrit: önce proje bazlı bir ilk sürüm, sonra kapasite. Ürünün ilk sürümü yazılı kapsamla çıkar, sonrasında öncelikleri sizin yönettiğiniz bir ekiple sürdürülür. Küçük ve belirsiz bir fikirde ilk sürümün kapsamını nasıl keseriz sorusu için MVP geliştirme sayfamıza bakın.

Seçim çoğu zaman tek bir ölçüte inmez. Önce "işim ne kadar tarif edilebilir?" diye sorun: tarif edilebiliyorsa yazılı kapsam bir avantajdır; edilemiyorsa, kapsamı yazıya dökmek için küçük bir ilk adım gerekebilir. Sonra "yönetimi kim yapabilir?" diye sorun: sizde ürün ve teknik yönetim yoksa ekip kiralama size yük bindirir. Son olarak "ayrılmak ne kadar kolay olmalı?" diye sorun; cevabınız ölçüt 5 ve 7'nin ağırlığını belirler.

Bir dürüstlük notu: tek ölçütünüz zaman ve kapasite satın almaksa, başka bir model size daha iyi hizmet eder. Mobil uygulama özelinde hazır araç, serbest çalışan ve ajans karşılaştırması için mobil uygulama yaptırma sayfamıza, bu seçeneklerin maliyet açısından farkları için mobil uygulama maliyeti yazımıza bakabilirsiniz.

Ekip kiralamanın hukuki ve işletme notları (Türkiye)

Kapasite kiralama, bazı kurgularda iş hukuku, fatura ve vergi sorularını gündeme getirebilir. Örneğin 4857 sayılı İş Kanunu'nun 2. maddesi asıl işveren-alt işveren ilişkisini tanımlar ve asıl işverenin, alt işverenin işçilerine karşı o işyeriyle ilgili yükümlülüklerinden alt işverenle birlikte sorumlu olduğunu söyler; 7. maddesi geçici iş ilişkisinin özel istihdam bürosu aracılığıyla ya da bir holding ya da şirketler topluluğu içinde kurulabileceğini düzenler (mevzuat.gov.tr).

Bir ekip kiralama düzeninin bu hükümlerden birine girip girmediği, işin nasıl tarif edildiğine ve sözleşmenin nasıl kurulduğuna bağlıdır; bunun cevabı bir hukuk sorusudur ve bu yazı onu vermez. Faturanın hangi unvanla ve hangi kalemle kesileceği de mali müşavirinizle netleştireceğiniz bir sorudur. Yurt dışından ekip kiralıyorsanız ya da Türkiye dışında çalışıyorsanız, ilgili ülkenin kuralları ayrıca devreye girer. Sözleşmeyi imzalamadan önce bir avukata ve mali müşavire danışın. Pratik bir kural: ekibin kimin çalışanı olduğunu, işi kimin yönettiğini ve kimin adına fatura kesildiğini sözleşmede açıkça yazdırın; bu üç cevap, avukatınızın ve mali müşavirinizin sorunu hangi başlıkta değerlendireceğini netleştirir. Bu bölüm genel bilgidir, hukuki ya da mali danışmanlık değildir.

Karar çalışma sayfası: ağırlıklandırın, puanlayın

Tabloyu kopyalayın. İlk sütuna her ölçütün sizin için önemini (düşük, orta, yüksek), sonraki dört sütuna her model için "uygun", "kısmen" ya da "uygun değil" yazın; son sütuna gerekçenizi not edin.

Bir eşik ya da toplam puan formülü vermiyoruz. Sonuç şudur: önemi "yüksek" olan ölçütlerin hiçbirinde "uygun değil" kalmayan model sizin için aday olabilir. İki model bu koşulu sağlıyorsa farkı "kısmen"lerde ve notlarınızda arayın. Kurgusal bir örnek: ölçüt 5 sizin için "yüksek" ve bir model bu ölçütte "uygun değil" ise (örneğin hesaplar tedarikçi adına açılıyor ve devir yazılı değil), o model ancak bu açık yazılı olarak kapatılırsa aday kalır. Ölçüt 7 "düşük" önemdeyse aynı modelin orada "kısmen" kalması kararı değiştirmez. Önce tek başınıza doldurun, sonra tedarikçilerin yanıtlarını (sıradaki on iki soru) işleyerek güncelleyin.

Outsource yazılım firmalarına sorulacak on iki soru

Model ne olursa olsun şu soruları yazılı sorun ve yanıtları yazılı alın.

1. Bu işi gün gün kim yönetecek, karar kimde ve kodu yazanla doğrudan konuşabilecek miyim?
2. Kod deposu kimin hesabında, ben her an erişebilir miyim?
3. İlerlemeyi nasıl görürüm: panel, ortak depo, ara teslim?
4. Kapsam değişikliği nasıl yazılır, fiyat ve takvim etkisini ne zaman yazılı alırım?
5. Ayrılırsam neyi, hangi biçimde ve ne zaman alırım (kod, veri, belge)?
6. Kilit kişi ayrılırsa ne olur, yerine kim gelir, bilgi nasıl aktarılır?
7. Sözleşme hangi unvanla yapılır, fatura hangi şirket adına kesilir?
8. Hakların devri yazılı mı, haklar tek tek sayılıyor mu, hangi koşulda bana geçiyor?
9. Kullanılan üçüncü taraf hesapları (barındırma, alan adı, ödeme, harita, yapay zeka) kimin adına açılacak?
10. Yayından sonra destek kimde, hangi kapsam ve hangi ücretlendirmeyle?
11. Yayından sonra bir hata çıkarsa sorumlu kim?
12. Bilgi devri nasıl yapılır: dokümantasyon, teknik karar kayıtları, eğitim?

Yanıtlar eksik, kaçamak ya da sözlü kalıyorsa bu da bir bilgidir. İyi bir tedarikçi, hangi sorunun kendi modelinde nasıl cevaplandığını açıkça anlatır; cevabın "duruma göre" olduğu yerlerde duruma göre neyin değiştiğini ve bunun yazılı nasıl göründüğünü isteyin. Bu listeyi yalnızca ilk görüşmede değil, teklifi aldıktan sonra da sorun: yazılı teklifin bu soruların kaçını cevapladığına bakın.

Biz bunu nasıl yapıyoruz

Burada yalnızca sitemizde yazdığımızı tekrarlıyoruz. Biz proje bazlı çalışıyoruz: her proje, onayladığınız yazılı teklifle başlayan ücretli bir çalışmadır. Kapsam, takvim ve maliyet herhangi bir ücretlendirme başlamadan önce yazılı olarak elinizdedir; onayınızdan önce tahsilat yoktur. Kodunuzu yazan mühendisle doğrudan konuşursunuz. Geliştirme başladığında hesabınızda durumu, teklifleri ve ödemeleri gösteren canlı bir proje paneli açılır.

Teslim edilen işin mülkiyeti, proje bedelinin tamamı ödendiğinde size geçer; altyapıyı bir gün başka bir ekibe taşımak isterseniz hesaplar, alan adları ve dokümantasyonla temiz bir devir için yanınızdayız. Sizin için işlettiğimiz hiçbir şey, bizimle kalmanız için bir koz değildir. Yayından sonra doğrudan destek veririz; ötesi projeye göre ölçeklenir. Ana sayfamızda da yazdığımız gibi, hazır bir şablon site, yalnızca en düşük fiyat ya da yalnızca görsel tasarım arıyorsanız başka bir yol size daha iyi hizmet eder. Çalışma biçimimizi özel yazılım geliştirme sayfamızda anlattık; ayrıntılar Süreç ve Kullanım Koşulları sayfalarında. Kapsamı yazılabilen bir işiniz varsa projenizi anlatın.

Sık sorulan sorular

Outsource ile ekip kiralama aynı şey mi?

Hayır. Outsource, işi dışarıya yaptırmanın genel adıdır. Ekip kiralama onun bir biçimidir: zaman ve kapasite satın alırsınız, işi siz yönetirsiniz. Proje bazlı çalışmada ise yazılı kapsamlı bir sonuç satın alırsınız ve yürütme tedarikçidedir. İkisi birbirini dışlamaz; bir ürünün ilk sürümü proje bazlı, sonraki gelişimi kiralanmış kapasiteyle yürüyebilir.

Proje bazlı çalışmada kapsam değişirse ne olur?

Genel iyi uygulama, kapsam değişikliğinin yazılı bir güncelleme olmadan yapılmamasıdır: değişikliğin işe, takvime ve maliyete etkisi yazılı bildirilir ve siz onaylamadan uygulanmaz. Bu yöntemin teklifte yazılı olup olmadığını tedarikçiye sormanız gerekir. Teklifte neye bakacağınız için yazılım teklifi nasıl okunur yazısındaki değişiklik yönetimi satırına bakın.

Ekip kiralamada yazılımın kodu kime ait olur?

Bu sözleşmeye bağlıdır. 5846 sayılı Kanun'un 52. maddesi, mali haklara dair sözleşmelerin yazılı olmasını ve konusu olan hakların ayrı ayrı gösterilmesini şart koşar (mevzuat.gov.tr). Kapasite kiralasanız da kodun ve hakların nasıl geçtiğini yazılı çözün. Bu cevap genel bilgidir, hukuki danışmanlık değildir.

Hangi model daha ucuz?

Ödediğiniz şey farklı: ekip kiralamada kapasite, proje bazlı çalışmada sonuç. Hangisinin daha ucuz olduğu işin ne kadar sürekli olduğuna, kapsamın ne kadar netleştirilebildiğine ve sizin yönetim zamanınıza bağlıdır. Burada rakam vermiyoruz; her modelin teklifini yazılı ve aynı kalemlerle isteyin, yönetim için ayıracağınız kendi zamanınızı da hesaba katın.

Küçük ve belirsiz bir ürün fikri için hangi model?

Çoğu zaman önce kapsamı kesmek gerekir: tek ana akışla başlayan, yazılı kapsamlı bir ilk sürüm. Belirsizlik yüksekse işi büyük bir kapsamla başlatmak yerine küçük bir ilk sürümle öğrenmek mantıklıdır. Yöntemi MVP geliştirme sayfamızda anlattık.

Kaynaklar

Aşağıdaki sayfalar 2 Kasım 2026'da açılıp okundu.

• In Defense of Not-Invented-Here Syndrome, Joel on Software, 14 Ekim 2001
• 5846 sayılı Fikir ve Sanat Eserleri Kanunu, madde 52, mevzuat.gov.tr · 4857 sayılı İş Kanunu, madde 2 ve 7, mevzuat.gov.tr

Bu yazı genel bilgi içindir; hukuki ya da mali danışmanlık değildir.